Alien Pastures

My thoughts on Slackware, life and everything

Tag: lilo

How I switched us.slackware.nl from lilo to grub

February 27, 2025 / / 1 Comment

Today I finally switched my US server from lilo to grub as its bootloader.

The reason for doing it now, is that I usually do not have a remote IP console (KVM) to that physical server which is located in a US datacenter whereas I live in Europe. This server’s storage is configured as software RAID1 and has been running for years on a Slackware huge kernel, since I was unable to make a generic kernel plus initrd work. That was many years ago.
Now this server runs Slackware-current and the recent updates to Slackware-current include automatic recreation of an initrd, followed by an update of the Grub configuration when installing a new kernel. Essentially, when you have configured Grub to boot your machine, you won’t have to re-install the bootloader until the actual grub package is upgraded to a new version.

I wanted this switch from lilo to grub to ease future upgrades. But had to wait until the server owner was able to connect a KVM and gave me access. The reason for being hesitant to just install grub and reboot are obvious: what if the server won’t come up after boot, for whatever reason? I won’t be able to fix that remotely without access to the console and maybe the BIOS.

I did my research on installing Grub to a software RAID and in the course of that, discovered that Linux does not even read the file “/etc/mdadm.conf” anymore, because the RAID metadata is written to the disks themselves and mdadm extracts it on the fly. Anyway, I also learned that there’s a peculiarity that you need to take into account when using Grub to boot off a software RAID: you need to install Grub to both of the hard drives that together form the software RAID1. I thought, well I can do that!

Then I scribbeled down some possible iterations of the “grub-install” command that I would try until one actually worked. Why that doubt about a successful outcome? Obviously because I was bitten before! I have switched a Linode server from lilo to grub last year and the grub-install command crapped out with:

grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists

What I eventually needed to do was add “–force” to the grub-install command because apparently Grub works fine with blocklists despite the error. The command eventually became:

# grub-install --recheck /dev/sda --force

… and the Linode rebooted just fine into Grub. Goes to say, Grub is at least as finicky as lilo.

Of course, when you anticipate bad things to happen, you’re jinxed and bad things will happen.
When I was ready to start the switch from lilo to grub, had a KVM connected, installed the latest kernel-generic and let that generate an initrd.img and write a Grub configuration, I proceeded with:

# grub-install --recheck /dev/sda

What I did not anticipate was the resulting error:

Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won’t be possible.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.

I had to search for that warning and the error to find out what was happening. Searching for the error message (last line) was not returning much useful information but when searching for the warning, I found the GRUB article on the Arch Linux Wiki (Arch to the rescue once again): GRUB#GUID_Partition_Table_(GPT)_specific_instructions

It is a really informative and instructive article! Basically, my disks are formatted as GPT and not equipped with a MBR. Grub’s requirements are vastly different in those two cases:

  • When installing to a MBR disk, it squeezes the ‘core.img’ code in the post-MBR gap, between byte number 512 and the start of the first partition. Now it also makes sense why disk partitioning utilities start the first partition at sector 2048 which leaves almost 1 MB for the Grub bootloader.
  • When installing to a GPT disk, Grub wants to install its ‘core.img’ to a separate “BIOS Boot Partition” (partition number ‘EF02’)

Oops… my disk was already partitioned, not leaving any space and was already running as ‘us.slackware.nl’ for years! I could not simply erase the disks and start from scratch.
Luckily the Arch Wiki article pointed out that this BIOS Boot partition can still be created, in the space before the first partition.  Modern disk partition tools, as said earlier, create the first partition at sector 2048. The trick is to use gdisk (because this is a GPT disk) and prompt it to create a new partition. Gdisk will tell you that it can create one that starts at sector 34 and will end at sector 2047. Perfect for our needs.
So, I created that partition and assigned partition type ‘EF02’ to it (equivalent to GUID ‘21686148-6449-6E6F-744E-656564454649’ and skipped creating a filesystem on it – not needed.

It turns out that this partition can be in any position order as long as it is on the first 2 TiB of the disk. In my case, it became partition number ‘4’ even though it’s physically located at the start of the disk.

After creating the partition, I re-ran the grub-install commands:

# grub-install --recheck /dev/sda
# grub-install --recheck /dev/sdb

There were no errors, I double-checked my KVM access and rebooted. The server came back up without a hickup.

I hope this write-up will help someone somewhere in the future.
Cheers, Eric

Adding Linux to the Windows7 boot menu

February 24, 2012 / / 30 Comments

When I create a Windows / Linux dual-boot computer I usually add Windows as an option to my LILO boot menu. That is the easiest way, and works always.

However, I ran into a situation where I could not use LILO as the primary boot loader and I had to look into the Windows7 “boot configuration data” or BCD. Actually it was Windows Vista, not Windows7, which was the first to abandon good old C:\boot.ini and start writing its bootloader configuration into a binary block of data. I wrote this post just to have this procedure available as a reference.

Windows7 contains the command-line program BCDedit which you are supposed to use for editing your Windows boot menu. A total load of crock it is. It will not support any OS that does not boot from the same hard disk that Windows7 is installed to… so I had some issues getting my Slackware added to the Windows boot menu because I had installed it on a second hard disk.

In the end I decided to shrink the Windows partition a little bit and add a small Linux partition where I could install LILO.

Microsoft has added a basic partition manager to Windows7 – something they do more often. If a 3rd party creates an invaluable add-on to provide functionality Microsoft did not include into Windows, then Microsoft will eventually copy its basic functionality into a half-hearted clone. Anyway, the freed-up hard disk space was allocated to a small partition which became Slackware’s “/boot” and I installed LILO to that /boot partition.

Then, just like in the days of Windows NT and “c:\boot.ini”, I extracted the first 512 bytes from the root sector of that /boot partition (in my case, that partition was “/dev/sda3“) and wrote it to a USB stick which I had mounted on “/mnt/hd“:

dd if=/dev/sda3 of=/mnt/hd/linux.bin bs=512 count=1

Rebooted to Windows7 and transfered that 512 byte file called “linux.bin” from the USB stick to the root of the Windows C: drive.

Next, I used BCDedit to add an entry to Windows7’s BCD store. Note that administrative privileges are required to use BCDedit!. What you do is navigate to “Start->All Programs->Accessories“, Right-click on “Command Prompt” and select “Run as administrator“.

In this command window, enter the BCDedit commands. Start by creating an entry for Slackware Linux. I use “Linux” as the label for the boot menu. The actual label you choose is arbitrary of course:

bcdedit /create /d “Linux” /application BOOTSECTOR

BCDedit will return an alphanumeric identifier for this entry. Copy that string into a text file and do not lose it!

In the remainder of this article I will refer to this string as {ID}. You would replace {ID} with the actual identifier as returned by the command you ran. An example of what you can get for an {ID} is {244ebca6-432f-11df-ab86-ce0c22f636af}.

The next step will be to specify which partition holds the copy of the Linux boot loader sector (our “linux.bin” file):

bcdedit /set {ID} device partition=c:

Then specify the actual path to the “linux.bin” file on that C: drive:

bcdedit /set {ID}  path \linux.bin

The Windows boot menu needs an entry for our Slackware Linux OS:

bcdedit /displayorder {ID} /addlast

Usually you won’t see the boot menu at all (after all, it does not contain any other entry than Windows7 itself). In order to allow the user of the computer some reflection time, we add a delay to the menu’s display timeout. Say, the boot menu should remain visible for 30 seconds before booting into the default selection:

bcdedit /timeout 30

That would be all. You can test the new Windows boot menu by rebooting the computer. You should be able to select either Windows7 (default) or Linux to boot into. When you choose “Linux”, you’ll be taken to Slackware’s familiar LILO menu.

If at any time you would have to remove the “Linux” menu option, you can run the following command … provided you wrote the {ID} string down somewhere:

bcdedit /delete {ID}

Have fun, even with Windows,

Eric

Robby’s libata switchover howto

January 9, 2010 / / 8 Comments

The new kernels in Slackware (post 13.0) have one important change compared to previous kernels. This change will affect anyone with Slackware installed on an IDE disk (like /dev/hda) who wants to upgrade to the latest state of affairs.

The new kernels exclusively use “libata”. The last bits of the old IDE/ATA subsystem have finally been removed.

This means, that your IDE disk will be recognized as a “SCSI disk”. The device name “/dev/hda” will change to “/dev/sda” when you boot the new kernel. As a result, your computer will refuse to boot because the bootloader (grub or lilo) can not find the root device.

Robby Workman has written a HOWTO for anyone who wants to do this upgrade. The article was published as http://rlworkman.net/howtos/libata-switchover. By following the HOWTO you will not have any issues in upgrading to the new kernel.

I will print Robby’s HOWTO in full below to give it some more coverage:

libata_switchover
20100110
rworkman

/*
Thanks to David Somero, Old_Fogie, gegechris99, and GazL for valuable
feedback and enhancements to this document.
*/

This is written to provide one of several ways to retain a working system after upgrading from Slackware 13.0’s kernel to the newer kernel in -current (which removes support for the “old” ide subsytem, thereby causing all /dev/hd* devices to have /dev/sd* names.

1. Upgrade the kernel and kernel-modules packages normally.

2. Edit /etc/fstab to reflect the change from hd* to sd*.

If you have multiple SATA devices, and especially if you have some of
both hd* and sd* devices present already, then you’re basically going
to be playing a guessing game right now, and you probably want to
consider using some of the persistent symlinks in /dev/disk/by-*/
instead of raw device nodes.

* If you are using one of the generic kernels (requiring an initrd),
then use the sd* name for the root device when creating the image
(edit /boot/initrd-tree/rootdev and then re-run “mkinitrd”).

* You will almost surely want to remove the udev rules file for cdrom
devices (it will be regenerated on the next boot with correct
information reflecting the new libata stuff):
# rm -f /etc/udev/rules.d/70-persistent-cd.rules

* Speaking of optical devices, if you have multiple disk drives and an
optical drive using the old ide subsystem, then be aware that the
optical drive will get a /dev/sr* name instead of /dev/sd* — this is
relevant because you might see something like this (if your optical
drive is currently /dev/hdb):

Old Name –> New Name
/dev/hda /dev/sda
/dev/hdb /dev/sr0
/dev/hdc /dev/sdb

3. Run lilo. Note that you have made no edits at all to it yet, unless
you needed to edit it for the new kernel. Specifically, do not make
any changes with respect to hd* –> sd*.

4. Reboot. At the lilo prompt, press <TAB> and add an append for the
real root device (which will no longer be /dev/hd*). For example, if
the old root device was /dev/hda1, and it will now be /dev/sda1, and
the name of your kernel image is “Linux” then you would type this:

Linux root=/dev/sda1

5. Once the system comes back up, then fix /etc/lilo.conf, run lilo, and
reboot again to be sure everything is correct.

Good luck! Eric

PS: I have refreshed the copy of Robby’s text so that it reflects the updates he made to the original after feedback from several people.

initramfs unpacking failed: junk in compressed archive

June 16, 2009 / / 2 Comments

Lilo, the 2.6.30.x kernel and Slackware on x86_64

Although Slackware -current still has a 2.6.29.x kernel, I am sure that people are experimenting with 2.6.30 kernels. In some cases, and only on Slackware for the x86_64 architecture so far, this may lead to boot problems. There is a problem that manifests itself when you are using an initial ramdisk with your kernel. The error message that you may see (unless it scrolls off your screen too fast) is this:

“initramfs unpacking failed: junk in compressed archive“

As a result, your computer will fail to boot.

Now, what is happening here?

By default, LILO loads your initial ramdisk (/boot/initrd.img) into the first 15MB of memory. This circumvents a BIOS limitation for older systems (typically, computers produced before 2001).

However, the linux kernel has been growing in size, and there are combinations of kernel and initrd that will no longer fit into the first 15MB of memory. This leads to boot failure. Because of the fact that the kernel and initrd files are compressed archives, the rule of thumb is that these issues appear when the combined size of your kernel and initrd files is larger than 8 MB. The kernel will then overwrite part of the initrd in memory, leading to the above error message.

For computers with a x86_64 capable CPU, it is safe to assume that the computer has a BIOS without the 15MB limitation. In this case, you can add the following parameter to your “/etc/lilo.conf” file:

large-memory

This option instructs LILO to use a larger memory window when loading the initial ramdisk (do not forget to run the “lilo” command after making this change). It will cure the issue.

I think this should be added as a default option in the lilo.conf file generated by the liloconfig utility of slackware64.

Eric

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