Bug#588675: Narrowing on location of bug #588675
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+sigmsg@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Reply to: