Boron alpha 1 iso available for testing and feedback

johnraff · 2023-07-20 05:45:45

I spent most of this morning websearching the raspi-firmware issue, and lots of people have been hit by it - plenty of discussion on the Debian forums.

TL:DR For people who just want to fix their computers and move on, see here:
https://forums.debian.net/viewtopic.php?t=155245
Summarized, very carefully copy these commands and run them in a terminal:
echo /etc/{initramfs/post-update.d/,kernel/{postinst.d/,postrm.d/}}z50-raspi-firmware
and check you get a list of three raspi-firmware files, then re-run it with rm:
sudo rm /etc/{initramfs/post-update.d/,kernel/{postinst.d/,postrm.d/}}z50-raspi-firmware
Purge the package:

sudo apt purge raspi-firmware

finally, super-carefully:

sudo rm -rf /boot/firmware

EDIT Thanks to @unklar for discovering that an apt purge is enough to get rid of the unwanted files under /etc/.
---
Details:

There are two issues here:

1) The deb package raspi-firmware was badly made and doesn't cleanly uninstall, leaving junk on your system - many megabytes: https://bugs.debian.org/cgi-bin/bugrepo … ug=1035783

2) The recent debian live isos included raspi-firmware even for amd64 systems, loading them with (~100MB?) of unnecessary files: https://bugs.debian.org/cgi-bin/bugrepo … ug=1035382

Debian live isos, after a period using live-wrapper, are now like BunsenLabs built with live-build. Live-build is where the unwanted raspi-firmware came from. Debian's handling of non-free firmware has changed dramatically with Bookworm, and there's obviously still some cleaning up to do. The Debian devs seem determined to get the issue fixed for their live isos in time for point release 12.1 on Saturday 22nd July, but while the fix to live-build itself has already been committed it will probably be some time before a new version is released, migrated to Sid, to Trixie and hopefully backported to Bookworm.

We can't afford to wait that long, so we have two choices I think:
1) Use live-build as it is in the git repo right now, and take our chances there are no regressions or conflicts with Bookworm.
2) Apply that single commit as a patch on the Bookworm live-build before doing our next build, and hope it doesn't clash with anything. (It looks safe enough to me.)
I propose going with 2). We already have a mechanism in our live-build configs for applying patches at build time.

Either way, the next BL iso build should be a bit smaller from losing the unnecessary firmware.

Last edited by johnraff (2023-07-20 11:22:32)

johnraff · 2023-07-20 05:56:09

hhh wrote:

The OOTB notification theme is wrong, it should be changed from "default" to "Boron-light-aqua".

I noticed this too, and it's a bit mysterious. Previously "default" set the notification popup to whatever GTK theme had been set for the system. If we have to set it to "Boron-light-aqua" then users will have to change it every time they switch GTK theme, which is less than optimal. I hope there's a simple tweak we can do so Boron-light-aqua gets recognized by default.

re: removing the live-build packages problem, I think the issue should be moved to it's own thread. It's actually a minor issue IMO, the whole OS install only takes up about 4.5 GiB of space as it is now. The installed size of live-config-systemd is 23kB...

Minor issue because it's easily fixed with a live-build hook. But regardless of installation size it's not good for normal systems to have those live-* packages installed because they might be tweaking things in subtle ways and causing mysterious bugs.

unklar · 2023-07-20 07:10:01

johnraff wrote:

I spent most of this morning websearching the raspi-firmware issue, and lots of people have been hit by it - plenty of discussion on the Debian forums.
TL:DR For people who just want to fix their computers and move on, see here:
--snip

@johnraff,

+1

Since I already used the purge command for the raspi firmware, as described earlier, the following does not result in three more files:

sudo rm /etc/{initramfs/post-update.d/,kernel/{postinst.d/,postrm.d/}}z50-raspi-firmware
[sudo] Passwort für unklar: 
rm: das Entfernen von '/etc/initramfs/post-update.d/z50-raspi-firmware' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: das Entfernen von '/etc/kernel/postinst.d/z50-raspi-firmware' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: das Entfernen von '/etc/kernel/postrm.d/z50-raspi-firmware' ist nicht möglich: Datei oder Verzeichnis nicht gefunden

So it is sufficient for me:

sudo rm -rf /boot/firmware

Thank you, for your time.

johnraff · 2023-07-20 11:13:59

unklar wrote:

Since I already used the purge command for the raspi firmware, as described earlier, the following does not result in three more files:

sudo rm /etc/{initramfs/post-update.d/,kernel/{postinst.d/,postrm.d/}}z50-raspi-firmware
[sudo] Passwort für unklar: 
rm: das Entfernen von '/etc/initramfs/post-update.d/z50-raspi-firmware' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: das Entfernen von '/etc/kernel/postinst.d/z50-raspi-firmware' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: das Entfernen von '/etc/kernel/postrm.d/z50-raspi-firmware' ist nicht möglich: Datei oder Verzeichnis nicht gefunden

So it is sufficient for me:

sudo rm -rf /boot/firmware

Ah, thank you - it's consistent with that bug report - which only mentions /boot/firmware - and the Debian forum poster forgot to try --purge first I guess. I'll edit my post.

cog · 2023-07-21 03:23:17

@johnraff

Please see the following to remove raspi firmware in livebuild/d-i

https://github.com/troutcobbler/hatcher … reseed.cfg

/boot/firmware will still be left over but it's harmless

cog · 2023-07-21 03:24:20

since you don't have the other packages installed the last line should simply be

in-target apt-get -y autopurge raspi-firmware

johnraff · 2023-07-21 04:53:52

Thanks cog - /boot/firmware might be harmless, but it's pretty big (~72M) and it doesn't belong there so I think it's best to remove it.

In live-build, I'd rather not install a raspberry pi package in the first place than have to remove it later. Also there are other unwanted ARM firmware packages that live-build 1:20230502 installs and I'd like to apply the fix I linked above: https://salsa.debian.org/live-team/live … a453eb6307

(For an amd64 system it blocks: arm-trusted-firmware-tools crust-firmware firmware-qcom-soc firmware-samsung firmware-ti-connectivity raspi-firmware )

The firmware that Debian recently started bundling bulks up isos quite a bit, so let's at least not install stuff that doesn't belong in the first place.

That commit is just a patch on one file and doesn't look as if it would interfere with anything else in lb 1:20230502.

Last edited by johnraff (2023-07-21 06:35:42)

cog · 2023-07-21 05:16:18

@johnraff That's how sleekmason & I both handled it on both of our separate projects. Just passing that info along in case it's of any use.

Last edited by cog (2023-07-21 05:16:56)

cog · 2023-07-21 05:21:55

As you can see his config is similar to mine. We colaborated when stuff was borking out back during the debian testing phase.

https://github.com/sleekmason/Lilidog-B … reseed.cfg

johnraff · 2023-07-21 05:26:29

...why I prefer to wait a bit. Give things time to shake out.

But appreciate the suggestion, even if I go another route.

Last edited by johnraff (2023-07-21 05:28:04)

cog · 2023-07-21 05:30:59

best of luck

johnraff · 2023-07-21 05:47:18

Thanks!

johnraff · 2023-07-21 09:45:23

I just tested the patch from Debian Git and it seemed to work OK without breaking anything.
@cog and @sleekmason, you might try this (two ways):
Either way, make a backup copy of /usr/share/live/build/functions/firmwarelists.sh first (of course).

1) Copy the new file from here: https://salsa.debian.org/live-team/live … relists.sh and paste it into firmwarelists.sh.

or

2) On this page: https://salsa.debian.org/live-team/live … a453eb6307
Top right "Options", choose "Download Patches" to get 8eaf20daf1cf79669975b1acfe4d6fa453eb6307.patch
Then you can patch firmwarelists.sh:

sudo patch -u /usr/share/live/build/functions/firmwarelists.sh -i /path/to/8eaf20daf1cf79669975b1acfe4d6fa453eb6307.patch

Take the remove raspi-firmware part out of preseed.cfg, run live build, install and check that all those ARM firmware files are gone.

sleekmason · 2023-07-21 15:06:54

@johnraff & @cog, The fix above works well, and as a bonus, also takes care of the issue in the Calamares installer if used. Nice.) Thank you for posting the solution. Still testing, but so far so good.

Last edited by sleekmason (2023-07-21 17:36:00)

cog · 2023-07-21 19:17:07

@johnraff Thanks, that’s a cleaner solution. I’m gonna backport it to live-build in my repos. Thanks again.

cog · 2023-07-21 23:01:53

I might edit the patch some. I’ve got an nvidia user that might need that stuff.

johnraff · 2023-07-22 00:25:24

This is a fix for iso builders, @hhh, @rbh, @cog, @sleekmason...

johnraff wrote:

hhh wrote:
re: removing the live-build packages problem, I think the issue should be moved to it's own thread. It's actually a minor issue IMO, the whole OS install only takes up about 4.5 GiB of space as it is now. The installed size of live-config-systemd is 23kB...
Minor issue because it's easily fixed with a live-build hook. But regardless of installation size it's not good for normal systems to have those live-* packages installed because they might be tweaking things in subtle ways and causing mysterious bugs.

And the fix is very simple, though it means another (small) edit to a live-build file:
Open /usr/lib/live/build/config in a root text editor,
find line 1373:

LIVE_PKG_LIST="config/package-lists/live.list.chroot"

and rename live.list.chroot with a _live suffix:

LIVE_PKG_LIST="config/package-lists/live.list.chroot_live"

Save the file and your next iso build should do the Right Thing and remove the unwanted live-boot and friends at the install stage.

cog · 2023-07-22 04:12:43

@johnraff A little confused on what y’all are accomplishing here ^.

I don’t have any unwanted live* packages left over after installation. D-I seems to do that just fine without telling it to. I do like using preseed.config to remove calamares etc though. It’s a little more akin to the way calamares removes packages after installation.

On a different note. The patch works great BTW. I put a patched version of live-build in my repos earlier.

Last edited by cog (2023-07-22 04:15:21)

johnraff · 2023-07-22 04:37:57

It's a subtle issue with l-b in that if there are no live-only packages listed in a config/package-lists/*.list.chroot_live file, then in the iso there is no live/filesystem.packages-remove file. OK, in that case (the most common case) the Debian installer falls back to a manual remove list of: live-boot live-boot-initramfs-tools live-config live-config-runit live-config-systemd live-config-sysvinit live-config-upstart debian-installer-launcher casper calamares-settings-debian and everything's pretty much fine. (Do you maybe have live-boot-doc and live-config-doc left on your installed systems? They would do no harm of course.)

But in BL we have bunsen-configs-live to set a slightly different menu etc on the live system, so that's listed in extra.list.chroot_live and gets put in filesystem.packages-remove. Any package wanted only in live systems will trigger that. That means that the installer doesn't do the manual removal and removes what it finds in filesystem.packages-remove instead. Unfortunately, l-b as-is doesn't put the live-* packages in there - it treats them like regular "install" packages, so the installer doesn't remove them. This happens only when there's a *.list.chroot_live file.

Renaming the LIVE_PKG_LIST file makes l-b treat the live-* packages as only for the live system, which is correct AFAICS.

I'm going to consult the live-build mailing list to see what they think of this, if it's a bug or not.

cog · 2023-07-22 04:45:00

Make sense now. In the couple days it took to figure out live-build I had noticed that the package lists prefixed with live or however your suppose to name them according to the manual to have them only in a live session and then removed on d-I was totally borked lately. So I gave up on it and resorted to preseed.cfg

I’m guessing your previous post fixes that now. Good stuff man.

(PS I’m not seeing live-boot-doc left over either)

Last edited by cog (2023-07-22 04:49:00)

#21 2023-07-20 05:45:45

Re: Boron alpha 1 iso available for testing and feedback

#22 2023-07-20 05:56:09

Re: Boron alpha 1 iso available for testing and feedback

#23 2023-07-20 07:10:01

Re: Boron alpha 1 iso available for testing and feedback

#24 2023-07-20 11:13:59

Re: Boron alpha 1 iso available for testing and feedback

#25 2023-07-21 03:23:17

Re: Boron alpha 1 iso available for testing and feedback

#26 2023-07-21 03:24:20

Re: Boron alpha 1 iso available for testing and feedback

#27 2023-07-21 04:53:52

Re: Boron alpha 1 iso available for testing and feedback

#28 2023-07-21 05:16:18

Re: Boron alpha 1 iso available for testing and feedback

#29 2023-07-21 05:21:55

Re: Boron alpha 1 iso available for testing and feedback

#30 2023-07-21 05:26:29

Re: Boron alpha 1 iso available for testing and feedback

#31 2023-07-21 05:30:59

Re: Boron alpha 1 iso available for testing and feedback

#32 2023-07-21 05:47:18

Re: Boron alpha 1 iso available for testing and feedback

#33 2023-07-21 09:45:23

Re: Boron alpha 1 iso available for testing and feedback

#34 2023-07-21 15:06:54

Re: Boron alpha 1 iso available for testing and feedback

#35 2023-07-21 19:17:07

Re: Boron alpha 1 iso available for testing and feedback

#36 2023-07-21 23:01:53

Re: Boron alpha 1 iso available for testing and feedback

#37 2023-07-22 00:25:24

Re: Boron alpha 1 iso available for testing and feedback

#38 2023-07-22 04:12:43

Re: Boron alpha 1 iso available for testing and feedback

#39 2023-07-22 04:37:57

Re: Boron alpha 1 iso available for testing and feedback

#40 2023-07-22 04:45:00

Re: Boron alpha 1 iso available for testing and feedback

Board footer