From: Stephen Powell on
OK, I'm sure it must be something simple, but I can't figure out what.

I am running the "testing" release (Squeeze).
I have two stock Debian kernels installed on my system:
linux-image-2.6.32-3-686 and linux-image-2.6.32-5-686.
My computer has a single hard disk, a traditional ATA IDE drive,
also known as "PATA". One important difference between these
two kernels is that the -3 kernel uses the old IDE drivers,
which results in my hard disk device name being /dev/hda.
The -5 kernel uses the newer libata driver, which results in
my hard disk device name being /dev/sda. In other words,
the newer kernel uses a SCSI device naming convention instead of
the traditional IDE device naming convention.

When I first installed the 2.6.32-5 kernel, it was from unstable,
but this kernel has since migrated to testing. I didn't like
all the UUID changes that the dependencies of this kernel package
wanted to make and instead changed all my system files (/etc/fstab,
/etc/initramfs-tools/conf.d/resume, and /etc/lilo.conf) to use
the new SCSI device naming conventions. After some initial
issues with the nouveau driver, I have been running the -5
kernel successfully for some time.

Recently, however, for the purpose of testing some software,
I decided I wanted to boot my old kernel (the -3 kernel).
I knew that I would have to make some changes to the system
files first, however. I decided to make use of udev aliases
in these system files. For example, in /etc/fstab, instead of
something like

/dev/sda1

I used something like

/dev/disk/by-uuid/04db5929-51e6-424a-ac5b-a592b96b9d04

After making changes of this nature to /etc/lilo.conf, /etc/fstab,
and /etc/initramfs-tools/conf.d/resume, I rebuilt the initial
RAM file systems for both kernels with "update-initramfs -uk all"
while running the -5 kernel. Everything appeared to work fine.
I then shutdown and rebooted my current kernel (the -5 kernel).
It booted just fine. I then tried to boot my old kernel (the -3
kernel). It failed. The kernel and initial RAM file system
were loaded just fine by the boot loader, but the -3 kernel
couldn't make the switch between the initial RAM file system and
the permanent root file system. I got a few "device not found"
error messages and it left me in an ash shell with "(initramfs)"
as the boot prompt.

What did I do wrong? Is there a system file that I missed?
Is this a missed dependency in the dependency-based boot system?
I can still boot the -5 kernel just fine, but I can't get the
-3 kernel to boot. I tried searching the internet with the
search words

Debian 2.6.32-3 2.6.32-5 "(initramfs)" "won't boot"

but none of the hits looked promising to me.

Any ideas? My hunch is that the udev aliases might not yet
exist at the time they are being referenced. But that's just
a wild guess at this point. The thing is though, it works fine
for the -5 kernel.

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


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/266421654.228790.1277306098638.JavaMail.root(a)md01.wow.synacor.com
From: Tom H on
On Wed, Jun 23, 2010 at 11:14 AM, Stephen Powell <zlinuxman(a)wowway.com> wrote:
> OK, I'm sure it must be something simple, but I can't figure out what.
>
> I am running the "testing" release (Squeeze).
> I have two stock Debian kernels installed on my system:
> linux-image-2.6.32-3-686 and linux-image-2.6.32-5-686.
> My computer has a single hard disk, a traditional ATA IDE drive,
> also known as "PATA".  One important difference between these
> two kernels is that the -3 kernel uses the old IDE drivers,
> which results in my hard disk device name being /dev/hda.
> The -5 kernel uses the newer libata driver, which results in
> my hard disk device name being /dev/sda.  In other words,
> the newer kernel uses a SCSI device naming convention instead of
> the traditional IDE device naming convention.
>
> When I first installed the 2.6.32-5 kernel, it was from unstable,
> but this kernel has since migrated to testing.  I didn't like
> all the UUID changes that the dependencies of this kernel package
> wanted to make and instead changed all my system files (/etc/fstab,
> /etc/initramfs-tools/conf.d/resume, and /etc/lilo.conf) to use
> the new SCSI device naming conventions.  After some initial
> issues with the nouveau driver, I have been running the -5
> kernel successfully for some time.
>
> Recently, however, for the purpose of testing some software,
> I decided I wanted to boot my old kernel (the -3 kernel).
> I knew that I would have to make some changes to the system
> files first, however.  I decided to make use of udev aliases
> in these system files.  For example, in /etc/fstab, instead of
> something like
>
>   /dev/sda1
>
> I used something like
>
>   /dev/disk/by-uuid/04db5929-51e6-424a-ac5b-a592b96b9d04
>
> After making changes of this nature to /etc/lilo.conf, /etc/fstab,
> and /etc/initramfs-tools/conf.d/resume, I rebuilt the initial
> RAM file systems for both kernels with "update-initramfs -uk all"
> while running the -5 kernel.  Everything appeared to work fine.
> I then shutdown and rebooted my current kernel (the -5 kernel).
> It booted just fine.  I then tried to boot my old kernel (the -3
> kernel).  It failed.  The kernel and initial RAM file system
> were loaded just fine by the boot loader, but the -3 kernel
> couldn't make the switch between the initial RAM file system and
> the permanent root file system.  I got a few "device not found"
> error messages and it left me in an ash shell with "(initramfs)"
> as the boot prompt.
>
> What did I do wrong?  Is there a system file that I missed?
> Is this a missed dependency in the dependency-based boot system?
> I can still boot the -5 kernel just fine, but I can't get the
> -3 kernel to boot.  I tried searching the internet with the
> search words
>
>   Debian 2.6.32-3 2.6.32-5 "(initramfs)" "won't boot"
>
> but none of the hits looked promising to me.
>
> Any ideas?  My hunch is that the udev aliases might not yet
> exist at the time they are being referenced.  But that's just
> a wild guess at this point.  The thing is though, it works fine
> for the -5 kernel.

