lilo config is busted, need help fixing it
bri...@aracnet.com
at the lilo boot prompt and it will boot correctly. So clearly it's
pointing at the incorrect root device. I've double checked the
lilo.conf file and it says:
boot=/dev/sda
root=/dev/sda2
which is correct. the lilo command runs without warnings or errors.
I ran lilo -v 3 -t and it produced the following:
Boot image: /boot/vmlinuz-2.6.32-5-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
Setup length is 27 sectors.
Mapped 4708 sectors.
Mapping RAM disk /boot/initrd.img-2.6.32-5-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
RAM disk: 9407 sectors.
Added Lin_2.6.32img5
<dev=0xe0,hd=227,cyl=57,sct=204>
"ro root=802"
I immediately noticed that dev=0xe0
brw-rw---- 1 root disk 8, 0 Sep 23 20:45 /dev/sda
brw-rw---- 1 root disk 8, 1 Sep 13 05:17 /dev/sda1
brw-rw---- 1 root disk 8, 2 Sep 13 05:20 /dev/sda2
brw-rw---- 1 root disk 8, 3 Sep 13 05:22 /dev/sda3
brw-rw---- 1 root disk 8, 4 Sep 13 05:17 /dev/sda4
shouldn't dev=0x82 !!??
Anybody know how I can fix this ?
Thanks,
Brian
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100923205...@windy.deldotd.com
Stan Hoeppner
> Boot image: /boot/vmlinuz-2.6.32-5-amd64
> Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
> 63 sectors. Partition offset: 120583890 sectors.
> Using Volume ID 5879D4A8 on bios 80
> Setup length is 27 sectors.
> Mapped 4708 sectors.
> Mapping RAM disk /boot/initrd.img-2.6.32-5-amd64
> Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
> 63 sectors. Partition offset: 120583890 sectors.
> Using Volume ID 5879D4A8 on bios 80
> RAM disk: 9407 sectors.
> Added Lin_2.6.32img5
> <dev=0xe0,hd=227,cyl=57,sct=204>
> "ro root=802"
>
> I immediately noticed that dev=0xe0
> shouldn't dev=0x82 !!??
No, that's normal. What had you changed on the system immediately prior
to this boot problem occurring?
Boot image: /boot/vmlinuz-2.6.34.1
Device 0x0801: BIOS drive 0x80, 16 heads, 969021 cylinders,
63 sectors. Partition offset: 63 sectors.
Using Volume ID 37945249 on bios 80
Setup length is 23 sectors.
Mapped 2909 sectors.
Added Linux (alias 1) *
<dev=0xe0,hd=0,cyl=22,sct=25>
"ro root=802"
Boot image: /boot/vmlinuz-2.6.32.9
Device 0x0801: BIOS drive 0x80, 16 heads, 969021 cylinders,
63 sectors. Partition offset: 63 sectors.
Using Volume ID 37945249 on bios 80
Setup length is 23 sectors.
Mapped 2879 sectors.
Added LinuxOLD (alias 2)
<dev=0xe0,hd=0,cyl=22,sct=58>
"ro root=802"
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4C9C271D...@hardwarefreak.com
bri...@aracnet.com
Stan Hoeppner <st...@hardwarefreak.com> wrote:
> bri...@aracnet.com put forth on 9/23/2010 10:50 PM:
>
> > Boot image: /boot/vmlinuz-2.6.32-5-amd64
> > Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
> > 63 sectors. Partition offset: 120583890 sectors.
> > Using Volume ID 5879D4A8 on bios 80
> > Setup length is 27 sectors.
> > Mapped 4708 sectors.
> > Mapping RAM disk /boot/initrd.img-2.6.32-5-amd64
> > Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
> > 63 sectors. Partition offset: 120583890 sectors.
> > Using Volume ID 5879D4A8 on bios 80
> > RAM disk: 9407 sectors.
> > Added Lin_2.6.32img5
> > <dev=0xe0,hd=227,cyl=57,sct=204>
> > "ro root=802"
> >
> > I immediately noticed that dev=0xe0
>
> > shouldn't dev=0x82 !!??
>
> No, that's normal. What had you changed on the system immediately
> prior to this boot problem occurring?
apt-get dist-upgrade, natch.
it's very odd, because it runs just fine. and it boots fine as long as
I supply the root=/dev/sda2
aaargh. I've never had so much trouble in my entire
linux/debian/life. I have had a smooth boot or bootloader upgrade on
this computer since I fired it up. other one works good, though. but
really, 1/2 _is_ bad.
Brian
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100923212...@windy.deldotd.com
bri...@aracnet.com
<bri...@aracnet.com> wrote:
> aaargh. I've never had so much trouble in my entire
> linux/debian/life. I have had a smooth boot or bootloader upgrade on
> this computer since I fired it up. other one works good, though. but
> really, 1/2 _is_ bad.
I have NOT had a smooth, etc...
Brian
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100923213...@windy.deldotd.com
Stan Hoeppner
>> No, that's normal. What had you changed on the system immediately
>> prior to this boot problem occurring?
>
> apt-get dist-upgrade, natch.
WTF is "natch"?
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4C9C2CA9...@hardwarefreak.com
Boyd Stephen Smith Jr.
>bri...@aracnet.com put forth on 9/23/2010 11:25 PM:
>>> No, that's normal. What had you changed on the system immediately
>>> prior to this boot problem occurring?
>>
>> apt-get dist-upgrade, natch.
>
>WTF is "natch"?
Shortening of "naturally", which in this context is slang for "of course" or
"as expected".
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
David Baron
linux-image-2.6.32.5 from Sid. The postinstall script will point /etc/fstab
and lilo.conf to the newer UUID references and then it should play.
The postinstall for home-brew kernels does not do this for you, I'm afraid and
I was dead in the water for a few weeks till I installed the stock image.
(Afterwards, you do not need to keep it if your home-brew kernel now boots
OK.)
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201009241157....@012.net.il
bri...@aracnet.com
David Baron <d_b...@012.net.il> wrote:
> Try reinstalling your kernel, or if you compiled your own, install a
> recent linux-image-2.6.32.5 from Sid. The postinstall script will
> point /etc/fstab and lilo.conf to the newer UUID references and then
> it should play.
I'll give it a try,but I'm not clear on what the UUID reference has to
do with anything. it boots fine with root=/dev/sda2 and my fstab is
consistent, i.e. uses device designation and _not_ UUIDs.
>
> The postinstall for home-brew kernels does not do this for you, I'm
> afraid and I was dead in the water for a few weeks till I installed
> the stock image.
I'm running a stock kernel.
However it's certainly worth a try to see if it fixes it.
I'm following Steve Powell's excellent kernel guide:
http://www.wowway.com/~zlinuxman/Kernel.htm
and I'm fairly certain I've done everything correctly.
The real question here is: what tells lilo what the root device is ??
The lilo.conf file is correct. Is there something in one of the .map
files are some other auxiliary file screwing things up ?
Brian
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100924070...@windy.deldotd.com
bri...@aracnet.com
David Baron <d_b...@012.net.il> wrote:
> Try reinstalling your kernel, or if you compiled your own, install a
> recent linux-image-2.6.32.5 from Sid. The postinstall script will
> point /etc/fstab and lilo.conf to the newer UUID references and then
> it should play.
>
> The postinstall for home-brew kernels does not do this for you, I'm
> afraid and I was dead in the water for a few weeks till I installed
> the stock image.
>
> (Afterwards, you do not need to keep it if your home-brew kernel now
> boots OK.)
>
>
I deleted one of the older images and when it finished I got this mess:
Could not find postrm hook script [lilo-update].
Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin'
Examining /etc/kernel/postrm.d .
Purging configuration files for linux-image-2.6.18-6-amd64 ...
Could not find postrm hook script [lilo-update].
Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin'
Examining /etc/kernel/postrm.d .
clearly I did not follow Mr. Powells guide correctly.
Fun project for the weekend.
Brian
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100924071...@windy.deldotd.com
Stephen Powell
>
> I deleted one of the older images and when it finished I got this mess:
>
> Could not find postrm hook script [lilo-update].
> Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin'
> Examining /etc/kernel/postrm.d .
> Purging configuration files for linux-image-2.6.18-6-amd64 ...
> Could not find postrm hook script [lilo-update].
> Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin'
> Examining /etc/kernel/postrm.d .
>
> clearly I did not follow Mr. Powells guide correctly.
>
> Fun project for the weekend.
>
Hello, Brian. I have been following this thread, but I didn't want
to respond until I tried it myself. There is an important difference
between specifying
root=/dev/sda2
at the boot prompt versus supplying it in /etc/lilo.conf. When you
supply it on the command line at a boot prompt, I'm fairly sure that
it passes that literal string to the kernel during boot. But when
you specify it in /etc/lilo.conf, lilo's map installer translates it
into a four-digit hexadecimal number consisting of a two-digit major
number and a two-digit minor number. It is that number which gets
passed to the kernel at boot time. In your case it would be
root=802
(The leading zero is suppressed.) So it is theoretically possible
that something changed in the kernel so that it does not correctly
handle that type of root argument. Having said that, however, I cannot
reproduce your results using the latest stock Debian kernel for
squeeze for the i386 architecture: linux-image-2.6.32-5-686, version
2.6.32-23. Unless it is something specific to the amd64 architecture,
which I doubt, I suspect that lilo didn't get run during the upgrade,
as the above console log suggests. The first thing to try is to
manually run lilo, shutdown and reboot, and see if it fixes the
problem. If it does, then it's a pretty safe bet that lilo did not
get run during the upgrade, or at least not at the right time.
Due to changes in the way hook scripts are handled, I no longer
recommend using a hook script invoked from /etc/kernel-img.conf,
even when using stock kernels. And the latest version of lilo
available for squeeze, 1:22.8-8.3, now includes its own hook scripts.
These hook scripts do not maintain symbolic links, however. If you
are using only stock kernels, you can take care of getting
symlinks maintained by using
do_symlinks = yes
in /etc/kernel-img.conf, but if you use custom kernels at all,
this won't cut it. In that case, you need my zy-symlinks hook
scripts from my web site. Also, I am using lilo 23.0, which is
available from upstream but not yet as an official Debian package;
so that also might possibly explain why I cannot reproduce your
problem. But I doubt it. Current stock Debian kernels for the
amd64 architecture are right on the ragged edge of being too
large for lilo to load below the 16M line; and lilo 23.0 contains
some important fixes for amd64 users; so you might want to give
lilo 23.0 a try.
I suggest that you review
http://www.wowway.com/~zlinuxman/Kernel.htm#Customize
for a more complete treatment of the topic.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1437715587.253054.1285...@md01.wow.synacor.com
bri...@aracnet.com
I've run lilo and rebooted multiple times and always get the same
result.
> I suggest that you review
>
> http://www.wowway.com/~zlinuxman/Kernel.htm#Customize
>
> for a more complete treatment of the topic.
I've been using that as my guide.
right now I'm thinking I've got something misconfigured, but what ??
Running lilo manually should fix whatever's going on and it most
certainly isn't.
Brian
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100924174...@windy.deldotd.com
Stephen Powell
>
> I've run lilo and rebooted multiple times and always get the same
> result.
Interesting. What happens if you specify
root=802
as an argument to the boot prompt?
> right now I'm thinking I've got something misconfigured, but what ??
> Running lilo manually should fix whatever's going on and it most
> certainly isn't.
Please post your entire /etc/lilo.conf. Also post:
/etc/kernel-img.conf
A list of all files in /etc/kernel/postinst.d
A list of all files in /etc/kernel/postrm.d
A list of all files in /boot
The definitions of the boot-related symlinks:
vmlinuz
initrd.img
vmlinuz.old
initrd.img.old
The output of
lilo -v
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1780951118.257185.1285...@md01.wow.synacor.com
Stan Hoeppner
> Current stock Debian kernels for the
> amd64 architecture are right on the ragged edge of being too
> large for lilo to load below the 16M line
And the bulk of these ~16MB stock kernels is the initrd, correct? Wow
those are huge. I'm so glad I roll my own, from kernel.org source, and
forgo the "kitchen sink" initrd setups of the stock kernels.
-rw-r--r-- 1 root root 1.5M Jul 9 09:29 vmlinuz-2.6.34.1
-rw-r--r-- 1 root root 490K Jul 9 09:29 System.map-2.6.34.1
-rw-r--r-- 1 root root 29K Jul 9 09:29 config-2.6.34.1
At my pace of kernel file growth, I won't hit the lilo 22.8 16MB limit
for a few decades. :)
Correct me if I'm wrong Stephen, but isn't this 16MB ceiling more of a
block device controller BIOS limitation than a lilo limitation?
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4C9D8074...@hardwarefreak.com
Stan Hoeppner
> right now I'm thinking I've got something misconfigured, but what ??
> Running lilo manually should fix whatever's going on and it most
> certainly isn't.
Did you possibly lose your BIOS LBA configuration before the
dist-upgrade, and didn't know it? If your CMOS battery had died, which
is quite common on 4-5+ year old systems, and you rebooted the PC, when
it came back up your BIOS data would be at defaults. In this case your
disk geometry in the BIOS may have changed from say, LBA, to LARGE, or
NORMAL.
If this occurred, it "might" explain your problems. Once the system is
booted after you manually specify /dev/sda2 at the prompt, the ATA
driver may be defaulting to LBA mode. Thus, when you run lilo, it's
basing sector translation on block offsets using LBA. When you reboot,
if the BIOS is set to NORMAL (CHS) or LARGE, the translation isn't going
to match what lilo saved in the MBR or the first sector of a partition,
whichever method you use.
When you specify /dev/sda2 at the prompt, the bootloader is working with
the current BIOS translation setting and correctly finds the disk
sectors for the root filesystem. This may explain why you can
successfully boot in this manner, but not using the normal automatic
lilo boot--the sector translations may be different.
This is all a shot in the dark and I could be smoking crack. But, it
_seems_ possible given your symptoms. Check your mobo BIOS, or PCI card
disk controller BIOS, if that's what your disk is attached to, and make
sure the drive translation is set to LBA, which is likely what it was
before.
Like I said, it's a long shot...but worth checking.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4C9D85EA...@hardwarefreak.com
bri...@aracnet.com
I have it set to auto which is what it's always been set to.
Brian
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100925004...@windy.deldotd.com
bri...@aracnet.com
Stephen Powell <zlin...@wowway.com> wrote:
Before I post all that stuff, let me show you exactly what's happening
on boot. I think there is something very strange going on and it may
not be lilo.
Lin_img0 is : /boot/vmlinuz
When I boot using that entry I get the following error:
kernel-Panic: not syncing : VFS : Unable to mount root fs on unknown
- block(8,2)
specifying
Lin_img0 root=/dev/sda2
DOES NOT WORK.
When I use the lilo entry Lin_2.6.32img5, /boot/vmlinuz-2.6.32-5-amd64,
AND specify root=/dev/sda2, i.e.
Lin_2.6.32img5 root=/dev/sda2
I get the following weirdness:
Running /scripts/local-premount
resume: could not stat the resume device
file /dev/disk/by-uuid/558d7790-5914-4949....
enter full path:
at that point I enter /dev/sda2 and then it boots normally.
don't have any idea what the uuid it's try to use is, but this is a
real WTF !?
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.
Here's a really interesting observation:
The Lin_img0 lilo entry behaves differently from the Lin_2.6.32img5, BUT
THEY BOTH USE THE SAME IMAGE ! /boot/vmlinuz is a symlink to
vmlinuz-2.6.32-5-amd64.
ugh...
Brian
> On Fri, 24 Sep 2010 20:42:56 -0400 (EDT), bri...@aracnet.com wrote:
> >
> > I've run lilo and rebooted multiple times and always get the same
> > result.
>
> Interesting. What happens if you specify
>
> root=802
>
> as an argument to the boot prompt?
I get the above resume weirdness.
>
> Please post your entire /etc/lilo.conf. Also post:
# Generated by liloconfig
# This allows booting from any partition on disks with more than 1024
# cylinders.
lba32
# Specifies the boot device
boot=/dev/sda
# Specifies the device that should be mounted as root.
# If the special name CURRENT is used, the root device is set to the
# device on which the root file system is currently mounted. If the root
# has been changed with -r , the respective device is used. If the
# variable ROOT is omitted, the root device setting contained in the
# kernel image is used. It can be changed with the rdev program.
root=/dev/sda2
# Bitmap configuration for /boot/debianlilo.bmp
# bitmap=/boot/debianlilo.bmp
# bmp-colors=1,,0;9,,0
# bmp-table=106p,144p,2,9,144p
# bmp-timer=514p,144p,6,8,0
# Enables map compaction:
# Tries to merge read requests for adjacent sectors into a single
# read request. This drastically reduces load time and keeps the map
# smaller. Using COMPACT is especially recommended when booting from a
# floppy disk.
# compact
# Install the specified file as the new boot sector.
# LILO supports built in boot sectory, you only need
# to specify the type, choose one from 'text', 'menu' or 'bitmap'.
# new: install=bmp old: install=/boot/boot-bmp.b
# new: install=text old: install=/boot/boot-text.b
# new: install=menu old: install=/boot/boot-menu.b or boot.b
# default: 'menu' is default, unless you have a bitmap= line
# Note: install=bmp must be used to see the bitmap menu.
install=menu
# install=bmp
# Specifies the number of _tenths_ of a second LILO should
# wait before booting the first image. LILO
# doesn't wait if DELAY is omitted or if DELAY is set to zero.
# delay=50
# Prompt to use certaing image. If prompt is specified without timeout,
# boot will not take place unless you hit RETURN
prompt
timeout=50
# Enable large memory mode.
large-memory
# Specifies the location of the map file. If MAP is
# omitted, a file /boot/map is used.
map=/boot/map
# Specifies the VGA text mode that should be selected when
# booting. The following values are recognized (case is ignored):
# NORMAL select normal 80x25 text mode.
# EXTENDED select 80x50 text mode. The word EXTENDED can be
# abbreviated to EXT.
# ASK stop and ask for user input (at boot time).
# <number> use the corresponding text mode. A list of available modes
# can be obtained by booting with vga=ask and pressing [Enter].
vga=normal
# Defines non-standard parameters for the specified disk.
# If you are using removable USB drivers (with mass-storage)
# you will need to tell LILO to not use these devices even
# if defined in /etc/fstab and referenced in /proc/partitions.
# Adjust these lines to your devices:
#
# disk=/dev/sda inaccessible
# These images were automagically added. You may need to edit something.
image=/boot/vmlinuz
label="Lin img0"
read-only
image=/boot/vmlinuz-2.6.26-2-amd64
label="Lin 2.6.26img2"
initrd=/boot/initrd.img-2.6.26-2-amd64
read-only
image=/boot/vmlinuz-2.6.31-1-amd64
label="Lin 2.6.31img3"
initrd=/boot/initrd.img-2.6.31-1-amd64
read-only
image=/boot/vmlinuz-2.6.32-3-amd64
label="Lin 2.6.32img4"
initrd=/boot/initrd.img-2.6.32-3-amd64
read-only
image=/boot/vmlinuz-2.6.32-5-amd64
label="Lin 2.6.32img5"
initrd=/boot/initrd.img-2.6.32-5-amd64
read-only
image=/boot/vmlinuz.old
label="Lin img6"
read-only
# If you have another OS on this machine (say DOS),
# you can boot if by uncommenting the following lines
# (Of course, change /dev/hda2 to wherever your DOS partition is.)
# other=/dev/hda2
# label="MS Windows"
>
> /etc/kernel-img.conf
> A list of all files in /etc/kernel/postinst.d
-rwxr-xr-x 1 root root 436 Jun 4 06:33 dkms
-rwxr-xr-x 1 root root 614 Apr 7 20:53 initramfs-tools.dpkg-dist
-rwxr-xr-x 1 root root 196 Mar 18 2010 pm-utils
-rwxr-xr-x 1 root root 1607 Apr 3 21:22 S30initramfs
-rwxr-xr-x 1 root root 3355 Jul 14 22:33 S50symlink_hook
> A list of all files in /etc/kernel/postrm.d
-rwxr-xr-x 1 root root 563 Apr 7 20:53 initramfs-tools.dpkg-dist
-rw-r--r-- 1 root root 1662 Apr 3 21:24 K30initramfs
-rw-r--r-- 1 root root 3390 Apr 3 21:27 K50symlink_hook
> A list of all files in /boot
boot.0800
coffee.bmp
config-2.6.26-2-amd64
config-2.6.31-1-amd64
config-2.6.32-3-amd64
config-2.6.32-5-amd64
debian.bmp
debianlilo.bmp
initrd.img
initrd.img-2.6.26-2-amd64
initrd.img-2.6.31-1-amd64
initrd.img-2.6.32-3-amd64
initrd.img-2.6.32-5-amd64
initrd.img.old
map
sarge.bmp
sid.bmp
System.map-2.6.26-2-amd64
System.map-2.6.31-1-amd64
System.map-2.6.32-3-amd64
System.map-2.6.32-5-amd64
vmlinuz
vmlinuz-2.6.26-2-amd64
vmlinuz-2.6.31-1-amd64
vmlinuz-2.6.32-3-amd64
vmlinuz-2.6.32-5-amd64
vmlinuz.old
> The definitions of the boot-related symlinks:
>
> vmlinuz
> initrd.img
> vmlinuz.old
> initrd.img.old
>
lrwxrwxrwx 1 root root 25 Jul 14 22:38 initrd.img ->
initrd.img-2.6.32-5-amd64
lrwxrwxrwx 1 root root 25 Jul 14 22:38 initrd.img.old ->
initrd.img-2.6.32-3-amd64
lrwxrwxrwx 1 root root 22 Jul 14 22:38 vmlinuz ->
vmlinuz-2.6.32-5-amd64
lrwxrwxrwx 1 root root 22 Jul 14 22:38 vmlinuz.old ->
vmlinuz-2.6.32-3-amd64
> The output of
>
> lilo -v
>
LILO version 22.8 (test mode), Copyright (C) 1992-1998 Werner
Almesberger Development beyond version 21 Copyright (C) 1999-2006 John
CoffmanReleased 19-Feb-2007, and compiled at 18:52:11 on Sep 21 2009
Running Linux kernel 2.6.32-5-amd64 on x86_64
Debian GNU/Linux
device-mapper major = 254
raid_setup returns offset = 00000000 ndisk = 0
BIOS VolumeID Device
Reading boot sector from /dev/sda
pf_hard_disk_scan: ndevs=1
0800 5879D4A8 /dev/sda
Resolve invalid VolumeIDs
Resolve duplicate VolumeIDs
0800 5879D4A8 /dev/sda
device codes (user assigned pf) = 0
device codes (user assigned) = 0
device codes (BIOS assigned) = 1
device codes (canonical) = 1
Device 0x0800: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 0 sectors.
Using Volume ID 5879D4A8 on bios 80
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
mode = 0x03, columns = 80, rows = 25, page = 0
Using MENU secondary loader
Calling map_insert_data
Secondary loader: 18 sectors (0x3600 dataend).
bios_boot = 0x80 bios_map = 0x80 map==boot = 0 map S/N: 5879D4A8
BIOS data check was okay on the last boot
Boot image: /boot/vmlinuz -> vmlinuz-2.6.32-5-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
Setup length is 27 sectors.
Mapped 4708 sectors.
Added Lin_img0 *
<dev=0xe0,hd=227,cyl=182,sct=252>
"ro root=802"
Boot image: /boot/vmlinuz-2.6.26-2-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
Setup length is 24 sectors.
Mapped 3430 sectors.
Mapping RAM disk /boot/initrd.img-2.6.26-2-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
RAM disk: 15181 sectors.
Added Lin_2.6.26img2
<dev=0xe0,hd=227,cyl=183,sct=45>
"ro root=802"
Boot image: /boot/vmlinuz-2.6.31-1-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
Setup length is 27 sectors.
Mapped 4848 sectors.
Mapping RAM disk /boot/initrd.img-2.6.31-1-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
RAM disk: 7205 sectors.
Added Lin_2.6.31img3
<dev=0xe0,hd=227,cyl=183,sct=240>
"ro root=802"
Boot image: /boot/vmlinuz-2.6.32-3-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
Setup length is 27 sectors.
Mapped 4638 sectors.
Mapping RAM disk /boot/initrd.img-2.6.32-3-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
RAM disk: 7215 sectors.
Added Lin_2.6.32img4
<dev=0xe0,hd=227,cyl=184,sct=106>
"ro root=802"
Boot image: /boot/vmlinuz-2.6.32-5-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
Setup length is 27 sectors.
Mapped 4708 sectors.
Mapping RAM disk /boot/initrd.img-2.6.32-5-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
RAM disk: 9407 sectors.
Added Lin_2.6.32img5
<dev=0xe0,hd=227,cyl=184,sct=226>
"ro root=802"
Boot image: /boot/vmlinuz.old -> vmlinuz-2.6.32-3-amd64
Device 0x0802: BIOS drive 0x80, 255 heads, 30515 cylinders,
63 sectors. Partition offset: 120583890 sectors.
Using Volume ID 5879D4A8 on bios 80
Setup length is 27 sectors.
Mapped 4638 sectors.
Added Lin_img6
<dev=0xe0,hd=227,cyl=185,sct=113>
"ro root=802"
BIOS VolumeID Device
80 5879D4A8 0800
The boot sector and the map file have *NOT* been altered.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100925004...@windy.deldotd.com
Stephen Powell
> Stephen Powell put forth on 9/24/2010 4:06 PM:
>> Current stock Debian kernels for the
>> amd64 architecture are right on the ragged edge of being too
>> large for lilo to load below the 16M line
>
> And the bulk of these ~16MB stock kernels is the initrd, correct? Wow
> those are huge. I'm so glad I roll my own, from kernel.org source, and
> forgo the "kitchen sink" initrd setups of the stock kernels.
>
> -rw-r--r-- 1 root root 1.5M Jul 9 09:29 vmlinuz-2.6.34.1
> -rw-r--r-- 1 root root 490K Jul 9 09:29 System.map-2.6.34.1
> -rw-r--r-- 1 root root 29K Jul 9 09:29 config-2.6.34.1
>
> At my pace of kernel file growth, I won't hit the lilo 22.8 16MB limit
> for a few decades. :)
>
> Correct me if I'm wrong Stephen, but isn't this 16MB ceiling more of a
> block device controller BIOS limitation than a lilo limitation?
There are a couple of misconceptions here. It is true that the initial
RAM disk images on disk, when the default value of MODULES=most is
specified, are larger than the size of
the kernel image on disk. But that is not what I'm talking about.
I'm talking about the kernel itself. You see, the kernel image on disk,
which gets loaded by lilo into memory, is partially compressed.
That is, a small portion of the kernel code at the beginning of the
kernel is uncompressed, but the majority of it is compressed. That's
why the kernel image has the naming comvention vmlinuz-* instead of
vmlinux-*. (The initial RAM disk image on disk is compressed too.)
When lilo transfers control to the kernel, one of the first things
the kernel does is to decompress its compressed portion. From what
I can tell, it allocates some memory somewhere large enough to hold
the decompressed portion of itself, does the decompression, frees
the compressed portion of kernel memory, allocates a new chunk of
memory starting where the compressed portion resides and the same
size as the uncompressed hunk, copies the uncompressed hunk there,
and then frees the working copy of the uncompressed hunk. The net
effect is that the compressed kernel is "decompressed in place".
The compressed initial RAM file system image, also loaded by lilo,
has not yet been touched at this point. lilo tries to load the
compressed kernel image between the 1M line and the 15M line
(total 14M), even when large-memory is specified, at as low an
address as possible. lilo must determine whether the *decompressed*
kernel will fit in this space. If not, memory above 16M must be
used.
The compression ratio for an amd64-architecture kernel is significantly
higher than for an i386-architecture kernel. The current version
of lilo underestimates the uncompressed size of an amd64-architecture
kernel and may decide that the kernel will fit between 1M and 15M,
when in reality, it won't. This is especially likely if the compressed
initial RAM file system image is also being loaded in this space.
lilo 23.0 fixes this problem. The uncompressed sizes of stock
amd64 kernel images are quite large, and are close to the 14M limit
of below-16M loading. If the uncompressed kernel won't fit there,
then it must be loaded above 16M, even if the compressed image will fit
below 16M easily.
Some old BIOS do not support the BIOS calls that lilo, running in real
mode, uses to copy a block of memory above the 16M line. This can
be tested for using the lilo diagnostic diskette that I have posted
on my web site. But I am not aware of any 64-bit machines with this
restriction.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1689734423.261585.1285...@md01.wow.synacor.com
Stephen Powell
>
> Before I post all that stuff, let me show you exactly what's happening
> on boot. I think there is something very strange going on and it may
> not be lilo.
>
> Lin_img0 is : /boot/vmlinuz
>
> When I boot using that entry I get the following error:
>
> kernel-Panic: not syncing : VFS : Unable to mount root fs on unknown
> - block(8,2)
>
> specifying
>
> Lin_img0 root=/dev/sda2
>
> DOES NOT WORK.
After looking at your /etc/lilo.conf file, I'm not surprised. More later.
>
> When I use the lilo entry Lin_2.6.32img5, /boot/vmlinuz-2.6.32-5-amd64,
> AND specify root=/dev/sda2, i.e.
>
> Lin_2.6.32img5 root=/dev/sda2
>
> I get the following weirdness:
>
> Running /scripts/local-premount
>
> resume: could not stat the resume device
> file /dev/disk/by-uuid/558d7790-5914-4949....
>
> enter full path:
>
> at that point I enter /dev/sda2 and then it boots normally.
>
> don't have any idea what the uuid it's try to use is, but this is a
> real WTF !?
OK, I'm also goint to need to see the contents of
/etc/initramfs-tools/conf.d/resume.
I'm also going to need
to see the output of the following commands:
ls -Al /dev/disk/by-id/
ls -Al /dev/disk/by-uuid/
>
> 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.
Agreed.
>
> Here's a really interesting observation:
>
> The Lin_img0 lilo entry behaves differently from the Lin_2.6.32img5, BUT
> THEY BOTH USE THE SAME IMAGE ! /boot/vmlinuz is a symlink to
> vmlinuz-2.6.32-5-amd64.
>
> ugh...
That makes sense, given your config file.
>
> Stephen Powell wrote:
>> Interesting. What happens if you specify
>>
>> root=802
>>
>> as an argument to the boot prompt?
>
> I get the above resume weirdness.
Good. It's consistent. That means that the kernel is treating
root=/dev/sda2
and
root=802
as equivalent, which it should.
> Stephen Powell wrote:
>> Please post your entire /etc/lilo.conf.
>
> # Generated by liloconfig
>
> # This allows booting from any partition on disks with more than 1024
> # cylinders.
> lba32
>
> # Specifies the boot device
> boot=/dev/sda
>
>
> # Specifies the device that should be mounted as root.
> # If the special name CURRENT is used, the root device is set to the
> # device on which the root file system is currently mounted. If the root
> # has been changed with -r , the respective device is used. If the
> # variable ROOT is omitted, the root device setting contained in the
> # kernel image is used. It can be changed with the rdev program.
> root=/dev/sda2
>
> # Bitmap configuration for /boot/debianlilo.bmp
> # bitmap=/boot/debianlilo.bmp
> # bmp-colors=1,,0;9,,0
> # bmp-table=106p,144p,2,9,144p
> # bmp-timer=514p,144p,6,8,0
>
> # Enables map compaction:
> # Tries to merge read requests for adjacent sectors into a single
> # read request. This drastically reduces load time and keeps the map
> # smaller. Using COMPACT is especially recommended when booting from a
> # floppy disk.
> # compact
I would uncomment the above "compact" line for performance reasons,
but this is not your problem and it is not required.
>
> # Install the specified file as the new boot sector.
> # LILO supports built in boot sectory, you only need
> # to specify the type, choose one from 'text', 'menu' or 'bitmap'.
> # new: install=bmp old: install=/boot/boot-bmp.b
> # new: install=text old: install=/boot/boot-text.b
> # new: install=menu old: install=/boot/boot-menu.b or boot.b
> # default: 'menu' is default, unless you have a bitmap= line
> # Note: install=bmp must be used to see the bitmap menu.
> install=menu
> # install=bmp
>
> # Specifies the number of _tenths_ of a second LILO should
> # wait before booting the first image. LILO
> # doesn't wait if DELAY is omitted or if DELAY is set to zero.
> # delay=50
>
> # Prompt to use certaing image. If prompt is specified without timeout,
> # boot will not take place unless you hit RETURN
> prompt
> timeout=50
>
> # Enable large memory mode.
> large-memory
Good!
>
> # Specifies the location of the map file. If MAP is
> # omitted, a file /boot/map is used.
> map=/boot/map
>
> # Specifies the VGA text mode that should be selected when
> # booting. The following values are recognized (case is ignored):
> # NORMAL select normal 80x25 text mode.
> # EXTENDED select 80x50 text mode. The word EXTENDED can be
> # abbreviated to EXT.
> # ASK stop and ask for user input (at boot time).
> # <number> use the corresponding text mode. A list of available modes
> # can be obtained by booting with vga=ask and pressing [Enter].
> vga=normal
>
> # Defines non-standard parameters for the specified disk.
>
> # If you are using removable USB drivers (with mass-storage)
> # you will need to tell LILO to not use these devices even
> # if defined in /etc/fstab and referenced in /proc/partitions.
> # Adjust these lines to your devices:
> #
> # disk=/dev/sda inaccessible
>
> # These images were automagically added. You may need to edit something.
>
> image=/boot/vmlinuz
> label="Lin img0"
> read-only
>
ERROR! No initial RAM disk specified! Add:
initrd=/boot/initrd.img
> image=/boot/vmlinuz-2.6.26-2-amd64
> label="Lin 2.6.26img2"
> initrd=/boot/initrd.img-2.6.26-2-amd64
> read-only
>
> image=/boot/vmlinuz-2.6.31-1-amd64
> label="Lin 2.6.31img3"
> initrd=/boot/initrd.img-2.6.31-1-amd64
> read-only
>
> image=/boot/vmlinuz-2.6.32-3-amd64
> label="Lin 2.6.32img4"
> initrd=/boot/initrd.img-2.6.32-3-amd64
> read-only
>
> image=/boot/vmlinuz-2.6.32-5-amd64
> label="Lin 2.6.32img5"
> initrd=/boot/initrd.img-2.6.32-5-amd64
> read-only
>
> image=/boot/vmlinuz.old
> label="Lin img6"
> read-only
>
ERROR! No initial RAM disk image. Add:
initrd=/boot/initrd.img.old
> # If you have another OS on this machine (say DOS),
> # you can boot if by uncommenting the following lines
> # (Of course, change /dev/hda2 to wherever your DOS partition is.)
> # other=/dev/hda2
> # label="MS Windows"
>
> Stephen Powell wrote:
>> Also post:
>> /etc/kernel-img.conf
>
Where is it? I need to see the contents of that file.
It's very important.
> Stephen Powell wrote:
>> A list of all files in /etc/kernel/postinst.d
>
> -rwxr-xr-x 1 root root 436 Jun 4 06:33 dkms
> -rwxr-xr-x 1 root root 614 Apr 7 20:53 initramfs-tools.dpkg-dist
> -rwxr-xr-x 1 root root 196 Mar 18 2010 pm-utils
> -rwxr-xr-x 1 root root 1607 Apr 3 21:22 S30initramfs
> -rwxr-xr-x 1 root root 3355 Jul 14 22:33 S50symlink_hook
>
> Stephen Powell wrote:
>> A list of all files in /etc/kernel/postrm.d
>
> -rwxr-xr-x 1 root root 563 Apr 7 20:53 initramfs-tools.dpkg-dist
> -rw-r--r-- 1 root root 1662 Apr 3 21:24 K30initramfs
> -rw-r--r-- 1 root root 3390 Apr 3 21:27 K50symlink_hook
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.
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
do_symlinks = no
is set in /etc/kernel-img.conf. Also erase any of the following symbolic
links, if they exist, from the root directory:
vmlinuz
initrd.img
vmlinuz.old
initrd.img.old
Looks OK.
> Stephen Powell wrote:
>> The definitions of the boot-related symlinks:
>>
>> vmlinuz
>> initrd.img
>> vmlinuz.old
>> initrd.img.old
>>
>
> lrwxrwxrwx 1 root root 25 Jul 14 22:38 initrd.img ->
> initrd.img-2.6.32-5-amd64
>
> lrwxrwxrwx 1 root root 25 Jul 14 22:38 initrd.img.old ->
> initrd.img-2.6.32-3-amd64
>
> lrwxrwxrwx 1 root root 22 Jul 14 22:38 vmlinuz ->
> vmlinuz-2.6.32-5-amd64
>
> lrwxrwxrwx 1 root root 22 Jul 14 22:38 vmlinuz.old ->
> vmlinuz-2.6.32-3-amd64
Looks good. I'm assuming that they are in the /boot directory.
Looks good. Obviously, you also used the -t option as well.
Oh, I almost forgot. Another file I need to see is
/etc/fstab
So please make the changes indicated and post the additional
information requested, which is scattered throughout this post.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1943327589.266159.1285...@md01.wow.synacor.com
bri...@aracnet.com
Stephen Powell <zlin...@wowway.com> wrote:
> On Sat, 25 Sep 2010 03:40:04 -0400 (EDT), bri...@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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100926191...@windy.deldotd.com
bri...@aracnet.com
Stephen Powell <zlin...@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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100926192...@windy.deldotd.com
Stephen Powell
>>
>> 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
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.
>
> 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
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1149458522.286368.1285...@md01.wow.synacor.com
Stephen Powell
As I indicated in my previous post, you need to remove those last
two lines from /etc/kernel-img.conf, the ones which have "lilo-update"
in them. That will solve the above problem.
>>
>> 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
do_symlinks = no
is set in /etc/kernel-img.conf.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1802866504.286767.1285...@md01.wow.synacor.com
bri...@aracnet.com
Stephen Powell <zlin...@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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100926182...@windy.deldotd.com
bri...@aracnet.com
Stephen Powell <zlin...@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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100926182...@windy.deldotd.com
Stephen Powell
>
> 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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1884665001.298704.1285...@md01.wow.synacor.com
bri...@aracnet.com
Stephen Powell <zlin...@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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100927181...@windy.deldotd.com
Stephen Powell
> 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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1980597816.332928.1285...@md01.wow.synacor.com
bri...@aracnet.com
Stephen Powell <zlin...@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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20101002105...@windy.deldotd.com
Stephen Powell
> 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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1073334106.449362.1286...@md01.wow.synacor.com
Tom H
>
> 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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTikP0Fxukvz-9EU6U...@mail.gmail.com