On Mon, 27 Sep 2010 10:09:15 -0400 (EDT)
Stephen Powell <zlinux...@wowway.com> wrote:

> On Sun, 26 Sep 2010 21:27:37 -0400 (EDT), bri...@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


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100927181928.45306...@windy.deldotd.com

Reply via email to