Re: Cannot boot with latest Lenny kernel 2.6.26
On Tue, Nov 25, 2008 at 01:16:13PM -0800, Neil Gunton wrote:
> 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 remember seeing some requests about getting dpt_i2o to work on amd64,
since apparently some people prefer it.
> 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
Preferably change the #kopt= line, since that way kernel updates will
run 'update-grub' which then populates all the entries. So if you
change the #kopt line, and run update-grub, they all change.
For testing, changing one test entry and trying it is a good start.
> 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 ?
That's right.
> 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?
Run blkid on the current device to get the UUID. Or use a label. I
tend to have swap on LVM, so LVM uses UUID's and I get a fixed name for
the swap volume.
> 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.
That's it.
You can always boot no matter what fstab says. At worst fsck complains.
--
Len Sorensen
Reply to: