miscellaneous development log

Patrick · November 10, 2023, 7:11pm

Patrick · November 13, 2023, 3:46pm

CodeQL vulnerability scanning enabled for all projects containing non-trivial C or C++ code:

LKRG
hardned-malloc
bindp
kloak

Patrick · November 13, 2023, 3:47pm

Avoid intermediary installation of initramfs-tools when using INITRD_GENERATOR=dracut. by adrelanos · Pull Request #236 · grml/grml-debootstrap · GitHub

github.com/grml/grml-debootstrap

busybox should be moved to local packages file instead of being hardcoded in chroot-script

opened 03:45PM - 13 Nov 23 UTC

adrelanos

busybox had some security vulnerabilities. I didn't check how severe these were …or how to exploit there. However, busybox doesn't seem to be a a critically required dependency for a fully functional image. At least if using dracut. So lets move it from being hardcoded in chroot-script to the local packages files. Happy to send a PR. Seems to be a trivial change. Waiting with the PR until https://github.com/grml/grml-debootstrap/pull/236 is merged otherwise there would be a merge conflict.

Patrick · November 19, 2023, 6:16am

Patrick · November 22, 2023, 5:22am

github.com/grml/grml-debootstrap

my closed pull requests

opened 04:47AM - 22 Nov 23 UTC

adrelanos

Sorry about the closed pull requests noise. I was attempting to make github a…ctions work in my personal (soft) fork (only for the purpose of contributing and carrying delta until merged here upstream). Previously I had pressed the github fork button. But apparently such repositories cannot run github actions. To have a "real" fork I deleted the repository, manually created and pushed. That fixed the github actions in my personal repository but had the unwanted side effects of closing all my prior pull requests here upstream. I am trying to figure out how to re-open these.

Patrick · November 22, 2023, 5:40am

Patrick · November 24, 2023, 5:26am

--vmefi too small size of ESP partition / grub partition? / make size of ESP configurable (EFI) · Issue #221 · grml/grml-debootstrap · GitHub

Patrick · December 7, 2023, 7:10pm

more work on https://github.com/grml/grml-debootstrap/pull/255

Patrick · December 8, 2023, 8:39am

github.com/grml/grml-debootstrap

Comment by adrelanos to ci: diff back-to-back built images

grml:master ← zeha:b2b

This is probably considered blocked by: * https://github.com/grml/grml-deboot…strap/issues/252 But I think it should not be considered blocked because of that. I think this PR would be good to be merged rather sooner than later to avoid merge conflicts. It seems to be a nice feature towards reproducible builds. While the actual test is still broken on CI, it's still adding informative output to grml-debootstrap. I might even send a PR to improve that debug output. Also any scripts to diff two different VM images are nice for local use. As long as https://github.com/grml/grml-debootstrap/issues/252 is pending, simply keep the test disabled on CI so CI does not break until this gets fixed in the future?

Patrick · December 8, 2023, 11:19am

github.com/grml/grml-debootstrap

VM loop device not cleaned up in CI

opened 07:51PM - 19 Nov 23 UTC

zeha

``` * Removing loopback mount of file /code/qemu-1.img. previous state: loop…3p1 (253:0) /dev/loop1: [2065]:72205 (/var/lib/snapd/snaps/core20_2015.snap) /dev/loop2: [2065]:72206 (/var/lib/snapd/snaps/snapd_20290.snap) /dev/loop0: [2065]:72204 (/var/lib/snapd/snaps/lxd_24322.snap) /dev/loop3: [2065]:282883 (/code/qemu-1.img) after kpartx-d loop3p1 (253:0) /dev/loop1: [2065]:72205 (/var/lib/snapd/snaps/core20_2015.snap) /dev/loop2: [2065]:72206 (/var/lib/snapd/snaps/snapd_20290.snap) /dev/loop0: [2065]:72204 (/var/lib/snapd/snaps/lxd_24322.snap) /dev/loop3: [2065]:282883 (/code/qemu-1.img) loop_part is: loop3p1 loop3p1 (253:0) /dev/loop1: [2065]:72205 (/var/lib/snapd/snaps/core20_2015.snap) /dev/loop2: [2065]:72206 (/var/lib/snapd/snaps/snapd_20290.snap) /dev/loop0: [2065]:72204 (/var/lib/snapd/snaps/lxd_24322.snap) /dev/loop3: [2065]:282883 (/code/qemu-1.img) * Finished execution of grml-debootstrap. Enjoy your Debian system. ``` At least in GitHub Actions the cleanup of the loop device doesn't seem to work properly.

Patrick · December 12, 2023, 4:35pm

github.com/grml/grml-debootstrap

