Re: Cannot boot with latest Lenny kernel 2.6.26
Lennart Sorensen wrote:
On Tue, Nov 25, 2008 at 11:55:59AM -0800, Neil Gunton wrote:
My server is a dual Opteron 265, 4GB RAM, 4x10k SCSI drives in RAID0 on
an Adaptec zero channel SmartRaid V card (the drive appears as
/dev/i2o/hda1, so it's using the i2o_block driver).
I am running fully up-to-date Debian Lenny, using the AMD64 port.
I cannot boot with the latest kernel - 2.6.26.1. It stops early on, just
after detecting disks, with this line:
Begin: Waiting for root file system...
It just hangs there.
The last "good" kernel that works is 2.6.25.2. I haven't tweaked
anything, these are both the stock build AMD64 kernels. I'm fairly
certain this is a bug of some kind, since everything works ok with the
earlier kernel. Things seemed to break going from 2.6.25 to 2.6.26.
I am wondering if anyone else is having this issue, if it's a known bug,
or something that I need to enter as a bug. Can anybody help?
Well one change for I2O between 2.6.25 and 2.6.25 is this:
mythtv64:~# grep I2O /boot/config-2.6.26-1-amd64
CONFIG_SCSI_DPT_I2O=m
CONFIG_I2O=m
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
mythtv64:~# grep I2O /boot/config-2.6.25-2-amd64
CONFIG_I2O=m
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
So CONFIG_SCSI_DPT_I2O is now enabled. If that happens to have anything
to do with your I2O device, perhaps it is causing a different driver
name to be used or maybe it is causing interference.
Everything else looks the same of course.
Hitting control-c or alt+sysrq+i a few times might drop you to a shell
where you can see what devices if any for disk access have been detected
by the initramfs so far.
If the drive name does change, I often find it much better to use UUID
rather than device names in grub and fstab.
ie:
root=/dev/sda1
becomes:
root=UUID=abce-2312323-ssasdads
Similar in fstab.
That way the device names can do whatever they want and you still find
the right filesystems for the right places.
Hi Len,
This sounds promising - it would seem to make sense that if a different
driver is being used in 2.6.26.1, then /dev/i2o/hda1 might not work any
more if dpt_i2o is being used rather than i2o_block.
Does anyone know why the switch was made? I thought the "community" had
decided to use i2o_block over dpt_i2o a while back, since i2o_block was
being maintained, while dpt_i2o wasn't being maintained any more by Adaptec.
I am a little concerned to get this right, since the server is remote
(in Chicago, I'm thousands of miles away in Oregon), and I don't want to
risk making a non-bootable machine, or have to pay expensive datacenter
people to do things for me to recover.
So, let me get this straight. I get the UUID thus:
shell> ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 14 Nov 20 20:18
eb128018-0e0e-4158-8337-5a433c391cc4 -> ../../i2o/hda1
So in /boot/grub/menu.lst, I replace the following line:
kernel /boot/vmlinuz-2.6.26-1-amd64 root=/dev/i2o/hda1 ro
... with this:
kernel /boot/vmlinuz-2.6.26-1-amd64 \
root=UUID=eb128018-0e0e-4158-8337-5a433c391cc4 ro
Is that right? (all on one line, of course)
Then, in /etc/fstab, I currently have:
proc /proc proc defaults 0 0
/dev/i2o/hda1 / ext2 noatime,errors=remount-ro 0 1
/dev/i2o/hda2 none swap sw 0 0
/dev/hda /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
So do I simply change the /dev/i2o/hda1 to read
UUID=eb128018-0e0e-4158-8337-5a433c391cc4 ?
But then, how about the swap? It didn't come up in the list of UUIDs,
presumably it will be different as well if dpt_i2o is being used? What
do I change that to?
Is those two files (/boot/grub/menu.lst and /etc/fstab) all I need to
change here? I'm particularly concerned about /etc/fstab, since when I
change that, it affects boot even if I want to go back to my working
kernel. If I mess up fstab, then I get a non-bootable machine, not good.
Thanks!
Neil
Reply to: