Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

Nevertheless: thx for your report your help through this thread.


No problem. I am willing to try to do more, but right now I don't know
how to do what has been suggested.



Here is where to report Nouveau bugs:

https://gitlab.freedesktop.org/drm/nouveau/-/issues/

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Nick Hastings 
> Sent: Thursday, June 1, 2023 7:02 PM
> To: Karol Herbst 
> Cc: Limonciello, Mario ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> Hi,
>
> * Karol Herbst  [230602 03:10]:
> > On Thu, Jun 1, 2023 at 7:21 PM Limonciello, Mario
> >  wrote:
> > > > -Original Message-
> > > > From: Karol Herbst 
> > > > Sent: Thursday, June 1, 2023 12:19 PM
> > > > To: Limonciello, Mario 
> > > > Cc: Nick Hastings ; Lyude Paul
> > > > ; Lukas Wunner ; Salvatore
> > > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > > Wysocki ; Len Brown ; linux-
> > > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > > regressi...@lists.linux.dev
> > > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> system)
> > > >
> > > > On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
> > > >  wrote:
> > > > >
> > > > > [AMD Official Use Only - General]
> > > > >
> > > > > > -Original Message-
> > > > > > From: Karol Herbst 
> > > > > > Sent: Thursday, June 1, 2023 11:33 AM
> > > > > > To: Limonciello, Mario 
> > > > > > Cc: Nick Hastings ; Lyude Paul
> > > > > > ; Lukas Wunner ; Salvatore
> > > > > > Bonaccorso ; 1036...@bugs.debian.org; Rafael
> J.
> > > > > > Wysocki ; Len Brown ; linux-
> > > > > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > > > > regressi...@lists.linux.dev
> > > > > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video
> _OSI
> > > > > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> > > > system)
> > > > > >
> > > > > > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> > > > > > >
> > > > > > > Lyude, Lukas, Karol
> > > > > > >
> > > > > > > This thread is in relation to this commit:
> > > > > > >
> > > > > > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > > > > > >
> > > > > > > Nick has found that runtime PM is *not* working for nouveau.
> > > > > > >
> > > > > >
> > > > > > keep in mind we have a list of PCIe controllers where we apply a
> > > > > > workaround:
> > > > > >
> > > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > > > > > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> > > > > >
> > > > > > And I suspect there might be one or two more IDs we'll have to add
> > > > > > there. Do we have any logs?
> > > > >
> > > > > There's some archived onto the distro bug.  Search this page for
> > > > "journalctl.log.gz"
> > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
> > > > >
> > > >
> > > > interesting.. It seems to be the same controller used here. I wonder
> > > > if the pci topology is different or if the workaround is applied at
> > > > all.
> > >
> > > I didn't see the message in the log about the workaround being applied
> > > in that log, so I guess PCI topology difference is a likely suspect.
> > >
> >
> > yeah, but I also couldn't see a log with the usual nouveau messages,
> > so it's kinda weird.
> >
> > Anyway, the output of `lspci -tvnn` would help
>
> % lspci -tvnn
> -[:00]-+-00.0  Intel Corporation Device [8086:3e20]
>+-01.0-[01]00.0  NVIDIA Corporation TU117M [GeForce GTX 1650
> Mobile / Max-Q] [10de:1f91]

So the bridge it's connected to is the same that the quirk *should have been* 
triggering.

May 29 15:02:42 xps kernel: pci :00:01.0: [8086:1901] type 01 class 0x060400

Since the quirk isn't wor

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Karol Herbst 
> Sent: Thursday, June 1, 2023 12:19 PM
> To: Limonciello, Mario 
> Cc: Nick Hastings ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
>  wrote:
> >
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Karol Herbst 
> > > Sent: Thursday, June 1, 2023 11:33 AM
> > > To: Limonciello, Mario 
> > > Cc: Nick Hastings ; Lyude Paul
> > > ; Lukas Wunner ; Salvatore
> > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > Wysocki ; Len Brown ; linux-
> > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > regressi...@lists.linux.dev
> > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> system)
> > >
> > > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> > >  wrote:
> > > >
> > > > +Lyude, Lukas, Karol
> > > >
> > > > On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > > > > Hi,
> > > > >
> > > > > * Nick Hastings  [230530 16:01]:
> > > > >> * Mario Limonciello  [230530 13:00]:
> > > > > 
> > > > >>> As you're actually loading nouveau, can you please try
> > > nouveau.runpm=0 on
> > > > >>> the kernel command line?
> > > > >> I'm not intentionally loading it. This machine also has intel 
> > > > >> graphics
> > > > >> which is what I prefer. Checking my
> > > > >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > > > >> I see:
> > > > >>
> > > > >> blacklist nvidia
> > > > >> blacklist nvidia-drm
> > > > >> blacklist nvidia-modeset
> > > > >> blacklist nvidia-uvm
> > > > >> blacklist ipmi_msghandler
> > > > >> blacklist ipmi_devintf
> > > > >>
> > > > >> So I thought I had blacklisted it but it seems I did not. Since I do 
> > > > >> not
> > > > >> want to use it maybe it is better to check if the lock up occurs with
> > > > >> nouveau blacklisted. I will try that now.
> > > > > I blacklisted nouveau and booted into a 6.1 kernel:
> > > > > % uname -a
> > > > > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1
> > > (2023-05-08) x86_64 GNU/Linux
> > > > >
> > > > > It has been running without problems for nearly two days now:
> > > > > % uptime
> > > > >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> > > > >
> > > > > Regards,
> > > > >
> > > > > Nick.
> > > >
> > > > Thanks, that makes a lot more sense now.
> > > >
> > > > Nick, Can you please test if nouveau works with runtime PM in the
> > > > latest 6.4-rc?
> > > >
> > > > If it works in 6.4-rc, there are probably nouveau commits that need
> > > > to be backported to 6.1 LTS.
> > > >
> > > > If it's still broken in 6.4-rc, I believe you should file a bug:
> > > >
> > > > https://gitlab.freedesktop.org/drm/nouveau/
> > > >
> > > >
> > > > Lyude, Lukas, Karol
> > > >
> > > > This thread is in relation to this commit:
> > > >
> > > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > > >
> > > > Nick has found that runtime PM is *not* working for nouveau.
> > > >
> > >
> > > keep in mind we have a list of PCIe controllers where we apply a
> > > workaround:
> > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> > >
> > > And I suspect there might be one or two more IDs we'll have to add
> > > there. Do we have any logs?
> >
> &g

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Karol Herbst 
> Sent: Thursday, June 1, 2023 11:33 AM
> To: Limonciello, Mario 
> Cc: Nick Hastings ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
>  wrote:
> >
> > +Lyude, Lukas, Karol
> >
> > On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > > Hi,
> > >
> > > * Nick Hastings  [230530 16:01]:
> > >> * Mario Limonciello  [230530 13:00]:
> > > 
> > >>> As you're actually loading nouveau, can you please try
> nouveau.runpm=0 on
> > >>> the kernel command line?
> > >> I'm not intentionally loading it. This machine also has intel graphics
> > >> which is what I prefer. Checking my
> > >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > >> I see:
> > >>
> > >> blacklist nvidia
> > >> blacklist nvidia-drm
> > >> blacklist nvidia-modeset
> > >> blacklist nvidia-uvm
> > >> blacklist ipmi_msghandler
> > >> blacklist ipmi_devintf
> > >>
> > >> So I thought I had blacklisted it but it seems I did not. Since I do not
> > >> want to use it maybe it is better to check if the lock up occurs with
> > >> nouveau blacklisted. I will try that now.
> > > I blacklisted nouveau and booted into a 6.1 kernel:
> > > % uname -a
> > > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1
> (2023-05-08) x86_64 GNU/Linux
> > >
> > > It has been running without problems for nearly two days now:
> > > % uptime
> > >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> > >
> > > Regards,
> > >
> > > Nick.
> >
> > Thanks, that makes a lot more sense now.
> >
> > Nick, Can you please test if nouveau works with runtime PM in the
> > latest 6.4-rc?
> >
> > If it works in 6.4-rc, there are probably nouveau commits that need
> > to be backported to 6.1 LTS.
> >
> > If it's still broken in 6.4-rc, I believe you should file a bug:
> >
> > https://gitlab.freedesktop.org/drm/nouveau/
> >
> >
> > Lyude, Lukas, Karol
> >
> > This thread is in relation to this commit:
> >
> > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> >
> > Nick has found that runtime PM is *not* working for nouveau.
> >
>
> keep in mind we have a list of PCIe controllers where we apply a
> workaround:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
>
> And I suspect there might be one or two more IDs we'll have to add
> there. Do we have any logs?

There's some archived onto the distro bug.  Search this page for 
"journalctl.log.gz"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530

> And could anybody test if adding the
> controller in play here does resolve the problem?
>
> > If you recall we did 24867516f06d because 5775b843a619 was
> > supposed to have fixed it.
> >

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

+Lyude, Lukas, Karol

On 5/31/2023 6:40 PM, Nick Hastings wrote:

Hi,

* Nick Hastings  [230530 16:01]:

* Mario Limonciello  [230530 13:00]:



As you're actually loading nouveau, can you please try nouveau.runpm=0 on
the kernel command line?

I'm not intentionally loading it. This machine also has intel graphics
which is what I prefer. Checking my
/etc/modprobe.d/blacklist-nvidia-nouveau.conf
I see:

blacklist nvidia
blacklist nvidia-drm
blacklist nvidia-modeset
blacklist nvidia-uvm
blacklist ipmi_msghandler
blacklist ipmi_devintf

So I thought I had blacklisted it but it seems I did not. Since I do not
want to use it maybe it is better to check if the lock up occurs with
nouveau blacklisted. I will try that now.

I blacklisted nouveau and booted into a 6.1 kernel:
% uname -a
Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) 
x86_64 GNU/Linux

It has been running without problems for nearly two days now:
% uptime
  08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27

Regards,

Nick.


Thanks, that makes a lot more sense now.

Nick, Can you please test if nouveau works with runtime PM in the
latest 6.4-rc?

If it works in 6.4-rc, there are probably nouveau commits that need
to be backported to 6.1 LTS.

If it's still broken in 6.4-rc, I believe you should file a bug:

https://gitlab.freedesktop.org/drm/nouveau/


Lyude, Lukas, Karol

This thread is in relation to this commit:

24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")

Nick has found that runtime PM is *not* working for nouveau.

If you recall we did 24867516f06d because 5775b843a619 was
supposed to have fixed it.

Bug#1035397: pm-utils is abandoned, should be removed from Debian

[Limonciello, Mario]

[Public]

There was a comment on #852167 that there are no non-systemd tools, but that's 
simply not true.

All you need for a suspend is

echo mem | sudo tee /sys/power/state

BTW - there's a reason that systemd refuses to include a lot of hooks and 
quirks.
The scripts/quirks/etc that pm-utils does are presumptuous and generally not 
correct.

Bug#1008025:

[Limonciello, Mario]

[AMD Official Use Only - General]

I believe this should be fixed in the latest version which drops the efi-cc and 
uses CC variable directly.

Can you confirm it?

Bug#1023329:

[Limonciello, Mario]

[Public]

FYI - the patch was originally targeted to ath-next (6.2), but because of the 
severity of this deadlock issue it's going to go to 6.1-rc with a CC to stable.
[v6.1] wifi: ath11k: avoid deadlock during regulatory update in 
ath11k_regd_update() - Patchwork 
(kernel.org)

Bug#1011511:

[Limonciello, Mario]

[Public]

https://github.com/fwupd/fwupd/pull/5041 may help your problem, can you try 
that?

Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0 sp:bf98504c error:0 in fwupdmgr[423000+15000]

[Limonciello, Mario]

As an experiment, can you please try to disable the "cpu" plugin in 
/etc/fwupd/daemon.conf?
Add to "BlacklistPlugins" list.

> -Original Message-
> From: Martin-Éric Racine 
> Sent: Wednesday, March 10, 2021 5:14
> To: Julien Cristau
> Cc: 977...@bugs.debian.org; Bernhard Übelacker
> Subject: Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0 sp:bf98504c
> error:0 in fwupdmgr[423000+15000]
> 
> 
> [EXTERNAL EMAIL]
> 
> ke 10. maalisk. 2021 klo 13.08 Julien Cristau (jcris...@debian.org) kirjoitti:
> >
> > On Wed, Mar 10, 2021 at 01:01:30PM +0200, Martin-Éric Racine wrote:
> > > This could indeed be it. The baseline for Bullseye still is a basic
> > > 686. Additionally, the lowest Linux kernel for i386 is linux-image-686
> > > which is configured for Geode. Still, the bug just appeared a few days
> > > ago when the package in Testing was updated. This seems like a
> > > regression.
> > >
> > You filed this 4 months ago, so it seems rather older?
> 
> Apparently, it comes and goes.  It started showing up in 'coredumpctl
> list' just a few days ago. That's when I sent the output to the bug.
> 
> Martin-Éric

Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0 sp:bf98504c error:0 in fwupdmgr[423000+15000]

[Limonciello, Mario]

Yes, I forgot it renamed - that's right.
Also I didn't properly acknowledge the crash was in the client not the daemon, 
so this wouldn't have done anything anyway.

I tend to think this is a compiler issue, not a fwupd upstream or packaging 
issue.

> -Original Message-
> From: Martin-Éric Racine 
> Sent: Wednesday, March 10, 2021 10:25
> To: Limonciello, Mario
> Cc: 977...@bugs.debian.org; Julien Cristau; Bernhard Übelacker
> Subject: Re: Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0
> sp:bf98504c error:0 in fwupdmgr[423000+15000]
> 
> 
> [EXTERNAL EMAIL]
> 
> You probably meant this:
> 
> DisabledPlugins=test;test_ble;invalid;cpu
> 
> Still signal 4.
> 
> TIMEPID   UID   GID SIG COREFILE  EXE
> Wed 2021-03-10 18:23:39 EET1322 0 0   4 error
> /usr/bin/fwupdmgr
> 
> ke 10. maalisk. 2021 klo 17.49 Limonciello, Mario
> (mario.limoncie...@dell.com) kirjoitti:
> >
> > As an experiment, can you please try to disable the "cpu" plugin in
> /etc/fwupd/daemon.conf?
> > Add to "BlacklistPlugins" list.
> >
> > > -Original Message-
> > > From: Martin-Éric Racine 
> > > Sent: Wednesday, March 10, 2021 5:14
> > > To: Julien Cristau
> > > Cc: 977...@bugs.debian.org; Bernhard Übelacker
> > > Subject: Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0
> sp:bf98504c
> > > error:0 in fwupdmgr[423000+15000]
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > ke 10. maalisk. 2021 klo 13.08 Julien Cristau (jcris...@debian.org)
> kirjoitti:
> > > >
> > > > On Wed, Mar 10, 2021 at 01:01:30PM +0200, Martin-Éric Racine wrote:
> > > > > This could indeed be it. The baseline for Bullseye still is a basic
> > > > > 686. Additionally, the lowest Linux kernel for i386 is linux-image-686
> > > > > which is configured for Geode. Still, the bug just appeared a few days
> > > > > ago when the package in Testing was updated. This seems like a
> > > > > regression.
> > > > >
> > > > You filed this 4 months ago, so it seems rather older?
> > >
> > > Apparently, it comes and goes.  It started showing up in 'coredumpctl
> > > list' just a few days ago. That's when I sent the output to the bug.
> > >
> > > Martin-Éric
> >

Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Limonciello, Mario]

Paul,

I don't have the power to manually run it. So there is nothing I can do. With 
the new 1.5.6-1 upload someone will need to manually run it again.

Get Outlook for Android<https://aka.ms/ghei36>


From: Paul Gevers 
Sent: Thursday, February 18, 2021, 00:09
To: 973...@bugs.debian.org
Subject: Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd 
update results in segfaulting binary

Hi Mario,

LOn Mon, 16 Nov 2020 16:01:34 + "Limonciello, Mario"
 wrote:
> As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
> It needs to be done when 1.5.1-2 is ready to migrate.

There's users of unstable too. In my opinion, if you can't relax the
constraints, you'll have to kick it off as soon as it's needed in
unstable, not when it's ready to migrate.

Paul

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

I'm unsure what to do here, it seems to me that there is a problem with systemd 
using DynamicUser and sssd when the service uses dbus.
Perhaps this should be re-assigned to systemd.

> -Original Message-
> From: Thomas Stewart 
> Sent: Thursday, January 28, 2021 1:36
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: RE: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> Yes, I'm using sssd against FreeIPA.
> 
> Tom
> 
> 
> On 28 January 2021 02:12:11 GMT, "Limonciello, Mario"
>  wrote:
> >Are you by chance using NFS mounted directories?  Or external entity
> >for authentication such as LDAP or SSSD?

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

Are you by chance using NFS mounted directories?  Or external entity for 
authentication such as LDAP or SSSD?

> -Original Message-
> From: Thomas Stewart 
> Sent: Wednesday, January 27, 2021 8:33
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> On 27 Jan 2021, at 14:18, Limonciello, Mario wrote:
> > Can you check if fwupdmgr works as a standard user to talk to the daemon for
> you?
> 
> As a normal user I can run "fwupdmgr --version" fine[0].
> 
> However if I amend the unit to run the above[1] the output stops before
> daemon version[2].
> 
> Kind Regards
> --
> Tom
> 
> [0]
> $ id
> uid=1000(thomas) gid=1000(thomas)
> groups=1000(thomas),20(dialout),27(sudo),128(docker)
> $
> $ /usr/bin/fwupdmgr --version
> client version: 1.5.5
> compile-time dependency versions
> gusb:   0.3.5
> 
> daemon version: 1.5.5
> $
> 
> [1]
> ExecStart=/usr/bin/fwupdmgr --version
> 
> [2]
> Jan 27 14:24:38 systemd[1]: Starting Refresh fwupd metadata and update motd...
> Jan 27 14:24:38 fwupdmgr[199579]: client version:1.5.5
> Jan 27 14:24:38 fwupdmgr[199579]: compile-time dependency versions
> Jan 27 14:24:38 fwupdmgr[199579]: gusb:0.3.5
> Jan 27 14:24:38 fwupdmgr[199579]: Failed to connect to daemon: Exhausted all
> available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)
> Jan 27 14:24:38 systemd[1]: fwupd-refresh.service: Main process exited,
> code=exited, status=1/FAILURE
> Jan 27 14:24:38 systemd[1]: fwupd-refresh.service: Failed with result 'exit-
> code'.
> Jan 27 14:24:38 systemd[1]: Failed to start Refresh fwupd metadata and update
> motd.

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

Can you check if fwupdmgr works as a standard user to talk to the daemon for 
you?

> -Original Message-
> From: Thomas Stewart 
> Sent: Wednesday, January 27, 2021 5:42
> To: 943...@bugs.debian.org
> Subject: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> I'm running testing/sid and have fwupd-1.5.5-2 installed. I have found
> that when fwupd-refresh.service restarts either with the timer or
> manually that if DynamicUser=yes is enabled then the service fails to
> start[0]. When I remove DynamicUser from the unit it restarts fine.
> 
> I noticed that the unit has: CacheDirectory=fwupdmgr but the
> metadata seems to live in /var/cache/fwupd[1].
> 
> After purging the package and removing /var/cache/fwup* /var/lib/fwupd
> /var/cache/private/fwupd and reinstalling I can see the /var/cache dirs
> created[2] but the service does not start.
> 
> When removing the "StandardError=null" directive from the unit I get an
> additional error[3], which seems to indicate it's having trouble
> talking to dbus.
> 
> Kind Regards
> --
> Tom
> 
> [0]
> $ sudo systemctl restart fwupd-refresh.service
> Job for fwupd-refresh.service failed because the control process exited with
> error code.
> See "systemctl status fwupd-refresh.service" and "journalctl -xe" for details.
> $
> 
> $ sudo journalctl -f
> Jan 27 10:09:30 systemd[1]: Starting Refresh fwupd metadata and update motd...
> Jan 27 10:09:31 fwupdmgr[176638]: (fwupdmgr:176638): GLib-DEBUG: 10:09:31.089:
> setenv()/putenv() are not thread-safe and should not be used after threads are
> created
> Jan 27 10:09:31 systemd[1]: fwupd-refresh.service: Main process exited,
> code=exited, status=1/FAILURE
> Jan 27 10:09:31 systemd[1]: fwupd-refresh.service: Failed with result 'exit-
> code'.
> Jan 27 10:09:31 systemd[1]: Failed to start Refresh fwupd metadata and update
> motd.
> $
> 
> [1]
> $ find /var/cache/fw*
> /var/cache/fwupd
> /var/cache/fwupd/metadata.xmlb
> /var/cache/fwupd/quirks.xmlb
> /var/cache/fwupd/metainfo.xmlb
> /var/cache/fwupdmgr
> $
> 
> [2]
> $ sudo ls -la /var/cache/fwupdmgr /var/cache/private/fwupdmgr
> lrwxrwxrwx 1 root  root16 Jan 27 10:57 /var/cache/fwupdmgr ->
> private/fwupdmgr
> 
> /var/cache/private/fwupdmgr:
> total 8
> drwxr-xr-x 2 62803 62803 4096 Jan 27 10:57 .
> drwx-- 3 root  root  4096 Jan 27 10:57 ..
> $
> 
> [3]
> Jan 27 11:09:30 fwupdmgr[189035]: Failed to connect to daemon: Exhausted all
> available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)

Bug#980570: fwupd: obsolete-conffile /etc/fwupd/ata.conf

[Limonciello, Mario]

Thanks for the report.  It's an oversight that it didn't get removed.  Will 
have a future upload resolve it.

> -Original Message-
> From: Thorsten Glaser 
> Sent: Wednesday, January 20, 2021 12:25
> To: Debian Bug Tracking System
> Subject: Bug#980570: fwupd: obsolete-conffile /etc/fwupd/ata.conf
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.5.5-2
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: adequate obsolete-conffile
> X-Debbugs-Cc: t...@mirbsd.de
> 
> adequate reports:
> 
> fwupd: obsolete-conffile /etc/fwupd/ata.conf
> 
> Is this file really to be removed or is there a bug in the package
> that it’s not shipped any more?
> 
> If the former, please integrate relevant maintainer script magic to
> make it disappear properly.
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500,
> 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-
> debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages fwupd depends on:
> ii  libc6  2.31-9
> ii  libcurl3-gnutls7.74.0-1
> ii  libefiboot137-6
> ii  libelf10.182-3
> ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
> ii  libflashrom1   1.2-5
> ii  libfwupd2  1.5.5-2
> ii  libfwupdplugin11.5.5-2
> ii  libglib2.0-0   2.66.4-1
> ii  libgnutls303.7.0-5
> ii  libgudev-1.0-0 234-1
> ii  libgusb2   0.3.5-1
> ii  libjcat1   0.1.3-2
> ii  libjson-glib-1.0-0 1.6.0-2
> ii  libpolkit-gobject-1-0  0.105-29
> ii  libsmbios-c2   2.4.3-1
> ii  libsqlite3-0   3.34.0-1
> ii  libtss2-esys-3.0.2-0   3.0.3-1
> ii  libxmlb1   0.1.15-2
> ii  shared-mime-info   2.0-1
> 
> Versions of packages fwupd recommends:
> pn  bolt   
> ii  dbus   1.12.20-1
> pn  fwupd-signed   
> ii  python33.9.1-1
> pn  secureboot-db  
> ii  udisks2-without-systemd [udisks2]  2.1.3-5~wtf2
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

On Thu, 19 Mar 2020 15:02:13 +0100 Diederik de Haas  
wrote:
> On donderdag 19 maart 2020 14:59:56 CET mario.limoncie...@dell.com wrote:
> > Sorry - I see now that was from a while back.
>
> And also a different user (OP).

After some upstream discussion, any remaining issues with 1.3.x this is 
expected to be root caused in a CDN caching problem that will be transient.  
The architecture was changed in the 1.4.x series, so please if this is still 
present in 1.4.x or 1.5.x please notify.

Bug#980049: fwupd: Should fwupd specify dbus as a dependency?

[Limonciello, Mario]

> -Original Message-
> From: Lukas Pirl 
> Sent: Wednesday, January 13, 2021 13:51
> To: Limonciello, Mario
> Cc: 980...@bugs.debian.org
> Subject: Re: Bug#980049: fwupd: Should fwupd specify dbus as a dependency?
> 
> Thanks for your quick reply, Mario.
> 
> On Wed, 2021-01-13 16:10 +, Limonciello, Mario wrote as excerpted:
> > I don't think it's a true dependency.  You can use fwupdtool without it.
> > It's only needed for fwupdmgr.
> > Perhaps a Recommends would be better?
> 
> I didn't know if fwupd is really useful without fwupdmgr. If using fwupd
> without fwupdmgr is a common use case then yes, listing dbus as recommended
> package is probably appropriate.
> 

I don't believe we have any evidence to say which use cases are more "common".
But it's a use case that is supported by upstream, particularly since you can
now optionally build without daemon/client and fwupdtool is placed in PATH by
default.

As such, I'll add a Recommends.

> > That being said I don't think it would solve it for you.  Systemd has dbus
> > as a Recommends and you still appear to not have it.
> 
> Even if systems are configured to not install recommended packages by default
> (you are right, it does not solve it for me), then the list of recommended
> packages can provide helpful clues, at least.

OK.

Bug#980049: fwupd: Should fwupd specify dbus as a dependency?

[Limonciello, Mario]

I don't think it's a true dependency.  You can use fwupdtool without it.  It's 
only needed for fwupdmgr.
Perhaps a Recommends would be better?

That being said I don't think it would solve it for you.  Systemd has dbus as a 
Recommends and you still appear to not have it.

> -Original Message-
> From: lukas 
> Sent: Wednesday, January 13, 2021 6:55
> To: Debian Bug Tracking System
> Subject: Bug#980049: fwupd: Should fwupd specify dbus as a dependency?
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.5.3-2
> Severity: important
> 
> Dear Maintainers,
> 
> thanks for maintaining this package and taking the time to consider this bug
> report.
> 
> On a minimal system, it happened to me that when installing fwupd, dbus is
> has not been installed as a dependency.
> Without dbus, fwupd turned out to be unusable ("Failed to connect to daemon"
> on ``fwupdmgr refresh``).
> 
> Do we maybe need to list the package "dbus" as a dependency of "fwupd"?
> 
> Cheers,
> 
> Lukas
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libc6  2.31-9
> ii  libcurl3-gnutls7.74.0-1
> ii  libefiboot137-6
> ii  libelf10.182-3
> ii  libflashrom1   1.2-5
> ii  libfwupd2  1.5.3-2
> ii  libfwupdplugin11.5.3-2
> ii  libglib2.0-0   2.66.4-1
> ii  libgudev-1.0-0 234-1
> ii  libgusb2   0.3.5-1
> ii  libjcat1   0.1.3-2
> ii  libjson-glib-1.0-0 1.6.0-2
> ii  libpolkit-gobject-1-0  0.105-29
> ii  libsmbios-c2   2.4.3-1
> ii  libsqlite3-0   3.34.0-1
> ii  libsystemd0247.2-4
> ii  libtss2-esys-3.0.2-0   3.0.3-1
> ii  libxmlb1   0.1.15-2
> ii  shared-mime-info   2.0-1
> 
> Versions of packages fwupd recommends:
> pn  bolt   
> pn  fwupd-signed   
> ii  python33.9.1-1
> pn  secureboot-db  
> ii  udisks22.9.1-2
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#976639: flashrom does not support jlink_spi

[Limonciello, Mario]

> 
> On Tue, 2020-12-08 at 05:45 +, Limonciello, Mario wrote:
> > I checked and meson.build is missing jlink support.  So this needs to
> > be fixed upstream to enable in the package.
> 
> Thanks, I didn't know that there is a meson build option. I pushed a
> fix upstream: https://review.coreboot.org/c/flashrom/+/48478

Thanks!  I'll watch for that to be merged and then pull it into the Debian 
package when ready.

Bug#976639: flashrom does not support jlink_spi

[Limonciello, Mario]

I checked and meson.build is missing jlink support.  So this needs to be fixed 
upstream to enable in the package.

Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Limonciello, Mario]

> -Original Message-
> From: Matteo Settenvini  On Behalf Of Matteo Settenvini
> Sent: Saturday, November 14, 2020 7:35
> To: 973...@bugs.debian.org
> Subject: Bug#973715: fwupd-amd64-signed holding off fwupd update results in
> segfaulting binary
> 
> The problem suddenly become worse.
> 
> Now that fwupd 1.5.1 has landed in sid, and some dependencies
> apparently changed, the fwupd-amd64-signed package holding off fwupd
> upgrade and forcing it to stay at version 1.4.6-2, is breaking the
> system:
> 
> nov 14 14:29:52 rosebud kernel: fwupd[11192]: segfault at 8 ip
> 56035dbcc548 sp 7ffddfa64b00 error 4 in
> fwupd[56035dbaf000+2]
> nov 14 14:29:52 rosebud kernel: Code: c7 44 24 08 00 00 00 00 66 2e 0f
> 1f 84 00 00 00 00 00 48 8b 11 8b 44 24 10 be 01 00 00 00 4c 8b 34 c2>
> nov 14 14:29:52 rosebud systemd[1]: fwupd.service: Main process exited,
> code=killed, status=11/SEGV
> 
> This goes away after uninstalling the fwupd-amd64-signed package and
> installing fwupd 1.5.1, but of course on a system with SecureBoot
> enabled, this is not helping much if you have pending BIOS updates.
> 
> Cheers,
> Matteo

