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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