consistently use ESP label for the EFI system partition

grml:master ← adrelanos:patch-1

opened 04:34PM - 12 Dec 23 UTC

adrelanos

+1 -1

change from EFI to ESP for arm64 builds Use of ESP is more popular. * http…s://en.wikipedia.org/wiki/EFI_system_partition * https://wiki.archlinux.org/title/EFI_system_partition * https://www.diskpart.com/articles/efi-system-partition-4348.html If we'd use the long label it would be "EFI system partition" but since we use the short label it should be ESP. Why bother? Because then later `PARTLABEL` can be used in `/etc/fstab`. https://wiki.archlinux.org/title/fstab#GPT_partition_labels Any label with spaces is more error-prone. I haven't found any convention for partition labels but consistency makes sense.

Patrick · December 21, 2023, 2:24pm

Debian mkosi bug report:
outdated package description - mkosi is no longer legacy-free (and that’s okay)

Patrick · December 21, 2023, 2:37pm

Support iso9660 as output format · Issue #1220 · systemd/mkosi · GitHub

Patrick · December 21, 2023, 2:59pm

repart: Support booting via CD-ROM · Issue #28798 · systemd/systemd · GitHub

Patrick · December 22, 2023, 6:57pm

github.com/systemd/mkosi-initrd

update The initrd Interface of systemd blog post

opened 06:56PM - 22 Dec 23 UTC

adrelanos

https://systemd.io/INITRD_INTERFACE/ > Oh, and one last question before closi…ng: instead of implementing these features in your own distro’s initrd, may I suggest just using Dracut instead? It’s all already implemented there! I've obliged and learned the basics of dracut. Had I known mkosi-initrd, I might have skipped it. I guess since you have your own initrd generator now, I think that should be mentioned in your blog post. If it's editable in git, happy to send a PR, suggestion.

Patrick · December 22, 2023, 7:05pm

github.com/systemd/mkosi-initrd

update Introducing mkosi blog post

opened 07:05PM - 22 Dec 23 UTC

adrelanos

https://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html > When y…ou tell mkosi to generate a bootable image for you, it will make it bootable on EFI, not on legacy BIOS. This is outdated. mkosi is now capable for legacy BIOS booting. This is the reason why I didn't consider using mkosi earlier. Thank you for adding legacy BIOS booting support! Also seems like you stopped using the `legacy-free` branding in this repository, which is fine, but also best if the blog post removes these mentions. If it's editable in git, happy to send a PR, suggestion.

Patrick · December 22, 2023, 9:51pm

Patrick · December 23, 2023, 5:54pm

github.com/grml/grml-debootstrap

use apt-get with --error-on=any option

grml:master ← adrelanos:patch-2

opened 05:53PM - 23 Dec 23 UTC

adrelanos

+1 -1

for better error handling Otherwise if 1 repository fails (such as the securi…ty repository) apt would by default silently ignore this can continue the build. Therefore for consistent builds and towards reproducible builds, this option is required. I am using this in all my build scripts for years, though injected through DPKG_OPTIONS but I think the case is strong enough to hardcode this as default.

Patrick · December 23, 2023, 6:14pm

Patrick · December 28, 2023, 5:50am

github.com/systemd/mkosi

mkosi git signing key unusable

opened 05:49AM - 28 Dec 23 UTC

adrelanos

It's good that it's signed... ``` git tag -v v19 … object bbe715f42911f9660712377a5b39335b9391ae22 type commit tag v19 tagger Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> 1700043352 +0100 mkosi 19 gpg: Signature made Wed 15 Nov 2023 05:15:52 AM EST gpg: using RSA key 5C251B5FC54EB2F80F407AAAC54CA336CFEB557E gpg: Can't check signature: No public key zsh: exit 1 git tag -v v19 ``` but impossible to find the signing key. https://fedoraproject.org/wiki/User:Zbyszek links to https://keys.openpgp.org/search?q=C54CA336 but that link is broken. https://keys.openpgp.org/search?q=5C251B5FC54EB2F80F407AAAC54CA336CFEB557E works but when attempting to import the key I get: ``` gpg --import a gpg: key C54CA336CFEB557E: new key but contains no user ID - skipped gpg: Total number processed: 1 gpg: w/o user IDs: 1 ``` A wild theory is that `keys.openpgp.org` removes key ids if the e-mail address is not confirmed. https://api.github.com/users/keszybz/gpg_keys also isn't useful. > "raw_key": null, Maybe https://unix.stackexchange.com/questions/614670/import-pgp-keys-with-no-user-id-into-gpg would work as a solution but I suppose this isn't how it's imagined what should be done. @keszybz