1.5.1-1 won't migrate to testing as other issues came up with non-x86
architectures.  I've uploaded a 1.5.1-2 this morning that should hopefully
sort those out.

As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
It needs to be done when 1.5.1-2 is ready to migrate.  If there is another
problem that comes up (say autopkgtest fails, or some other arch still fails)
then we'll probably need to do a 1.5.1-3 and then kick it off.

Bug#974738: fwupd: FTBFS on various architectures

[Limonciello, Mario]

Yes, I'm aware. I fixed all but ppc64le in the upstream packaging. That one is 
under discussion. Will wait until that one is also fixed for next upload.

Get Outlook for Android


From: Salvatore Bonaccorso 
Sent: Saturday, November 14, 2020 7:33:16 AM
To: Debian Bug Tracking System 
Subject: Bug#974738: fwupd: FTBFS on various architectures


[EXTERNAL EMAIL]

Source: fwupd
Version: 1.5.1-1
Severity: serious
Tags: ftbfs
Justification: fails to builds from source on various architectures
X-Debbugs-Cc: car...@debian.org

Hi

The last upload of fwupd fails to build on various architectures:

https://buildd.debian.org/status/logs.php?pkg=fwupd=1.5.1-1=sid

Regards,
Salvatore

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Limonciello, Mario]

> -Original Message-
> From: Boyuan Yang 
> Sent: Tuesday, November 3, 2020 23:45
> To: Limonciello, Mario; 973...@bugs.debian.org
> Subject: Re: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-
> friendly
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> 在 2020-11-03星期二的 22:21 +，Limonciello, Mario写道：
> > > -Original Message-
> > > From: Boyuan Yang 
> > > Sent: Tuesday, November 3, 2020 13:09
> > > To: sub...@bugs.debian.org
> > > Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-
> > > friendly
> > >
> > > Package: fwupd-amd64-signed
> > > Severity: grave
> > > Version: 1.4.6+2
> > > X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com
> > >
> > > Dear EFI Team,
> > >
> > > Package fwupd-amd64-signed currently cannot be installed on Debian
> > > Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has
> > > fwupd
> > > (= 1.4.6-2+b1).
> >
> > I'm sorry can you show me where this +b1 build is?
> >
> > I don't see it mentioned in https://tracker.debian.org/pkg/fwupd
> 
> It is shown at https://buildd.debian.org/status/package.php?p=fwupd .
> If you actually install a Debian Sid system, you can also find the
> package with this version string.
> 
> 
> > > It seems obvious that such dependency relationship made
> > > fwupd/fwupd-
> > > amd64-signed not binNMU-friendly. Please consider setting a version
> > > range to allow binNMU-ed package to satisfy the dependency
> > > relationship.
> 
> Please consider reading https://wiki.debian.org/binNMU and see how can
> things be improved.
> 
> Thanks,
> Boyuan Yang

I think the problem here is that the EFI binary sign process just didn't
run.  @Steve McIntyre is that supposed to be automatic now?  Or still manual?

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Limonciello, Mario]

> 
> On Wed, Nov 04, 2020 at 06:30:54PM +, Limonciello, Mario wrote:
> >> 在 2020-11-03星期二的 22:21 +0000，Limonciello, Mario写道：
> >> > > -Original Message-
> >> > > From: Boyuan Yang 
> >> > > Sent: Tuesday, November 3, 2020 13:09
> >> > > To: sub...@bugs.debian.org
> >> > > Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-
> >> > > friendly
> >> > >
> >> > > Package: fwupd-amd64-signed
> >> > > Severity: grave
> >> > > Version: 1.4.6+2
> >> > > X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com
> >> > >
> >> > > Dear EFI Team,
> >> > >
> >> > > Package fwupd-amd64-signed currently cannot be installed on Debian
> >> > > Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has
> >> > > fwupd
> >> > > (= 1.4.6-2+b1).
> >> >
> >> > I'm sorry can you show me where this +b1 build is?
> >> >
> >> > I don't see it mentioned in https://tracker.debian.org/pkg/fwupd
> >>
> >> It is shown at https://buildd.debian.org/status/package.php?p=fwupd .
> >> If you actually install a Debian Sid system, you can also find the
> >> package with this version string.
> >>
> >>
> >> > > It seems obvious that such dependency relationship made
> >> > > fwupd/fwupd-
> >> > > amd64-signed not binNMU-friendly. Please consider setting a version
> >> > > range to allow binNMU-ed package to satisfy the dependency
> >> > > relationship.
> >>
> >> Please consider reading https://wiki.debian.org/binNMU and see how can
> >> things be improved.
> >>
> >> Thanks,
> >> Boyuan Yang
> >
> >I think the problem here is that the EFI binary sign process just didn't
> >run.  @Steve McIntyre is that supposed to be automatic now?  Or still manual?
> 
> I saw earlier that it's just happened. It's still run manually. What
> we've done for the other -signed packages to deal with the delay and
> potentially inconsistent versioning is change the dependencies.
> Instead of depending on *exactly* the same version as the signed
> package (==), we switch to >= so that a delay in the new -signed
> package being processed won't break installations.
> 

99.9% of the time that's probably sufficient.  But the moment the structure
of the NVRAM variable used by linux user space and EFI application changes
this would break.  So because of that it's safer to block installation.

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Limonciello, Mario]

> -Original Message-
> From: Boyuan Yang 
> Sent: Tuesday, November 3, 2020 13:09
> To: sub...@bugs.debian.org
> Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly
> 
> Package: fwupd-amd64-signed
> Severity: grave
> Version: 1.4.6+2
> X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com
> 
> Dear EFI Team,
> 
> Package fwupd-amd64-signed currently cannot be installed on Debian
> Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has fwupd
> (= 1.4.6-2+b1).

I'm sorry can you show me where this +b1 build is?

I don't see it mentioned in https://tracker.debian.org/pkg/fwupd

> 
> It seems obvious that such dependency relationship made fwupd/fwupd-
> amd64-signed not binNMU-friendly. Please consider setting a version
> range to allow binNMU-ed package to satisfy the dependency
> relationship.
> 
> Thanks,
> Boyuan Yang

Bug#973267: Acknowledgement (libtss2-dev: pkgconfig file included with libtss2-dev has invalid path)

[Limonciello, Mario]

Submitted this to upstream project:
https://github.com/tpm2-software/tpm2-tss/issues/1876

Bug#970054: fwupd: Missing Depends (or Recommends) on udisks2 for UEFI update

[Limonciello, Mario]

Thanks for the report, and submitting the fix upstream!

I agree, it should probably be a recommends and we should pull that patch in
for safety.  I'll include it in a 1.4.6-2 upload once we merge it upstream.

Thanks!

> -Original Message-
> From: Jochen Sprickerhof 
> Sent: Thursday, September 10, 2020 17:08
> To: Debian Bug Tracking System
> Subject: Bug#970054: fwupd: Missing Depends (or Recommends) on udisks2 for
> UEFI update
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.4.6-1
> Severity: normal
> 
> Hi,
> 
> starting with 1.4.6 (or 25ba4157) fwupdmgr connects to
> /org/freedesktop/UDisks2/Manager to get the ESP. You can see this by
> running
> 
> dbus-monitor --system
> 
> while doing a
> 
> fwupdtool esp-list
> 
> with out udisks2 installed I get a segfault and fwupdmgr does not opt to
> update the UEFI. I proposed a fix to the segfault here:
> 
> https://github.com/fwupd/fwupd/pull/2384
> 
> Still there should be a dependency on udisks2 (or a way to work without
> it).
> 
> Cheers Jochen
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libc6  2.31-3
> ii  libefiboot137-5
> ii  libefivar1 37-5
> ii  libelf10.180-1+b1
> ii  libflashrom1   1.2-5
> ii  libfwupd2  1.4.6-1
> ii  libfwupdplugin11.4.6-1
> ii  libglib2.0-0   2.64.4-1
> ii  libgudev-1.0-0 233-1
> ii  libgusb2   0.3.4-0.2
> ii  libjcat1   0.1.3-2
> ii  libjson-glib-1.0-0 1.4.4-2
> ii  libpolkit-gobject-1-0  0.105-29
> ii  libsmbios-c2   2.4.3-1
> ii  libsoup2.4-1   2.70.0-1
> ii  libsqlite3-0   3.33.0-1
> ii  libtss2-esys0  3.0.0-1
> ii  libxmlb1   0.1.15-2
> ii  shared-mime-info   1.15-1
> 
> Versions of packages fwupd recommends:
> pn  bolt  
> pn  fwupd-signed  
> ii  python3   3.8.2-3
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Limonciello, Mario]

I would suggest a new issue linking to that one instead so it's not lost.

> -Original Message-
> From: Michel Le Bihan 
> Sent: Monday, July 27, 2020 1:01 PM
> To: Limonciello, Mario; 963...@bugs.debian.org
> Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not
> parse device path: Invalid argument"
> 
> 
> [EXTERNAL EMAIL]
> 
> I added a comment under the existing closed issue:
> https://github.com/rhboot/efibootmgr/issues/133#issuecomment-664549236
> 
> Le lundi 27 juillet 2020 à 17:54 +, Limonciello, Mario a écrit :
> > In that case, would you mind reporting a bug to upstream efibootmgr?
> > It seems
> > to me that your Boot entry can't be properly parsed.  You may
> > need to also
> > attach it to your bug report.
> >
> > > -----Original Message-
> > > From: Michel Le Bihan 
> > > Sent: Monday, July 27, 2020 12:16 PM
> > > To: Limonciello, Mario; 963...@bugs.debian.org
> > > Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > "Could not
> > > parse device path: Invalid argument"
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > It was efibootmgr and efivar master.
> > >
> > > Le lundi 27 juillet 2020 à 16:46 +, Limonciello, Mario a écrit
> > > :
> > > > Was that just efibootmgr master?
> > > > If possible, can you move up to *both* efivar master and
> > > > efibootmgr
> > > > master and try again?
> > > >
> > > > > -Original Message-
> > > > > From: Michel Le Bihan 
> > > > > Sent: Monday, July 27, 2020 11:25 AM
> > > > > To: Limonciello, Mario; 963...@bugs.debian.org
> > > > > Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > > > "Could not
> > > > > parse device path: Invalid argument"
> > > > >
> > > > >
> > > > > [EXTERNAL EMAIL]
> > > > >
> > > > > Hello,
> > > > >
> > > > > I applied the fix and built the package. It didn't help. I also
> > > > > built
> > > > > latest master and I still have this issue.
> > > > >
> > > > > BTW, the computer is an OptiPlex 7040. Full hwinfo --bios:
> > > > > https://lebihan.pl/files/hwinfo-bios.txt
> > > > >
> > > > > Error trace:
> > > > > ```
> > > > > root@s217-lab00:~# /dev/shm/efibootmgr/src/efibootmgr -v
> > > > > BootCurrent: 0003
> > > > > Timeout: 2 seconds
> > > > > BootOrder: 0003,0004,0001,0005,000A,0007,0008,0009,0002
> > > > > Boot* Windows Boot ManagerCould not parse device path:
> > > > > Invalid
> > > > > argument
> > > > > error trace:
> > > > >  /build/efivar-yvRv8P/efivar-37/src/include/efivar/efivar-
> > > > > dp.h:1208
> > > > > efidp_is_valid(): invalid device path node type: Invalid
> > > > > argument
> > > > > ```
> > > > >
> > > > > Michel Le Bihan
> > > > >
> > > > > Le lundi 27 juillet 2020 à 15:28 +, Limonciello, Mario a
> > > > > écrit
> > > > > :
> > > > > > > -Original Message-
> > > > > > > From: Michel Le Bihan 
> > > > > > > Sent: Sunday, July 26, 2020 2:58 PM
> > > > > > > To: 963...@bugs.debian.org
> > > > > > > Subject: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > > > > > "Could
> > > > > > > not
> > > > > > > parse device path: Invalid argument"
> > > > > > >
> > > > > > >
> > > > > > > [EXTERNAL EMAIL]
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > What's preventing the upstream fix from being applied to
> > > > > > > this
> > > > > > > package?
> > > > > > >
> > > > > > > Michel Le Bihan
> > > > > >
> > > > > > I personally can't reproduce the failure on my system's
> > > > > > firmware.
> > > > > > Can you apply the fix locally and confirm it actually helps?

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Limonciello, Mario]

In that case, would you mind reporting a bug to upstream efibootmgr? It seems
to me that your Boot entry can't be properly parsed.  You may need to also
attach it to your bug report.

> -Original Message-
> From: Michel Le Bihan 
> Sent: Monday, July 27, 2020 12:16 PM
> To: Limonciello, Mario; 963...@bugs.debian.org
> Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not
> parse device path: Invalid argument"
> 
> 
> [EXTERNAL EMAIL]
> 
> It was efibootmgr and efivar master.
> 
> Le lundi 27 juillet 2020 à 16:46 +, Limonciello, Mario a écrit :
> > Was that just efibootmgr master?
> > If possible, can you move up to *both* efivar master and efibootmgr
> > master and try again?
> >
> > > -Original Message-
> > > From: Michel Le Bihan 
> > > Sent: Monday, July 27, 2020 11:25 AM
> > > To: Limonciello, Mario; 963...@bugs.debian.org
> > > Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > "Could not
> > > parse device path: Invalid argument"
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hello,
> > >
> > > I applied the fix and built the package. It didn't help. I also
> > > built
> > > latest master and I still have this issue.
> > >
> > > BTW, the computer is an OptiPlex 7040. Full hwinfo --bios:
> > > https://lebihan.pl/files/hwinfo-bios.txt
> > >
> > > Error trace:
> > > ```
> > > root@s217-lab00:~# /dev/shm/efibootmgr/src/efibootmgr -v
> > > BootCurrent: 0003
> > > Timeout: 2 seconds
> > > BootOrder: 0003,0004,0001,0005,000A,0007,0008,0009,0002
> > > Boot* Windows Boot ManagerCould not parse device path: Invalid
> > > argument
> > > error trace:
> > >  /build/efivar-yvRv8P/efivar-37/src/include/efivar/efivar-dp.h:1208
> > > efidp_is_valid(): invalid device path node type: Invalid argument
> > > ```
> > >
> > > Michel Le Bihan
> > >
> > > Le lundi 27 juillet 2020 à 15:28 +, Limonciello, Mario a écrit
> > > :
> > > > > -Original Message-
> > > > > From: Michel Le Bihan 
> > > > > Sent: Sunday, July 26, 2020 2:58 PM
> > > > > To: 963...@bugs.debian.org
> > > > > Subject: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > > > "Could
> > > > > not
> > > > > parse device path: Invalid argument"
> > > > >
> > > > >
> > > > > [EXTERNAL EMAIL]
> > > > >
> > > > > Hello,
> > > > >
> > > > > What's preventing the upstream fix from being applied to this
> > > > > package?
> > > > >
> > > > > Michel Le Bihan
> > > >
> > > > I personally can't reproduce the failure on my system's firmware.
> > > > Can you apply the fix locally and confirm it actually helps?

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Limonciello, Mario]

> -Original Message-
> From: Michel Le Bihan 
> Sent: Sunday, July 26, 2020 2:58 PM
> To: 963...@bugs.debian.org
> Subject: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not
> parse device path: Invalid argument"
> 
> 
> [EXTERNAL EMAIL]
> 
> Hello,
> 
> What's preventing the upstream fix from being applied to this package?
> 
> Michel Le Bihan

I personally can't reproduce the failure on my system's firmware.
Can you apply the fix locally and confirm it actually helps?

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Limonciello, Mario]

Was that just efibootmgr master?
If possible, can you move up to *both* efivar master and efibootmgr master and 
try again?

> -Original Message-
> From: Michel Le Bihan 
> Sent: Monday, July 27, 2020 11:25 AM
> To: Limonciello, Mario; 963...@bugs.debian.org
> Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not
> parse device path: Invalid argument"
> 
> 
> [EXTERNAL EMAIL]
> 
> Hello,
> 
> I applied the fix and built the package. It didn't help. I also built
> latest master and I still have this issue.
> 
> BTW, the computer is an OptiPlex 7040. Full hwinfo --bios:
> https://lebihan.pl/files/hwinfo-bios.txt
> 
> Error trace:
> ```
> root@s217-lab00:~# /dev/shm/efibootmgr/src/efibootmgr -v
> BootCurrent: 0003
> Timeout: 2 seconds
> BootOrder: 0003,0004,0001,0005,000A,0007,0008,0009,0002
> Boot* Windows Boot ManagerCould not parse device path: Invalid
> argument
> error trace:
>  /build/efivar-yvRv8P/efivar-37/src/include/efivar/efivar-dp.h:1208
> efidp_is_valid(): invalid device path node type: Invalid argument
> ```
> 
> Michel Le Bihan
> 
> Le lundi 27 juillet 2020 à 15:28 +, Limonciello, Mario a écrit :
> > > -Original Message-
> > > From: Michel Le Bihan 
> > > Sent: Sunday, July 26, 2020 2:58 PM
> > > To: 963...@bugs.debian.org
> > > Subject: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could
> > > not
> > > parse device path: Invalid argument"
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hello,
> > >
> > > What's preventing the upstream fix from being applied to this
> > > package?
> > >
> > > Michel Le Bihan
> >
> > I personally can't reproduce the failure on my system's firmware.
> > Can you apply the fix locally and confirm it actually helps?