From: Stephen Powell on 23 Jun 2010 11:20 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 23 Jun 2010 12:40 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 23 Jun 2010 13:30 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 23 Jun 2010 13:40 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 23 Jun 2010 14:10 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
|
Next
|
Last
Pages: 1 2 3 Prev: Unidentified subject! Next: Req. Advice from Lazy Web on Configuring 1.5TB extern. HD |