[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cannot boot with latest Lenny kernel 2.6.26



On Tuesday 25 November 2008 19:16:13 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 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 ?

AFAICS, that's it.

> 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?

I've checked in one my servers, and there's no uuid for the swap partition.
Don't know why, but it doesn't seem to be important. :)

> 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.

I usually go with uuids in all hds, except the one that holds / (which usually 
also holds /boot).
I've seen enough complaints about unbootable machines that used uuids to point 
the boot disk/partition, and got afraid of it. :)

/dev/hda2		/	ext3		defaults		0	1
UUID=be5463be-af72-4526-ac2d-2efba4c7babf	/export/home	ext3	defaults	0	2

Good luck !


Reply to: