Bug#790722: mkinitramfs fails with latest udev (>= 220-7) on some systems
On Wed, 01 Jul 2015 14:05:57 -0400 (EDT), Ben Hutchings wrote: > > Please note that i2o will be going away entirely (disabled in 4.0, > removed upstream in 4.2). Thanks, Ben, I hadn't heard that; but it really doesn't have anything to do with this bug, per se. I happened to discover it using an i2o RAID device on i386 using lilo. But this bug can happen with any disk device, on any hardware platform, and with any boot loader. All one need do to expose it is to supply the "root" parameter on the kernel command line, specifying the root file system as a kernel composite device number, such as root=801 If you do this, and if you use MODULES=dep, and if udev is at version 220-7, then mkinitramfs (and update-initramfs), performed during this boot session, will fail. I've done a little more research, and I suggest using udevadm, instead of udevd, as the command to look for. You already make use of this command elsewhere in initramfs-tools. The fix for this problem is a canonical (pardon the pun) one-line change. Simply change if command -v udevd >/dev/null 2>&1; then to if command -v udevadm >/dev/null 2>&1; then in the parse_numeric function. Problem solved. And yes, I realize that using disk labels or uuids is the recommended way to specify the root file system these days. But that's another story, as I mentioned earlier. Respectfully yours, -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1967416753.5648099.1435795665776.javamail.zim...@wowway.com
Bug#790808: linux: Please enable CONFIG_MMIOTRACE
Source: linux Severity: wishlist Dear Maintainer, Please enable CONFIG_MMIOTRACE. mmiotrace can provide very valuable information to the nouveau developers. But to enable that, we currently need to rebuild the kernel, and rebuild the nvidia blob against it. >From ubuntu: Enable MMIOTRACE to allow us to trace low level card operations. This is commonly used to debug graphics issues particularly under Nouveau. According to the documentation it is a near zero impact when disabled -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150701205332.27242.22394.report...@satlan.zlatograd.net
Bug#790722: mkinitramfs fails with latest udev (>= 220-7) on some systems
On Wed, 2015-07-01 at 03:39 -0400, Stephen Powell wrote: > Package: initramfs-tools > Version: 0.120 > Severity: normal > > A recent upgrade of my stretch system via > >apt-get upgrade > > failed with > >mkinitramfs: failed to determine device for / > > I run with MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy. My > system > uses an i2o hardware RAID device, device major number 80 (decimal) and device > minor number 0, with user-space name /dev/i2o/hda. The root partition is > /dev/i2o/hda6 (device minor number 6). [...] Please note that i2o will be going away entirely (disabled in 4.0, removed upstream in 4.2). Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#790722: mkinitramfs fails with latest udev (>= 220-7) on some systems
Package: initramfs-tools
Version: 0.120
Severity: normal
A recent upgrade of my stretch system via
apt-get upgrade
failed with
mkinitramfs: failed to determine device for /
I run with MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy. My system
uses an i2o hardware RAID device, device major number 80 (decimal) and device
minor number 0, with user-space name /dev/i2o/hda. The root partition is
/dev/i2o/hda6 (device minor number 6).
The main culprit seems to be the new udev at release 220-7. I have tried the
sid version also at 221-1 with no better luck. However, initramfs-tools
may be partially at fault.
udev has 2 major deficiencies, from my perspective:
(1) The symbolic links in /dev/disk/by-uuid and /dev/disk/by-label are no
longer being created at boot time. I don't know why they aren't being created,
but they should be.
(2) The new udev does not contain a command called udevd.
I was able to work around the first problem by changing /etc/fstab,
/etc/initramfs-tools/conf.d/resume, and /etc/lilo.conf to use traditional
block special file names (/dev/i2o/hda6, etc.) instead of uuids (UUID=...).
(I use lilo as my boot loader.) This is a regression from recommended practice,
but I must have a functioning system.
The second problem causes a problem for initramfs-tools. The parse_numeric
function in /usr/share/initramfs-tools/scripts/functions has code in it which
looks like this:
if command -v udevd >/dev/null 2>&1; then
ROOT=/dev/block/${major}:${minor}
else
mknod -m 600 /dev/root b ${major} ${minor}
ROOT=/dev/root
fi
Obviously, initramfs-tools is testing for the existence of udev by checking
to see if there is a command available called udevd. If not, then it assumes
that there is no udev. Older releases of udev contained this command. udev
220-7 (and above) does not. As a temporary kludge, I have changed the first
line
of the above to
if command -v udevd >/dev/null 2>&1; :; then
which causes the "if" test to always test true, resulting in the correct code
path. I had to change MODULES=dep to MODULES=most temporarily, but after
building the initramfs, shutting down, and rebooting, I was able to change back
to MODULES=dep and successfully build an initial RAM file system with
MODULES=dep.
The system then boots correctly using the smaller initial RAM file system image.
Either it is a bug for udev to be missing the udevd command, or initramfs-tools
needs to find another way to determine if udev is present. I plan to eventually
report a bug in udev, but I need to do more research first, and my first goal
was to get my system running again. Thus this bug report came first.
By the way, I am still hoping to get my parse_numeric patch, available at
http://users.wowway.com/~zlinuxman/kernel/parse_numeric.patch, included in
initramfs-tools. The current code cannot handle a kernel composite device
number
greater than 0xf. With the patch, it should be able to handle any valid
kernel composite device number.
Respectfully submitted,
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1993869501.4988405.1435736347189.javamail.zim...@wowway.com
Bug#790660: thinkpad yoga sometimes fails to suspend when xhci-pci is loaded
On Tue, Jun 30, 2015 at 06:25:42PM +0200, Bastian Blank wrote: > You have several modules loaded that are not supported. You want to try > it without first. i've blacklisted those modules, even purged them -- still, when i reboot, my kernel is tainted 4096 (O) after login; at that time, no out-of-tree modules are loaded. i'd happily provide test results with a completely untainted kernel, but as things are, i don't know how to boot into one. (there doesn't happen to be a kernel option to have it reject tainting modules, does there?) even under the current circumstances, the issue is the same. (i noticed that the fan *does* stop spinning as opposed to my original problem report, but i'd rather attribut that to erroneous observation.) best regards chrysn signature.asc Description: Digital signature
