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: 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. 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. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't.
signature.asc
Description: This is a digitally signed message part
