FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 09-27-2010, 01:24 AM
 
Default lilo config is busted, need help fixing it

On Sun, 26 Sep 2010 19:51:12 -0400 (EDT)
Stephen Powell <zlinuxman@wowway.com> wrote:

> > # Kernel image management overrides
> > # See kernel-img.conf(5) for details
> > do_symlinks = no
> > relative_links = yes
> > do_bootloader = no
> > do_bootfloppy = no
> > do_initrd = yes
> > link_in_boot = yes
> > postinst_hook = lilo-update
> > postrm_hook = lilo-update
>
> You need to remove those last two lines, the ones that have
> "lilo-update" in them. At one time I recommended this for squeeze
> users that use only stock kernels, but I don't anymore. Besides,
> either you didn't write a corresponding lilo-update script or
> it got deleted somehow. Either way, you need to get rid of those
> two lines in /etc/kernel-img.conf.
> >

done. that explains the errors. that's the problem with this stuff is
unwinding the call stack.

Is there a magic option to pass apt-get or dpkg which will produce more
verbose output ?

Didn't see anything obvious in the manpage except for the "quiet"
parameter.


> > I haven't gone through the rest of the changes yet. Working on
> > that right now.
>
> Also, in /etc/initramfs-tools/conf.d/resume, the file should reference
> the swap partition, not the root partition, either directly or via a
> UUID. Older versions of the Debian installer contained a version of
> mkswap that did not assign a UUID. Also, if you install another
> operating system in another partition, such as Ubuntu, it may
> reformat the swap partition, which will change its UUID. You can
> either use
>
> RESUME=/dev/sda4
>
> or
>
> RESUME=UUID=558d7790-5914-494d-938f-3387296eed45
>


I'm not use if it makes a difference, but that file was referencing the
uuid, so I changed it to point at /dev/sda, simply to be consistent
with my fstab and lilo.conf.

my guess is that it will break if I put another disk drive in, right ?

Brian


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100926182458.239130c7@windy.deldotd.com">http://lists.debian.org/20100926182458.239130c7@windy.deldotd.com
 
Old 09-27-2010, 01:27 AM
 
Default lilo config is busted, need help fixing it

On Sun, 26 Sep 2010 20:01:36 -0400 (EDT)
Stephen Powell <zlinuxman@wowway.com> wrote:

> >> I also don't see any zz-lilo hook scripts, which the latest version
> >> of lilo would have installed. Reinstall the latest version of
> >> lilo. This should also install a file
> >> in /etc/initramfs/post-update.d called lilo or runlilo, depending
> >> on which version of lilo you are running. Then remove
> >> S50symlink_hook and K50symlink_hook. Finally, install the two
> >> zy-symlinks hook scripts available on my web site, one
> >> for /etc/kernel/postinst.d and one for /etc/kernel/postrm.d. Then
> >> make sure that ...
> >
> > Yes the zz scripts are there now.
>
> Good. Don't forget the zy-symlinks hook scripts and to delete the
> other ones and to install the latest initramfs-tools package, and
> to make sure that

done.

>
> do_symlinks = no
>
> is set in /etc/kernel-img.conf.
>

ok.


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.

Thank you very much for your help ! I _really_ appreciate it.

Now that it's working I can go back to try and create a custom
kernel :-)



Brian



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100926182737.535a81f7@windy.deldotd.com">http://lists.debian.org/20100926182737.535a81f7@windy.deldotd.com
 
Old 09-27-2010, 02:14 AM
 
Default lilo config is busted, need help fixing it

On Sat, 25 Sep 2010 12:28:00 -0400 (EDT)
Stephen Powell <zlinuxman@wowway.com> wrote:

> On Sat, 25 Sep 2010 03:40:04 -0400 (EDT), briand@aracnet.com wrote:
> I'm also going to need
> to see the output of the following commands:
>
> ls -Al /dev/disk/by-id/


lrwxrwxrwx 1 root root 9 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692 -> ../../sda
lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Sep 26 18:12 ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692-part4 -> ../../sda4
lrwxrwxrwx 1 root root 9 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692 -> ../../sda
lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Sep 26 18:12 scsi-SATA_WDC_WD2500YS-01_WD-WCANY2148692-part4 -> ../../sda4
lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_CF_SDDR-189_2008102301130-0:3 -> ../../sde
lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_mSD_SDDR-189_2008102301130-0:0 -> ../../sdb
lrwxrwxrwx 1 root root 9 Sep 26 18:12 usb-SanDisk_MSxDSDDR-189_2008102301130-0:2 -> ../../sdd
lrwxrwxrwx 1 root root 9 Sep 26 18:12
usb-SanDisk_SD_SDDR-189_2008102301130-0:1 -> ../../sdc



> ls -Al /dev/disk/by-uuid/
> >

lrwxrwxrwx 1 root root 10 Sep 26 18:12 4b764501-da53-4323-a751-3da37d7e2a91 -> ../../sda3
lrwxrwxrwx 1 root root 10 Sep 26 18:12 558d7790-5914-494d-938f-3387296eed45 -> ../../sda4
lrwxrwxrwx 1 root root 10 Sep 26 18:12 9EFC3C45FC3C1A4B -> ../../sda1
lrwxrwxrwx 1 root root 10 Sep 26 18:12
a948d6b6-8395-49a1-9f0f-21a10ceee9c2 -> ../../sda2


So there's something going on with the swap partition (/dev/sda4). I must have had an aborted resume from hibernate mode or something (don't remember doing it).

either way, not good.

> > It seems like I have two different problems. I have a lilo entry
> > that doesn't work at all and another one which dumps me into this
> > resume nonsense.
>

> ERROR! No initial RAM disk specified! Add:
>
> initrd=/boot/initrd.img
>

ok.

> ERROR! No initial RAM disk image. Add:
>
> initrd=/boot/initrd.img.old

ok.

> >> /etc/kernel-img.conf
> >
>
> Where is it? I need to see the contents of that file.
> It's very important.
>

# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = no
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = yes
postinst_hook = lilo-update
postrm_hook = lilo-update

I haven't gone through the rest of the changes yet. Working on that right now.

Brian


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100926191429.2ede9596@windy.deldotd.com">http://lists.debian.org/20100926191429.2ede9596@windy.deldotd.com
 
Old 09-27-2010, 02:29 AM
 
Default lilo config is busted, need help fixing it

On Sat, 25 Sep 2010 12:28:00 -0400 (EDT)
Stephen Powell <zlinuxman@wowway.com> wrote:

>
> Several problems here. S30initramfs, S50symlink_hook,
> K30initramfs, and K50symlink_hook, though they will still
> work, I now consider obsolete. S30initramfs and K30initramfs
> were made obsolete by newer versions of the initramfs-tools
> package. The initramfs-tools hook scripts appear to be missing.
> And you have a couple of scripts called initramfs-tools.dpkg-dist.
> Are they renamed versions of initramfs-tools? Are they the current
> versions of them? I would erase S30initramfs, K30initramfs,
> and both copies of initramfs-tools.dpkg-dist, and reinstall
> the latest version of the initramfs-tools package. This should
> install a script called initramfs-tools in both /etc/kernel/postinst.d
> and /etc/kernel/postrm.d.

All done. I am now running the latest lilo:

ii lilo
1:22.8-8.3 LInux LOader - The Classic OS loader can
load Linux and others

however:

Setting up linux-image-2.6.32-5-amd64 (2.6.32-23) ...
Running depmod.
Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Running lilo-update.
User postinst hook script [lilo-update] failed to execute: No such file
or directory dpkg: error processing linux-image-2.6.32-5-amd64
(--configure): subprocess installed post-installation script returned
error exit status 255 configured to not write apport reports
Errors were encountered while
processing: linux-image-2.6.32-5-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)



>
> I also don't see any zz-lilo hook scripts, which the latest version
> of lilo would have installed. Reinstall the latest version of lilo.
> This should also install a file in /etc/initramfs/post-update.d called
> lilo or runlilo, depending on which version of lilo you are running.
> Then remove S50symlink_hook and K50symlink_hook. Finally, install
> the two zy-symlinks hook scripts available on my web site, one for
> /etc/kernel/postinst.d and one for /etc/kernel/postrm.d. Then make
> sure that
>

Yes the zz scripts are there now.

However it looks like the lilo install is borked.

Brian


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100926192934.34dd3aa0@windy.deldotd.com">http://lists.debian.org/20100926192934.34dd3aa0@windy.deldotd.com
 
Old 09-27-2010, 02:09 PM
Stephen Powell
 
Default lilo config is busted, need help fixing it

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.

(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.)

(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:

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

You never did post the contents of your /etc/fstab file.
I'd still like to see that.


> 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.

--
.'`. Stephen Powell
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1884665001.298704.1285596555275.JavaMail.root@md01 .wow.synacor.com">http://lists.debian.org/1884665001.298704.1285596555275.JavaMail.root@md01 .wow.synacor.com
 
Old 09-28-2010, 01:19 AM
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100927181928.45306656@windy.deldotd.com">http://lists.debian.org/20100927181928.45306656@windy.deldotd.com
 
Old 09-28-2010, 03:20 PM
Stephen Powell
 
Default 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
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1980597816.332928.1285687246910.JavaMail.root@md01 .wow.synacor.com">http://lists.debian.org/1980597816.332928.1285687246910.JavaMail.root@md01 .wow.synacor.com
 
Old 10-02-2010, 05:54 PM
 
Default lilo config is busted, need help fixing it

On Tue, 28 Sep 2010 11:20:46 -0400 (EDT)
Stephen Powell <zlinuxman@wowway.com> wrote:

> 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.
> >

I got rid of the unused images because I really don't need them.

I put in all the UUID and dev/by-id changes and much to my relief the
system still boots !


> # /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 ...
>

ok, I put this in too. Is there any way to validate the fstab file so
that I know it's right ?? I mean other than umount and mount...

> 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.
>

Haven't gotten this far yet, but I will. It just doesn't feel right to
not have rolled my own kernel :-)

Brian

p.s. again, thank you.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101002105411.0e471a62@windy.deldotd.com">http://lists.debian.org/20101002105411.0e471a62@windy.deldotd.com
 
Old 10-03-2010, 02:07 AM
Stephen Powell
 
Default lilo config is busted, need help fixing it

On Sat, 02 Oct 2010 13:54:11 -0400 (EDT), briand@aracnet.com wrote:
> Stephen Powell wrote:
>> 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.
>
> I got rid of the unused images because I really don't need them.
> I put in all the UUID and dev/by-id changes and much to my relief the
> system still boots !

Good! Don't forget to re-run lilo after making the changes, if you
haven't already done so. The change to the root specification requires
that lilo be re-run.

>> # /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
>> ...
>
> ok, I put this in too. Is there any way to validate the fstab file so
> that I know it's right ?? I mean other than umount and mount...

There are a couple of ways. One way is to use the blkid command.
For example,

blkid /dev/sda2

will return the uuid of /dev/sda2. The other way is to issue

ls -Al /dev/disk/by-uuid/

which will list all the udev-created symbolic links that have a uuid
in them and what they are links to. I prefer the second method because
it lists them all with a single command and also because it makes
sure that udev (at least this portion of it) is working properly.

> p.s. again, thank you.

You're welcome. I'm glad I could help.

--
.'`. Stephen Powell
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1073334106.449362.1286071636079.JavaMail.root@md01 .wow.synacor.com">http://lists.debian.org/1073334106.449362.1286071636079.JavaMail.root@md01 .wow.synacor.com
 
Old 10-03-2010, 03:24 AM
Tom H
 
Default lilo config is busted, need help fixing it

On Sat, Oct 2, 2010 at 10:07 PM, Stephen Powell <zlinuxman@wowway.com> wrote:
>
> There are a couple of ways. *One way is to use the blkid command.
> For example,
>
> blkid /dev/sda2
>
> will return the uuid of /dev/sda2. *The other way is to issue
>
> ls -Al /dev/disk/by-uuid/
>
> which will list all the udev-created symbolic links that have a uuid
> in them and what they are links to. I prefer the second method because
> it lists them all with a single command and also because it makes
> sure that udev (at least this portion of it) is working properly.

Just "blkid" will output all the UUIDs and I think that the default
option is "udev" (it scans "/dev/disk/by-uuid") and the other option
is "scan" (it scans "/proc/partitions").

You can use "blkid -o list" to list the associated mount points.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikP0Fxukvz-9EU6U16Rwc45dcmew=YjQMMHYemH@mail.gmail.com">http://lists.debian.org/AANLkTikP0Fxukvz-9EU6U16Rwc45dcmew=YjQMMHYemH@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 08:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org