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

Bug#826999: marked as done (Kernel build scripts confused by entries for SCSI devices in /proc/mounts)

Your message dated Sat, 8 May 2021 16:32:21 +0200
with message-id <YJag9QE5whmEIQmT@eldamar.lan>
and subject line Re: Bug#588675: Beginings of Heading Towards a Root Cause of #588675
has caused the Debian Bug report #588675,
regarding Kernel build scripts confused by entries for SCSI devices in /proc/mounts
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
588675: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588675
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: src:linux
Version: 3.2.63-2
Control: found -1 linux/2.6.18
Control: found -1 linux/3.16.7-ckt25-2
Control: found -1 linux/3.16.7-ckt20-1+deb8u3
Control: found -1 linux/3.2.78-1
Control: found -1 linux/3.16.7-ckt11-1+deb8u6~bpo70+1
Control: found -1 linux/2.6.32

The kernel build scripts are confused by what the SCSI subsystem produces
in /proc/mounts:

$ awk '$2 == "/" && $1 != "rootfs"' < /proc/mounts
/dev/root / ext3 ro
$ 

A kernel build on such a system will panic on boot unless the root
filesystem is explicitly passed to the kernel by the bootloader.  While
in common configurations bootloaders generally default to telling the
kernel what device it should use as root, that has not been documented to
be required.

Since Ben Hutchings thinks #588675 is too insignificant to ever be worthy
of a single line of code to fix, this bug now needs to be fixed (along
with many other utilities that are broken by #588675).


-- 
(\___(\___(\______          --=> 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

--- End Message ---
--- Begin Message --- 
Hi,

On Thu, Jun 16, 2016 at 06:53:32PM -0700, Elliott Mitchell wrote:
> For some time I'd been trying to search for a cause of #588675.  Looks
> like I finally searched for the right string (problem is "root" occurs in
> many places inside the Linux kernel source).
> 
> Looks like the key file is linux/init/do_mounts.c:
> 
> Appears the line:
> 		ROOT_DEV = name_to_dev_t(root_device_name);
> inside prepare_namespace() resolves any specified root device into
> major/minor.  Later at the end of mount_root(), /dev/root is created with
> the appropriate major/minor, but mount_root() never tries to resolve the
> major/minor back into a proper device name.
> 
> The two spots that I've gotten hints of potentially being able to get
> back the proper device name are: Inside do_mount_root(), s->s_id is
> "sda1", but I'm a bit worried that may not work in cases with LVM where
> the proper result could have been "scsi0/target0/<long string of dirs>".
> The other is potentially doing bdevname(bdget(ROOT_DEV), char_buffer)
> may give something approximating a proper name.
> 
> >From looking at the current code, I suspect while this behavior may have
> first appeared with SCSI devices, it may well have spread to all block
> devices other than MTD and UBI (commonly being embedded devices with
> memory completely inadequate to hold an initial ramdisk, users of MTD
> device roots would have screamed too loudly to ignore).  So I got that
> wrong.
> 
> If things go well, I may have a patch soon (alas, I'm also having to
> fight other issues as well, so that could take a while).

Closing this bugreport as for the above I think was no further
followup. Please reopen if you disagree.

Rgards,
Salvatore

--- End Message ---
Reply to: