Re: [SOLVED] lilo config is busted, need help fixing it
On Mon, 27 Sep 2010 21:19:28 -0400 (EDT), briand@aracnet.com wrote:
> On Mon, 27 Sep 2010 10:09:15 -0400 (EDT), Stephen Powell wrote:
>>
>> 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.
If I recall correctly, you got farther with this one than you did
with the one that had a missing initrd entry. You were able to
boot this one with a root file system override, whereas the one
with the missing initrd entry would not boot at all.
>>
>> 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.
Right now, it's only a working setup for one kernel: 2.6.32-5-amd64.
If you're not going to make these changes, you might as well de-install
the other kernels. They will not boot, so what good are they?
What 2.6.32-5-amd64 calls /dev/sda is a PATA disk, which will be
treated as /dev/hda by all the other kernels.
>
> 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.
That's not the point. It is possible that adding another disk may
change the device names. But it is certain that booting any kernel
other than 2.6.32-5 will change the device names.
>
> uuid is very annoying because I can't look at it and know what's
> going on.
I agree. That's why I add comments to /etc/fstab.
>> 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
>>
>> to
>>
>> RESUME=UUID=558d7790-5914-494d-938f-3387296eed45
>
> 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 understand. But there were multiple problems, any one of which may
have caused a boot failure. We have them all fixed now. And I
will stay with you until you get it working. In the case of
the resume file, I suspect that although it used the uuid form,
it was using the wrong uuid (an old one). By default, the uuid changes
whenever the partition is re-formatted (mkswap). Do you share a swap partition
between, say, a Debian system and an Ubuntu system? The Ubuntu installer
is known to reformat a swap partition, which will change its uuid,
which will break the Debian system. That's just one example.
(Perhaps there is an option to skip the formatting of the swap partition,
or to re-use its existing uuid. But I've never installed Ubuntu;
so I don't know.)
>>
>> 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...
Thanks. I suggest the following here:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
UUID=a948d6b6-8395-49a1-9f0f-21a10ceee9c2 / ext3 defaults,errors=remount-ro 0 1
# /dev/sda2 / ext3 defaults,errors=remount-ro 0 1
UUID=4b764501-da53-4323-a751-3da37d7e2a91 /home ext3 defaults 0 2
# /dev/sda3 /home ext3 defaults 0 2
UUID=558d7790-5914-494d-938f-3387296eed45 none swap sw 0 0
# /dev/sda4 none swap sw 0 0
...
>> 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 :-)
I just did an upgrade yesterday and I noticed that new versions of
the 71xx and 96xx legacy driver packages have been recently uploaded
to the archive. If your machine needs one of those driver packages,
then the web page is out-of-date already. :-(
I will have to experiment with the new packages and revise the web page
accordingly. If you use the 173xx legacy or the current package,
then the web page should (hopefully) still be current.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: