Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

Tentative fix, for what it's worth:

https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/19

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1012859: Info received (Syslog)

[Nicholas D Steeves]

Dear Leslie,

I'm sorry no one noticed your bug.  Reply follows inline:

Jeremy, thank you for following up on this bug!  This brought the bug to
my attention :)

Leslie Rhorer  writes:

> On 7/13/2023 5:18 PM, Jeremy Davis wrote:
>> [Just a random passer-by that might have an idea?]
>>
>> It looks to me like you are missing the firmware-realtek[1][2] 
>> (non-free) package?!
>
>      No, I am not missing it.  The package is broken in Bullseye. The 
> firmware is there, but does not work.  It worked just fine in Buster, 
> but when I upgraded to Bullseye, the 10G NIC completely quit working.  
> It's been over a year, so I don't recall everything I did, but I spent 
> many, many hours trying to get the new firmware working, and many more 
> hours trying to extract the firmware from the oldstable package, and 
> then quite a few more hours trying  to compile from source, but nothing 
> worked.  I could not even get the source code to compile.

Given your intention to upgrade from buster to bullseye, here is what
you can try (please read to the end of this email first, because an
alternative method is a better use of your time):

1a. Enable bullseye-backports (non-free), and 'apt install -t
bullseye-backports firmware-linux firmware-misc-nonfree' which is
currently 20230210-4~bpo11+1

2a. Reboot

3a. If both your NICs work, then it's a firmware bug.  If this is the
case, please report a bug against firmware-linux-nonfree 20210315-3.

--

1b. If the steps above are insufficient, 'apt install -t
bullseye-backports linux-image-amd64' which is currently
6.1.20-2~bpo11+1

2b. Reboot.  GRUB should automatically choose the backports kernel.

3b. Your NICs should work at this point.  If they do, and you'd like to
report a bug against the linux-image-amd64 version in bullseye, then
please go ahead and do so, but please make sure that you've tested
5.10.178-3 before doing so:)

>      The bottom line is the firmware from the Buster non-free distro 
> works perfectly well, but noone has come forth with a fix for Bullseye, 
> and I have no reason to believe the firmware from Bookworm will work.  
> The NIC is an Asus PEB-10G/57811-1S 10GbE SFP+ Network Adapter which 
> employs a BCM 57811S controller.

Maybe nobody knows that this specific hardware is broken?  It may be
that the Asus PEB-10G/57811-1S has some hardware quirks that Broadcom
doesn't know about.  In your original bug log you'll notice this snippet

 RTL8211E Gigabit Ethernet

which is the Realtek one, Gibabit, RJ45 copper.  I wonder if this one is
a completely different NIC built into your motherboard.  ie: the
historically very buggy Realtek 8111E?

Alternatively, if the 10GbE SFP+ PCIe adapter NIC uses a Realtek for
gigabit PHY, then the nature of the bug could be that both both Realtek
and Broadcom broke your NIC (either in the firmware on in the driver, or
both).

>> If you haven't already tried, I'd suggest that you try a clean 
>> bookworm install from ISO. FWIW bookworm now includes a separate 
>> "non-free-firmware" repo that is enabled by default. So the official 
>> installer should "just work".
>      I can try, but I really would not be well advised to do so until I 
> can get the dead system working again.

Jeremy is right about how bookworm includes non-free-firmware by
default, and also that the state of your hardware with bookworm should
be tested first.

The best use of your time will be to test with live media (USB or DVD).
If you'd like to have a GUI for your test, please choose a variant you
recognise and are comfortable with.  The "standard" flavour is CLI only,
which--alternatively--might be what you want (it's a smaller download ).

https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/

If the problem still exists in bookworm, then it needs to be fixed in
bookworm before the fix can be backported to buster, and the live media
is the fastest way to test this.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1012859: Info received (Syslog)

[Jeremy Davis]

[Just a random passer-by that might have an idea?]

On 14/7/23 07:14, Leslie Rhorer wrote:
     I filed report 1012859 to the Debian BTS over a year ago. Nothing 
has been done so far, and I have one cripped system and one dead system 
that needs to be upgraded to the most recent version, but I can't really 
proceed until the proper files get included into the Debian distro.  Can 
someone please help?


It looks to me like you are missing the firmware-realtek[1][2] 
(non-free) package?!


[1] https://packages.debian.org/bullseye/firmware-realtek
[2] https://packages.debian.org/bookworm/firmware-realtek

If you haven't already tried, I'd suggest that you try a clean bookworm 
install from ISO. FWIW bookworm now includes a separate 
"non-free-firmware" repo that is enabled by default. So the official 
installer should "just work".


If not, then I would suggest opening a new bug against the current 
installer. In the meantime, try manually installing the package (e.g. 
copy the deb via a USB stick).


Hope that helps.

Regards,
Jeremy


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040010: [debian-installer] Please support more arm64 boards

[Roman Mamedov]

On Fri, 14 Jul 2023 00:33:25 +0500
Roman Mamedov  wrote:

> There isn't really an image per board, but at least a clever system of
> concatenating a board-specific bootloader and a board-agnostic rest of the
> image. That looks reasonable enough, and I suppose building the current
> 12 bootloaders is automated. Maybe add all 42 to that automation for now?

Or actually, that was 42 just for Allwinner, and much much more if you include
other vendors. So adding them all to the regular build might not be as
feasible after all. I remember now, that's why I proposed building them all
not daily, but at least once per month.

-- 
With respect,
Roman

Bug#1040010: [debian-installer] Please support more arm64 boards

[Roman Mamedov]

Hello,

On Thu, 13 Jul 2023 21:27:09 +0200
Emanuele Rocca  wrote:

> On 2023-07-01 04:18, Roman Mamedov wrote:
> > There are 42 DTBs shipped with the installer for Allwinner alone:
> > https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/
> > 
> > But for the bootloader aka firmware aka u-boot:
> > https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
> > it is an extremely weird and arbitrary list of 12 random boards. For 
> > instance
> > supporting "Orange Pi Zero Plus2" of all things specifically, not even just
> > "Zero Plus"; and not, say, Orange Pi Prime or Orange Pi Win (and so on).
> 
> The choice of 12 boards does indeed look a little puzzling. Having no
> historical background on this, I can try and guess that they were added
> on a case-by-case basis every time someone needed to boot the installer
> on their system. Out of interest: do you have a board that's not among
> the lucky 12? :-)

Yes, as a weird coincidence with my initial message, I have an Orange Pi Prime
and Orange Pi Win. :)

> > So despite having all the other DTBs, the system is not installable on those
> > boards. Unless the user is sent to find and compile their own u-boot, but if
> > so, what is the purpose of randomly providing it for 12 random niche boards 
> > to
> > begin with, might as well make everyone do that.
> > 
> > Instead, I suggest a better solution: maybe not even daily, but at least 
> > once
> > per month, could you build a bootloader part for ALL the supported boards, 
> > and
> > not just a handful of them.
> 
> In an ideal world we would have just one single image that works on all
> systems! That's one of the ideas behind the Arm SystemReady
> certification program at least: making sure that the board can boot a
> regular, unmodified distro ISO without any additional blobs.
> 
> We don't live in such a world unfortunately, at least not yet and not
> for all boards. I'm not sure we should have one different image for each
> DTB honestly. I'd rather go for having no custom images at all, but a
> very simple procedure to build your own image for your board. Maybe in
> the form of documentation, or a script, or both.

There isn't really an image per board, but at least a clever system of
concatenating a board-specific bootloader and a board-agnostic rest of the
image. That looks reasonable enough, and I suppose building the current
12 bootloaders is automated. Maybe add all 42 to that automation for now?

-- 
With respect,
Roman

Bug#1040010: [debian-installer] Please support more arm64 boards

[Emanuele Rocca]

Hello Roman,

On 2023-07-01 04:18, Roman Mamedov wrote:
> There are 42 DTBs shipped with the installer for Allwinner alone:
> https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/
> 
> But for the bootloader aka firmware aka u-boot:
> https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
> it is an extremely weird and arbitrary list of 12 random boards. For instance
> supporting "Orange Pi Zero Plus2" of all things specifically, not even just
> "Zero Plus"; and not, say, Orange Pi Prime or Orange Pi Win (and so on).

The choice of 12 boards does indeed look a little puzzling. Having no
historical background on this, I can try and guess that they were added
on a case-by-case basis every time someone needed to boot the installer
on their system. Out of interest: do you have a board that's not among
the lucky 12? :-)
 
> So despite having all the other DTBs, the system is not installable on those
> boards. Unless the user is sent to find and compile their own u-boot, but if
> so, what is the purpose of randomly providing it for 12 random niche boards to
> begin with, might as well make everyone do that.
> 
> Instead, I suggest a better solution: maybe not even daily, but at least once
> per month, could you build a bootloader part for ALL the supported boards, and
> not just a handful of them.

In an ideal world we would have just one single image that works on all
systems! That's one of the ideas behind the Arm SystemReady
certification program at least: making sure that the board can boot a
regular, unmodified distro ISO without any additional blobs.

We don't live in such a world unfortunately, at least not yet and not
for all boards. I'm not sure we should have one different image for each
DTB honestly. I'd rather go for having no custom images at all, but a
very simple procedure to build your own image for your board. Maybe in
the form of documentation, or a script, or both.

  Emanuele

Re: Bug#1040868: bookworm-pu: package glibc/2.36-9+deb12u1

[Aurelien Jarno]

Hi Adam,

On 2023-07-13 17:01, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2023-07-11 at 20:51 +0200, Aurelien Jarno wrote:
> > The upstream stable branch got a few fixes during the bookworm freeze
> > period, and this update pulls them into the debian package. In short:
> >  - Fix a buffer overflow and memory corruption in the gmon
> >functionality.
> >  - Fix a deadlock in getaddrinfo() and system() functions
> >  - Fix y2038 support in strftime on 32-bit architectures.
> >  - Fix possible segmentation fault in applications using sgetsgent()
> >when /etc/gshadow contains very long lines
> >  - Fix support for old C90 compilers.
> > 
> > In addition this include a Slovak translation update fixing typos,
> > that
> > 
> 
> Please go ahead, bearing in mind that the window for 12.1 closes over
> the coming weekend.

Thanks for the review, I have just uploaded it.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Re: Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

[Adam D. Barratt]

On Thu, 2023-07-13 at 17:51 +0100, Simon McVittie wrote:
> On Thu, 13 Jul 2023 at 16:58:54 +0100, Adam D. Barratt wrote:
> > On Wed, 2023-07-12 at 12:34 +0100, Simon McVittie wrote:
> > > On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote:
> > > > [ Reason ]
> > > > https://bugs.debian.org/1040790
> > 
> > Please go ahead, bearing in mind that the window for 12.1 closes
> > over
> > the coming weekend.
> 
> I uploaded it already, it's in
> ;. The
> corresponding unstable update should reach testing tomorrow.
> 

Heh, that'll teach me to catch up on e-mail before reviewing the queue.

> I'm sorry for the timing. I fixed it as fast as I was able, as soon
> as I was aware of the issue (I know both should have happened
> quicker).
> 

FTAOD, it absolutely wasn't a complaint, rather just making sure you
were aware of the date.

Regards,

Adam

Re: Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

[Simon McVittie]

On Thu, 13 Jul 2023 at 16:58:54 +0100, Adam D. Barratt wrote:
> On Wed, 2023-07-12 at 12:34 +0100, Simon McVittie wrote:
> > On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote:
> > > [ Reason ]
> > > https://bugs.debian.org/1040790
> 
> Please go ahead, bearing in mind that the window for 12.1 closes over
> the coming weekend.

I uploaded it already, it's in
. The
corresponding unstable update should reach testing tomorrow.

I'm sorry for the timing. I fixed it as fast as I was able, as soon as
I was aware of the issue (I know both should have happened quicker).

smcv

Re: Bug#1040868: bookworm-pu: package glibc/2.36-9+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2023-07-11 at 20:51 +0200, Aurelien Jarno wrote:
> The upstream stable branch got a few fixes during the bookworm freeze
> period, and this update pulls them into the debian package. In short:
>  - Fix a buffer overflow and memory corruption in the gmon
>functionality.
>  - Fix a deadlock in getaddrinfo() and system() functions
>  - Fix y2038 support in strftime on 32-bit architectures.
>  - Fix possible segmentation fault in applications using sgetsgent()
>when /etc/gshadow contains very long lines
>  - Fix support for old C90 compilers.
> 
> In addition this include a Slovak translation update fixing typos,
> that
> 

Please go ahead, bearing in mind that the window for 12.1 closes over
the coming weekend.

Regards,

Adam

Re: Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-07-12 at 12:34 +0100, Simon McVittie wrote:
> On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote:
> > [ Reason ]
> > https://bugs.debian.org/1040790
> > [ Changes ]
> > All changes are part of resolving or testing #1040790.
> 
> Debdiff attached.
> 
> > [ Tests ]
> 
> I should also have mentioned that I'm running the proposed package on
> a bookworm desktop system and it works normally.
> 

Please go ahead, bearing in mind that the window for 12.1 closes over
the coming weekend.

Regards,

Adam

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

Following up with that, it seems that the failure is due to a change in 
the kernel.


I'm testing 2 Kali netinst ISOs, one from last week (no problem), and a 
daily iso from today (which fails).


Last weekly iso had kernel 6.1.0-kali9-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives nothing, hence the grub-installer 
postinst doesn't try to mount the efivarfs.


Today's iso has kernel 6.3.0-kali1-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives `nodev efivarfs`, hence the 
grub-installer postinst tries to mount efivarfs, and fails.


--
Arnaud Rebillout / OffSec / Kali Linux Developer