Re: [SOLVED] lilo config is busted, need help fixing it
On Mon, 27 Sep 2010 10:09:15 -0400 (EDT)
Stephen Powell <zlinuxman@wowway.com> wrote:
> On Sun, 26 Sep 2010 21:27:37 -0400 (EDT), briand@aracnet.com wrote:
> >
> > and..... IT WORKS !
> >
> > Talking to you from a freshly booted machine :-)
> >
> > First time it's booted properly in quite sometime.
> >
> > I'm not really clear on what exactly fixed things, although those
> > missing initrd lines were probably key.
>
> You had several unrelated problems.
>
> (1) The initial RAM disk specifications were missing from the two
> boot menu items in /etc/lilo.conf that used the standard symlinks.
> Therefore, neither of these two entries would boot at all.
>
yep. interestingly that was _not_ the problem with one of the entries that I tried:
image=/boot/vmlinuz-2.6.32-5-amd64
label="Lin 2.6.32img5"
initrd=/boot/initrd.img-2.6.32-5-amd64
read-only
so there's a bit of a mystery there.
> (2) Apparently, the specification of the swap partition in
> /etc/initramfs-tools/conf.d/resume was not valid. Therefore, the
> other kernels would boot but failed at resume processing.
> (This is not related to the lilo boot loader. It would have
> failed with any boot loader.)
see my comment below about uuid form vs device form.
>
> (3) /etc/kernel-img.conf had postinst_hook and postrm_hook lines
> that referred to a script that did not exist or could not be found
> in any of the directories in the path. That method is no longer
> safe to use anyway because, under certain conditions, it is possible
> for the hook script to be invoked before the initial RAM file system
> is updated. That's OK for grub version 1 (grub-legacy), but not
> for lilo. lilo should not be invoked until *after* the initial RAM
> file system is updated.
>
> (4) hook scripts in /etc/kernel/postinst.d, /etc/kernel/postrm.d,
> and /etc/initramfs/post-update.d were missing, obsolete, or
> superfluous.
>
> > Thank you very much for your help ! I _really_ appreciate it.
>
> You're welcome. Now, with your indulgence, I'd like to suggest some
> further changes that will make your setup more robust. For example,
> I notice that you have other kernels in your boot menu, such as
> 2.6.32-3. This kernel currently will probably not boot. I suggest
> the following changes in /etc/lilo.conf:
>
I see what you're doing here but I'm very reluctant to change a working set-up.
You're right, of course. The first time I throw a new disk in the machine things will break. So eventually I need to switch over to uuid/by-id.
uuid is very annoying because I can't look at it and know what's going on.
the by-id is much better though.
> Change
>
> boot=/dev/sda
>
> to
>
> boot=/dev/disk/by-id/ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692
>
> Change
>
> root=/dev/sda2
>
> to
>
> root="UUID=a948d6b6-8395-49a1-9f0f-21a10ceee9c2"
>
> In /etc/initramfs-tools/conf.d/resume, change
>
> RESUME=/dev/sda4
well the problem with this is that it DID use the UUID form, and that wouldn't work. So I'm _very_ reluctant to put it back. I'll break down and experiment with it at some point.
>
> to
>
> RESUME=UUID=558d7790-5914-494d-938f-3387296eed45
>
> You never did post the contents of your /etc/fstab file.
> I'd still like to see that.
>
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/sda2 / ext3 defaults,errors=remount-ro 0 1
/dev/sda3 /home ext3 defaults 0 2
/dev/sda4 none swap sw 0 0
bunch of other crap like temporary devices and nfs mounts deleted...
>
> > Now that it's working I can go back to try and create a custom
> > kernel :-)
>
> Good luck! I see from other posts that you use an Nvidia graphics
> card. I now have a new section at the end of my kernel building
> guide that explains how to create a custom kernel that uses the
> proprietary Nvidia drivers built the traditional Debian way. It is
> called "A Specific Example". You may wish to review that section.
>
Naturally :-)
Brian
Reply to: