Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Here is another draft patch for hw-detect. This one is tested, and find the missing firmware on my X200 test laptop. This approach keep the non-functioning code and add two new approaches, one looking at the meta information for loadmed modules, and one parsing the dmesg output. The union from all three methods are then presented as the list of wanted firmware. diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh index 60c6ff4..74db55b 100755 --- a/check-missing-firmware.sh +++ b/check-missing-firmware.sh @@ -61,6 +61,18 @@ nic_is_configured() { return 1 } +add_if_fw_missing() { +fwfile=$1 +if [ ! -e /lib/firmware/$fwfile ] ; then +if grep -q ^$fwfile$ $DENIED 2/dev/null; then + log listed in $DENIED +continue +fi +files=${files:+$files }$fwfile +modules=$module${modules:+ $modules} +fi +} + check_missing () { upnics @@ -117,11 +129,30 @@ check_missing () { done done +# Workaround for bug #725714, the kernel and udev no longer +# let us know via /dev/.udev/firmware-missing and +# /run/udev/firmware-missing which firmware files the kernel +# drivers look for. This approach will only find firmware for +# the loaded kernel modules. Modules refusing to +# register/load when the firmware is missing will be missed. +for module in $(cut -d -f1 /proc/modules); do +for fwfile in $(modinfo $module | grep ^firmware: | cut -d: -f2); do +log looking for firmware file $fwfile needed by $module +add_if_fw_missing $fwfile +done +done +for fwfile in $(dmesg | grep 'firmware: failed' | sed 's/.*firmware: failed to load //' | cut -d -f1); do +# Dummy make sure '-n $modules' test below find something +module=kernel +log looking for firmware file $fwfile requested by kernel +add_if_fw_missing $fwfile +done + if [ -n $modules ]; then log missing firmware files ($files) for $modules return 0 else - log no missing firmware in $MISSING + log no missing firmware for any kernel module return 1 fi } -- Happy hacking Petter Reinholdtsen -- 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/20141007135247.gp10...@ulrik.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
On Tue, 2014-10-07 at 15:52 +0200, Petter Reinholdtsen wrote: Here is another draft patch for hw-detect. This one is tested, and find the missing firmware on my X200 test laptop. This approach keep the non-functioning code The firmware agent is never coming back, so please do remove the related code. and add two new approaches, one looking at the meta information for loadmed modules, and one parsing the dmesg output. The union from all three methods are then presented as the list of wanted firmware. diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh index 60c6ff4..74db55b 100755 --- a/check-missing-firmware.sh +++ b/check-missing-firmware.sh [...] @@ -117,11 +129,30 @@ check_missing () { done done +# Workaround for bug #725714, the kernel and udev no longer +# let us know via /dev/.udev/firmware-missing and +# /run/udev/firmware-missing which firmware files the kernel +# drivers look for. This belongs in the changelog not the code. This approach will only find firmware for +# the loaded kernel modules. Modules refusing to +# register/load when the firmware is missing will be missed. +for module in $(cut -d -f1 /proc/modules); do +for fwfile in $(modinfo $module | grep ^firmware: | cut -d: -f2); do +log looking for firmware file $fwfile needed by $module +add_if_fw_missing $fwfile +done +done +for fwfile in $(dmesg | grep 'firmware: failed' | sed 's/.*firmware: failed to load //' | cut -d -f1); do Redundant use of grep; sed can do that (sed -n 's/.../.../p'). +# Dummy make sure '-n $modules' test below find something +module=kernel The driver name should appear at the start of the log line (after the timestamp). Use that instead of 'kernel'. +log looking for firmware file $fwfile requested by kernel +add_if_fw_missing $fwfile +done + Indentation of the above is inconsistent with the surrounding code (4 spaces vs hard tab). Ben. if [ -n $modules ]; then log missing firmware files ($files) for $modules return 0 else - log no missing firmware in $MISSING + log no missing firmware for any kernel module return 1 fi } -- Happy hacking Petter Reinholdtsen -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Thank you for the code review. :) [Ben Hutchings] The firmware agent is never coming back, so please do remove the related code. I know and agree, but URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725714#163 asked for the non-working code to be kept to work with older kernels. I do not have any strong feelings, so I left it as it was. This belongs in the changelog not the code. Actually, as long as there are several blocks doing similar things, I believe an explanation should be close to the code to explain why. I will wonder when I return in a few years time. :) The driver name should appear at the start of the log line (after the timestamp). Use that instead of 'kernel'. Yeah, but did not find a simple way to do it, and it is not affecting the functionallity, only the user messages. Should probably be fixed in the final version. Redundant use of grep; sed can do that (sed -n 's/.../.../p'). Yeah. Indentation of the above is inconsistent with the surrounding code (4 spaces vs hard tab). It will happen before any commit is done. -- Happy hacking Petter Reinholdtsen -- 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/20141007150911.gq10...@ulrik.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
On Tue, 2014-10-07 at 17:09 +0200, Petter Reinholdtsen wrote: Thank you for the code review. :) [Ben Hutchings] The firmware agent is never coming back, so please do remove the related code. I know and agree, but URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725714#163 asked for the non-working code to be kept to work with older kernels. Actually it is udev that removed this feature originally. Anyway, I shan't argue this with KiBi. I do not have any strong feelings, so I left it as it was. This belongs in the changelog not the code. Actually, as long as there are several blocks doing similar things, I believe an explanation should be close to the code to explain why. I will wonder when I return in a few years time. :) Perhaps this would be better placed above the old code, as that is what should be cleaned up at some later date. The driver name should appear at the start of the log line (after the timestamp). Use that instead of 'kernel'. Yeah, but did not find a simple way to do it, and it is not affecting the functionallity, only the user messages. Should probably be fixed in the final version. Redundant use of grep; sed can do that (sed -n 's/.../.../p'). Yeah. Indentation of the above is inconsistent with the surrounding code (4 spaces vs hard tab). It will happen before any commit is done. Thanks. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
I noticed this bug was mentioned as a regression in the Jessie installer, and thought I should have a look at how this could be improved from the hw-detect side. The following patch replaces the code looking in /dev/.udev/firmware-missing and /run/udev/firmware-missing for firmware wanted by the kernel with code looking for firmware listed in the meta-info of loaded modules. It will solve the problem for at least some kernel modules, but not the class of modules refusing to load if their firmware files are missing. Perhaps something do use while we wait for more information from the kernel side? The patch is only partly tested on the command line inside d-i, and is based on the isenkram code, but rewritten to avoid awk, as awk is not available in d-i. I can brush it up if we decide to go in this direction. diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh index 60c6ff4..77a670e 100755 --- a/check-missing-firmware.sh +++ b/check-missing-firmware.sh @@ -2,7 +2,6 @@ set -e . /usr/share/debconf/confmodule -MISSING='/dev/.udev/firmware-missing /run/udev/firmware-missing' DENIED=/tmp/missing-firmware-denied if [ x$1 = x-n ]; then @@ -67,61 +66,29 @@ check_missing () { # Give modules some time to request firmware. sleep 1 - modules= - files= - for missing_dir in $MISSING - do - if [ ! -d $missing_dir ]; then - log $missing_dir does not exist, skipping - continue - fi - for file in $(find $missing_dir -type l); do - # decode firmware filename as encoded by - # udev firmware.agent - fwfile=$(basename $file | sed -e 's#\\x2f#/#g') - - # strip probably nonexistant firmware subdirectory - devpath=$(readlink $file | sed 's/\/firmware\/.*//') - # the symlink is supposed to point to the device in /sys - if ! echo $devpath | grep -q '^/sys/'; then - devpath=/sys$devpath - fi - - module=$(get_module $devpath) - if [ -z $module ]; then - log failed to determine module from $devpath - continue - fi - - rm -f $file - - if grep -q ^$fwfile$ $DENIED 2/dev/null; then - continue - fi - - files=$fwfile${files:+ $files} - - if [ $module = usbcore ]; then - # Special case for USB bus, which puts the - # real module information in a subdir of - # the devpath. - for dir in $(find $devpath -maxdepth 1 -mindepth 1 -type d); do - module=$(get_module $dir) - if [ -n $module ]; then - modules=$module${modules:+ $modules} - fi - done - else - modules=$module${modules:+ $modules} - fi - done - done - +# Workaround for bug #725714, the kernel and udev no longer +# let us know via /dev/.udev/firmware-missing and +# /run/udev/firmware-missing which firmware files the kernel +# drivers look for. This approach will only find firmware for +# the loaded kernel modules. Modules refusing to +# register/load when the firmware is missing will be missed. +for fwfile in $(for module in $(cut -d -f1 /proc/modules); do modinfo $module | grep ^firmware:|cut -d: -f2; done); do +if [ ! -e /lib/firmware/$fwfile ] ; then + +if grep -q ^$fwfile$ $DENIED 2/dev/null; then +continue +fi + +files=${files:+$files }$fwfile +modules=$module${modules:+ $modules} +fi +done + if [ -n $modules ]; then log missing firmware files ($files) for $modules return 0 else - log no missing firmware in $MISSING + log no missing firmware for any loaded kernel module return 1 fi } -- Happy hacking Petter Reinholdtsen -- 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/2fl8ukt1fpt@diskless.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Petter Reinholdtsen p...@hungry.com (2014-10-06): I noticed this bug was mentioned as a regression in the Jessie installer, and thought I should have a look at how this could be improved from the hw-detect side. The following patch replaces the code looking in /dev/.udev/firmware-missing and /run/udev/firmware-missing for firmware wanted by the kernel with code looking for firmware listed in the meta-info of loaded modules. It will solve the problem for at least some kernel modules, but not the class of modules refusing to load if their firmware files are missing. Perhaps something do use while we wait for more information from the kernel side? The patch is only partly tested on the command line inside d-i, and is based on the isenkram code, but rewritten to avoid awk, as awk is not available in d-i. I can brush it up if we decide to go in this direction. The idea is to parse kernel logs. Mraw, KiBi. signature.asc Description: Digital signature
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
[Cyril Brulebois] The idea is to parse kernel logs. OK, that might work too. Is the idea to use the output from 'dmesg'? Who is implementing it? Is there a draft patch somewhere? -- Happy hacking Petter Reinholdtsen -- 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/20141006144842.gn10...@ulrik.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Petter Reinholdtsen p...@hungry.com (2014-10-06): [Cyril Brulebois] The idea is to parse kernel logs. OK, that might work too. No, it does. Is the idea to use the output from 'dmesg'? Who is implementing it? Is there a draft patch somewhere? I am working on it, when I'm not busy fixing or reverting regressions people introduce in d-i packages. KiBi. signature.asc Description: Digital signature
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
On Mon, 2014-10-06 at 15:37 +0200, Petter Reinholdtsen wrote: I noticed this bug was mentioned as a regression in the Jessie installer, and thought I should have a look at how this could be improved from the hw-detect side. The following patch replaces the code looking in /dev/.udev/firmware-missing and /run/udev/firmware-missing for firmware wanted by the kernel with code looking for firmware listed in the meta-info of loaded modules. That seems like a good idea. It will solve the problem for at least some kernel modules, but not the class of modules refusing to load if their firmware files are missing. I'm not aware that there are any of those. Perhaps something do use while we wait for more information from the kernel side? [...] I'm afraid I'm unlikely to implement the proposed structured logging in time for jessie, and the installer would need some work to make use of structured log data. However the firmware core code is already patched so that it logs all failure in a consistent format that you can grep for: firmware: failed to load %s (%d) The parameters are the filename and negative error code; usually that will be -ENOENT == -2. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Ben Hutchings b...@decadent.org.uk (2014-10-06): On Mon, 2014-10-06 at 15:37 +0200, Petter Reinholdtsen wrote: I noticed this bug was mentioned as a regression in the Jessie installer, and thought I should have a look at how this could be improved from the hw-detect side. The following patch replaces the code looking in /dev/.udev/firmware-missing and /run/udev/firmware-missing for firmware wanted by the kernel with code looking for firmware listed in the meta-info of loaded modules. That seems like a good idea. I disagree with the code deletion. It makes it harder to combine various d-i components across distributions to support as many use cases as possible. Keeping a few old lines of shell code shouldn't be a problem. Perhaps something do use while we wait for more information from the kernel side? [...] I'm afraid I'm unlikely to implement the proposed structured logging in time for jessie, and the installer would need some work to make use of structured log data. However the firmware core code is already patched so that it logs all failure in a consistent format that you can grep for: firmware: failed to load %s (%d) The parameters are the filename and negative error code; usually that will be -ENOENT == -2. I started using this successfully but then I stumbled upon issues with WPA2 (which turned out to be missing modules as we now know), and got to publish Jessie Beta 2. So the current logging situation might not be ideal yet but it seems sufficient to vastly improve the current state of affairs. Mraw, KiBi. signature.asc Description: Digital signature