IIUC, linux-image-2.6.32-3-686 uses hdX and linux-image-2.6.32-5-686
uses sdX so wouldn't your update-initramfs have updated your
linux-image-2.6.32-3-686 initrd with sdX device names?


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/AANLkTim0guRg1bxPUTNWJGd6aTILv6AW3QXkjfwaDOcM(a)mail.gmail.com
From: Stephen Powell on
On Wed, 23 Jun 2010 12:35:50 -0400 (EDT), Tom H wrote:
> On Wed, Jun 23, 2010 at 11:14 AM, Stephen Powell <zlinuxman(a)wowway.com> wrote:
>> ...
>> I then tried to boot my old kernel (the -3
>> kernel).  It failed.  The kernel and initial RAM file system
>> were loaded just fine by the boot loader, but the -3 kernel
>> couldn't make the switch between the initial RAM file system and
>> the permanent root file system.
>> ...
>
> IIUC, linux-image-2.6.32-3-686 uses hdX and linux-image-2.6.32-5-686
> uses sdX so wouldn't your update-initramfs have updated your
> linux-image-2.6.32-3-686 initrd with sdX device names?

No. I changed the /dev/sdX device names to uuid udev aliases in
/etc/fstab, /etc/lilo.conf, and /etc/initramfs-tools/conf.d/resume
prior to issuing "update-initramfs -uk all". And these alias
names should exist in the -3 kernel too. As an example, I changed

/dev/sda1

to something like

/dev/disk/by-uuid/04db5929-51e6-424a-ac5b-a592b96b9d04

udev under the -5 kernel creates a symbolic link by this name to
/dev/sda1. udev under the -3 kernel creates a symbolic link by
this name to /dev/hda1. Or at least it should.

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


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/194912053.232939.1277313731254.JavaMail.root(a)md01.wow.synacor.com
From: Camaleón on
On Wed, 23 Jun 2010 13:22:11 -0400, Stephen Powell wrote:

> On Wed, 23 Jun 2010 12:35:50 -0400 (EDT), Tom H wrote:

>> IIUC, linux-image-2.6.32-3-686 uses hdX and linux-image-2.6.32-5-686
>> uses sdX so wouldn't your update-initramfs have updated your
>> linux-image-2.6.32-3-686 initrd with sdX device names?
>
> No. I changed the /dev/sdX device names to uuid udev aliases in
> /etc/fstab, /etc/lilo.conf, and /etc/initramfs-tools/conf.d/resume prior
> to issuing "update-initramfs -uk all". And these alias names should
> exist in the -3 kernel too.

So, all entries in "/etc/lilo.conf" are pointing to "uuid" devices or
just the ones loading the "-3" kernel?

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/pan.2010.06.23.17.33.16(a)gmail.com
From: Stephen Powell on
On Wed, 23 Jun 2010 13:33:16 -0400 (EDT), Camaleón wrote:
>
> So, all entries in "/etc/lilo.conf" are pointing to "uuid" devices or
> just the ones loading the "-3" kernel?

There are only two lines in /etc/lilo.conf that are relevant:
boot and root. Both are in the global section, not in a per-image
section. And since I have lilo's first stage loader installed in the
boot sector of a primary partition that has been formatted with a Linux
file system that assigns a UUID, the partition has a /dev/disk/by-uuid alias.
(If lilo were installed in the master boot record, I couldn't do this,
since the master boot record does not have a /dev/disk/by-uuid alias.)
So yes, "all the entries" are pointing to "uuid" devices.

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


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/806041989.233947.1277316293335.JavaMail.root(a)md01.wow.synacor.com