Control: retitle -1 (re)implement "missing firmware" support through kernel log
grepping
Control: tag -1 patch pending
Petter Reinholdtsen (2014-10-15):
> I've tested the patch just now, and it seem to be working as it
> should
It appears loading firmware seems to work but I can't confirm a who
On Wed, 2014-10-15 at 22:39 +0200, Petter Reinholdtsen wrote:
> [Ben Hutchings]
> > Again, this is not a workaround, this is the only fix there will be for
> > that bug. The only thing that may change in the kernel to make this
> > easier is that it will do structured logging so in theory you don'
[Joey Hess]
> Looking at dmesg might fail if something is spamming it and the message
> drops out of the ring buffer. Maybe it would be better to look in syslog?
I am aware of it. I do believe the new method is a huge step forward
and am unsure if it is worth it to use the syslog instead. If
som
Petter Reinholdtsen wrote:
> Here is another draft, this time also providing the module name. I
> dropped the code looking in /proc/modules, as three ways to find
> firmware seem a bit too much.
Looking at dmesg might fail if something is spamming it and the message
drops out of the ring buffer.
[Ben Hutchings]
> Again, this is not a workaround, this is the only fix there will be for
> that bug. The only thing that may change in the kernel to make this
> easier is that it will do structured logging so in theory you don't need
> to use grep, cut, etc. In practice, as this is all shell scr
x 60c6ff4..87f2839 100755
> --- a/check-missing-firmware.sh
> +++ b/check-missing-firmware.sh
> @@ -69,6 +69,29 @@ check_missing () {
>
> modules=""
> files=""
> +
> + # Workaround for bug #725714, the kernel and udev no longer
@@ check_missing () {
modules=""
files=""
+
+ # 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.
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
> https://bugs.debian.org/cgi-bi
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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725714#163 >
asked for the non-working code to be kept to work with older kern
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
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-mi
Ben Hutchings (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 rep
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/fi
Petter Reinholdtsen (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 rever
[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-bugs-dist-requ...@lists.debian.org
wit
Petter Reinholdtsen (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/ude
do
- module=$(get_module "$dir")
- if [ -n "$module" ]; then
- modules="$module${modules:+
$modules}"
- fi
Hello,
I ran into the same problem with a wifi card (iwlwifi). I have a workaround for
that. First, be
sure to have the installation medi with the non-free firmware/drivers. Install
until the error
"ethernet card not found".
Open console (alt-f2).
Then install manually the firmware:
# cp /cd
Any updates on this bug?
and the firmware is on root. I have testing to
load firmware with expert mode on the deian installer and then load
firmware but the installer says : the failing step is: Load drivers from
removable media.
Sadly the firmware loading is currently broken in jessie/sid, see bug
#725714 [1].
I hope
On Sat, 2013-12-21 at 18:50 +0100, Andreas Cadhalpun wrote:
> Control: reassign -1 src:linux
>
> Hi,
>
> as nobody objected to my proposal, I'm reassigning this bug back to linux.
> In my opinion FW_LOADER_USER_HELPER should default to no, since the
> functionality is not in udev anymore.
I mad
Control: reassign -1 src:linux
Hi,
as nobody objected to my proposal, I'm reassigning this bug back to linux.
In my opinion FW_LOADER_USER_HELPER should default to no, since the
functionality is not in udev anymore.
Furthermore it seems, that when this functionality was moved to the
kernel, it
Hi,
Thanks, Kay, for the very fast response and the detailed reasoning.
Your arguments convinced me, that it is technically a very good idea to
keep userspace out of the firmware loading. This should definitely not
be reintroduced upstream or in the Debian version of udev. (Originally
I thou
On Fri, Dec 13, 2013 at 4:29 AM, Ben Hutchings wrote:
> On Fri, 2013-12-13 at 00:28 +0100, Kay Sievers wrote:
> [...]
>> >> Such an explicit message would probably use printk_emit() and pass
>> >> structured data with the filename and the ides from the kernel to
>> >> userspace, and on systemd sys
On Fri, 2013-12-13 at 00:28 +0100, Kay Sievers wrote:
[...]
> >> Such an explicit message would probably use printk_emit() and pass
> >> structured data with the filename and the ides from the kernel to
> >> userspace, and on systemd systems the journal would pick up the
> >> MESSAGE_ID and do some
On Fri, 2013-12-13 at 00:32 +0100, Kay Sievers wrote:
> On Fri, Dec 13, 2013 at 12:26 AM, Michael Biebl wrote:
> > Am 13.12.2013 00:12, schrieb Andreas Cadhalpun:
> >> The Debian installer needs a way to load the firmware during
> >> installation, otherwise the netinst.iso is pretty useless for WL
On Fri, Dec 13, 2013 at 12:42 AM, Michael Biebl wrote:
> Am 13.12.2013 00:34, schrieb Michael Biebl:
> See also
> http://lists.freedesktop.org/archives/systemd-devel/2013-November/014771.html
>
> But that thread just echoes what Kay already said, that user-space
> firmware loading is deprecated a
On Fri, Dec 13, 2013 at 12:34 AM, Michael Biebl wrote:
> Am 13.12.2013 00:26, schrieb Michael Biebl:
>> Am 13.12.2013 00:12, schrieb Andreas Cadhalpun:
>>> The Debian installer needs a way to load the firmware during
>>> installation, otherwise the netinst.iso is pretty useless for WLAN
>>> device
Am 13.12.2013 00:34, schrieb Michael Biebl:
> According to codesearch.d.n, hw-detect is the only tool using
> /run/udev/firmware-missing. I'm inclined to re-assign this bug to
> hw-detect and let the hw-detect maintainers decided how to handle this.
> If something like the isenkram approach would
Am 13.12.2013 00:26, schrieb Michael Biebl:
> Am 13.12.2013 00:12, schrieb Andreas Cadhalpun:
>> The Debian installer needs a way to load the firmware during
>> installation, otherwise the netinst.iso is pretty useless for WLAN
>> devices with non-free firmware.
>> Since a majority of the WLAN devi
On Fri, Dec 13, 2013 at 12:26 AM, Michael Biebl wrote:
> Am 13.12.2013 00:12, schrieb Andreas Cadhalpun:
>> The Debian installer needs a way to load the firmware during
>> installation, otherwise the netinst.iso is pretty useless for WLAN
>> devices with non-free firmware.
>> Since a majority of t
On Fri, Dec 13, 2013 at 12:12 AM, Andreas Cadhalpun
wrote:
> On 12.12.2013 23:19, Kay Sievers wrote:
>> On Thu, Dec 12, 2013 at 10:58 PM, Michael Biebl
>> wrote:
>>> This was removed upstream [1] and is highly unlikely to be added back.
>>> Especially considering that the user space firmware load
Am 13.12.2013 00:12, schrieb Andreas Cadhalpun:
> The Debian installer needs a way to load the firmware during
> installation, otherwise the netinst.iso is pretty useless for WLAN
> devices with non-free firmware.
> Since a majority of the WLAN devices need non-free firmware, just
> dropping this f
Hi,
On 12.12.2013 23:19, Kay Sievers wrote:
> On Thu, Dec 12, 2013 at 10:58 PM, Michael Biebl
wrote:
>> This was removed upstream [1] and is highly unlikely to be added back.
>> Especially considering that the user space firmware loader is scheduled
>> to be removed sooner rather then later.
>
Control: reassign -1 udev 204-5
Hi,
On 12.12.2013 19:43, Ben Hutchings wrote:
Yes. This is what is supposed to happen when firmware is missing:
1. The driver requests firmware.
2. The kernel tries to load a file under /lib/firmware, and fails.
(This is not implemented in the wheezy kernel
On Thu, Dec 12, 2013 at 09:51:48AM +0100, Andreas Cadhalpun wrote:
> Hi Ben,
>
> On 12.12.2013 01:50, Ben Hutchings wrote:
> >Control: reassign -1 installation-reports
> >
> >On Wed, 2013-12-11 at 21:56 +0100, Andreas Cadhalpun wrote:
> >>It looks like a bug in the linux kernel.
> >
> >I don't thi
Hi Ben,
On 12.12.2013 01:50, Ben Hutchings wrote:
Control: reassign -1 installation-reports
On Wed, 2013-12-11 at 21:56 +0100, Andreas Cadhalpun wrote:
It looks like a bug in the linux kernel.
I don't think so. The kernel log indicates that it got a negative
response from the user agent.
gt; > missing nothing but cannot find the DHCP server.
> >
> > Its a TP-LINK Model TL-WN821N (300 Mbps).
> I have noticed similar problems and reported them as bug #725714 (CCed).
> It looks like a bug in the linux kernel.
I don't think so. The kernel log indicates that
d the DHCP server.
Its a TP-LINK Model TL-WN821N (300 Mbps).
I have noticed similar problems and reported them as bug #725714 (CCed).
It looks like a bug in the linux kernel.
Best regards,
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "u
Package: installation-reports
Severity: serious
Dear Maintainer,
The current debian-testing-amd64-netinst.iso is broken: It does detect
missing firmware, but does not place this information in the correct
folder /run/udev/fimrware-missing. This directory does not exist, when
check-missing-fir
40 matches
Mail list logo
