On Mon, Jan 05, 2015 at 03:17:28AM +0000, Ben Hutchings wrote: > Control: reassign -1 src:linux 3.2.63-2 > Control: retitle -1 / left as /dev/root with non-initrd kernel > Control: severity -1 wishlist > Control: tag -1 upstream wontfix > > On Sun, 2015-01-04 at 16:02 -0800, Elliott Mitchell wrote: > [...] > > The two crucial ingredients for reproducing this bug, the system must > > boot directly onto the root device (no initrd) and the root device must > > be something that plugs into the SCSI subsystem. > [...] > > This does NOT effect older kernels when booting onto IDE subsystem disks > > (/dev/hd* with newer kernels IDE disks go through the SCSI subsystem and > > are likely effected). This does not effect systems which initially mount > > *any* other device as root, and subsequently chroot onto a SCSI subsystem > > device (this explains why initrd system are uneffected). > [...] > > I don't see why the driver would matter. Since at least the beginning > of git history (2.6.12), when you use the root= parameter to boot > directly from a block device, the kernel has done:
I'm also surprised about the driver making such a difference, but observation has demonstrated it clearly does. Prior to hardware replacement I'd been using a system with an IDE^WPATA disk which used the olde IDE subsystem and /dev/hda1 appeared in /proc/mounts. Notice my prior message I mentioned with a 3.2 kernel a device that mounts /dev/mtdblock2 (without any initrd) as root filesystem, and /dev/mtdblock2 appears correctly in /proc/mounts. Since the SCSI subsystem is in common with the observed occurances, I must point my finger towards *something* being messed up with the SCSI subsystem. > 1. Mount rootfs (which is really either tmpfs or ramfs) at / > 2. Create directories /dev and /root, and block device /dev/console > 3. Create block device node /dev/root for the specified block device > 4. Mount /dev/root at /root > 5. Move-mount /root to / (hiding the tmpfs/ramfs) > > What *has* changed is that /etc/mtab is now a symlink to /proc/mounts > and therefore the root device name recorded there is not affected by > /etc/fstab. No, that is not where the problem occurs. Back when I was running on the system with IDE disk, /etc/mtab was already a symbolic link to /proc/mounts, yet the issue did not occur. My first observation of the problem corresponds with when I'd installed a PCI SATA card in a system and using the exact same filesystem image, except for rebuilding the kernel with SATA support. > None of this is likely to change, so if you don't want to use an > initramfs then you'd better create a symlink called /dev/root on your > root filesystem. Userspace (I /think/, maybe this too is inside the kernel?) has already been creating /dev/root for a long time. While this only causes mild corruption of output, it causes it in *many* programs. Either this *kernel* *bug* needs to be fixed inside the kernel, or I'm going have to report many bugs against the many programs which display bad output. Again, a computer with /dev/mtdblock2 as root device, directly mounts /dev/mtdblock2 just fine and lists "/dev/mtdblock2" in /proc/mounts just fine. That sounds very much like a (perhaps fairly minor) SCSI subsystem bug. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
