LILO confusion when both 64-Bit and 32-Bit Slackware are installed
I’m using an AMD64 computer, and I decided to try and install the 32-Bit and the 64-Bit versions of Slackware 13.37 next to each other (each on their own partition, of course). I installed 64-Bit first, then 32-Bit, and set up LILO on the MBR.
Result: 32-Bit runs fine, but 64-Bit will not boot. Instead, it hangs on the following on-screen messages: Code:
Freeing unused kernel memory: 612k freed Code:
INFO: taskswapper:1 blocked for more than 120 seconds I also found a work-around: If I set up LILO on the Root Blocks of my system partitions, and make the MBR chainload to them, then both installs work fine. Here is the list of boot options in my MBR LILO configuration: Code:
image = /boot/vmlinuz After a little experimenting, I discovered that the “Slackware-64” entry appears to load the 32-Bit kernel (from the /dev/sda2 partition) instead of the 64-Bit one (which sits on /dev/sda3). It looks like it locates the “/boot/vmlinuz” file while the “/sbin/lilo” is being run to install the boot loader (i.e., when my root filesystem is /dev/sda2). I could actually confirm my suspicion after I reinstalled the MBR LILO from the 64-Bit system instead; after that, the 32-Bit system could successfully boot, but it turned out to run the 64-Bit kernel, while its root filesystem was the 32-Bit Slackware system partition. I’m not sure if this behaviour should be considered a bug; it may simply work “as designed,” given that the location of the kernel is determined when the “/sbin/lilo” command is run. I do know, however, that it is something to be aware of! |
I have a double-boot with Slackware-13.37 and Slackware64-13.37 here, using LiLO. It's installed on the MBR, with sda1 as common swap for both systems, sda2 and sda5 the respective /boot partitions and sda3 and sda6 the respective root partitions of both systems.
Here's my /etc/lilo.conf: Code:
# Start LILO global section Cheers. |
GRUB uses the run-time location of the kernel and so you would specify /boot/vmlinuz for each installation. LILO, however, directly accesses inode locations and therefore you must specify the current location of the kernel on the running system. The other boot partition (or root (/) partition if /boot is not on its own partition) needs to be mounted when lilo is run but does not need to be mounted during everyday use.
|
Quote:
|
Quote:
|
I usually have shared /boot for multiple distributions and use symlinks, like vmlinuz-slackware, vmlinuz-gentoo, vmlinuz-salix, etc. Only drawback is that I have to make sure symlinks points to right kernel after any kernel upgrade.
Kikinovak's solution seems better for these situations. Thanks for sharing! |
All times are GMT -5. The time now is 08:48 AM. |