Re: Can't boot 2.6.32-3 after running 2.6.32-5 for a while
On Wed, 23 Jun 2010 14:20:07 -0400 (EDT), Camaleón wrote:
> On Wed, 23 Jun 2010 14:04:53 -0400, Stephen Powell wrote:
>> On Wed, 23 Jun 2010 13:33:16 -0400 (EDT), Camaleón wrote:
>>>
>>> So, all entries in "/etc/lilo.conf" are pointing to "uuid" devices or
>>> just the ones loading the "-3" kernel?
>>
>> There are only two lines in /etc/lilo.conf that are relevant: boot and
>> root. Both are in the global section, not in a per-image section.
>
> How is that? Can't LiLo manage a multiboot menu or is a personal
> configuration? :-?
Of course it can. But the only thing that differs between the two
kernels is the kernel image and its corresponding initial RAM file
system image. They share the same permanent root file system.
>
> I ask because I never used LiLo but GRUB, and here is quite normal to
> have several lines/sections allowing the user to boot the desired kernel/
> system.
The same is true of lilo.
>
> Can you copy/paste the relevant "lilo.conf" boot entries you are using
> for both, the ones that boot "-3" kernel and the ones that boot "-5"
> kernel?
If you want the exact configuration file, that will have to wait for about
seven hours, until I have access to that machine again. But perhaps
you will be satisfied with an approximation for now. Here is an approximation
of what it looks like based on another machine. The uuids used in this example
are from this substitute machine:
----------
# /etc/lilo.conf
#
# global options
#
# boot=/dev/sda2
boot=/dev/disk/by-uuid/04db5929-51e6-424a-ac5b-a592b96b9d04
compact
default=Linux
delay = 40
install=text
large-memory
lba32
# root=/dev/sda2
root=/dev/disk/by-uuid/04db5929-51e6-424a-ac5b-a592b96b9d04
read-only
vga=3841
#
# per-image options
#
image=/boot/vmlinuz
label=Linux
initrd=/boot/initrd.img
#
image=/boot/vmlinuz.old
label=LinuxOld
initrd=/boot/initrd.img.old
optional
----------
I really don't think that the problem is in lilo (although I haven't
ruled that out yet). lilo does successfully boot the old kernel. But it
hangs part-way through the boot process. Under the 2.6.32-3 kernel,
/dev/disk/by-uuid/04db5929-51e6-424a-ac5b-a592b96b9d04 is a symbolic link
to /dev/hda2. Under the 2.6.32-5 kernel,
/dev/disk/by-uuid/04db5929-51e6-424a-ac5b-a592b96b9d04 is a symbolic link
to /dev/sda2. And in both cases, everything under /dev is a virtual file
system created by udev.
I suspect that the problem is in /etc/fstab, where similar entries are
used, and I suspect that it has to do with the timing of when udev
creates the symbolic link versus when it is being referenced. But
that is just a hunch at this point.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: