Actually not yet too successful booting my #BuildRoot image with systemd-boot. With grub-efi I got to the login.

EDIT: I think I got it and it is pretty obvious. I’m still deploying GRUB style configs when I construct the disk image with genimage, so I just fix them up as systemd boot style configs (found a reference for that).

So I just follow along [1] and cross my fingers ;-) I think it is good exercise to build from scratch a systemd image from boot to user space in all cases.

[1] https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/

The summary of #systemd #spam of today:

1. I got it fully working for my #BuildRoot image build.
2. It boots with no errors.
3. Compilation time is still not much different than with #Busybox.
4. Uses now systemd-boot instead of GRUB (thanks @vathpela for comments).
5. Uses systemd version 254. Plan is to get into phase.
6. For BuildRoot, uses the master branch of: https://gitlab.com/jarkkojs/linux-tpmdd-test

I “systemd” re-initiated the history of my test repository: https://gitlab.com/jarkkojs/linux-tpmdd-test. From now on I commit on keeping a proper versions on this :-) It had no forks so far so I’m the only person who had consequences on that action.

@vathpela One pleasant surprise is that changing to systemd from busybox with stripped down configuration does not cause any significant increase to compilation time of the image. So I can stick to this configuration from now and improve it :-)

Also it is a huge benefit that I now generate a single img file that QEMU can host or I can burn it to USB stick and run tests on real hardware. So I guess I'm a happy systemd user then...

@vathpela Anyway, I think I switch to systemd-boot in my kernel testing environment based on "less dependencies" :-) I.e. measurable benefit for the use case.

@vathpela So, I'm now generating 2GB UEFI bootable image from BuildRoot recipes based on GRUB2. Previously based on busybox. So this is the context to be more specific. I don't care how my distribution works as long as I don't have to touch it :-)

I have no idea what "systemd-stub" even is (first time I'm hearing the word), but I guess in my use using systemd-boot could decrease the turn-over time in compilation by decreasing dependencies. I compile full operating system image from scratch when I do kernel development, not just kernel image, so decreasing that is already a benefit.

LOL, apparently this feature was merged already in 2015. Heard first time this year...

What is the advantage of systemd-boot over GRUB2? #systemd #grub #grub2

Right now I'm on systemd 254 but should not be hard to get in phase with latest release from this point forward.

Fully works!! Screenshot taken from my MacBook Pro ;-) QEMU running on my PC workstation:

Functionally of that tool looks great tho. I just wrote down quick analysis of TPM2 part here for me as a reminder ;-) It also does FIDO2 which is great.

My #systemd feature awareness is always about two years old because you don’t become aware of its features by doing #kernel development :-)

For instance, I had no idea that systemd already natively supported #TPM2 before month or two ago someone told me about systemd-cryptenroll. I had seen the utility tho in some article but had a blind spot for the prefix.

Now that I’ve seen systemd’s TPM2 implementation in source level I can only say that it is somewhat bloated but I guess it is working fine :-) It is bloated because it would have been better idea just directly use the device. So not a great implementation, but at least a working one. That said, it is not a major glitch but IMHO could be rewritten at some point, with the motivation of decreasing dependencies and compilation times.

In order to address the 1-2 year turn-over issue, I’ll try to get my #BuildRoot build to generate a fully working #systemd environment.

#linux

I think what goes wrong is my static /etc/fstab from “Busybox ERA”.

I was able to create #systemd image with #BuildRoot.

However, it boots into emergency mode. Any tips or ideas?

My end product is 2GB img file that can be booted either with real hardware or in QEMU (it has #UEFI layout).

@ljs @vbabka Well, I like it and it works without issues for most of the time.

In Fedora installation I did not have sockets correctly configured so I wrote a script, and also in Fedora I had to first time create scdaemon.conf.

So I expect this to work better than before :-)

Maybe I should make this a contribution to PGP maintainers guide with more verbose explanations?

Especially the part which sockets need to be on would be good to be there because it is not easy to know beforehand the correct configuration e.g. if you've never used gpg-agent.

@vbabka For reference:

default-cache-ttl 3600
default-cache-ttl-ssh 3600
max-cache-ttl 7200
max-cache-ttl-ssh 7200
enable-ssh-support

@vbabka So you can check from here: https://gitlab.com/jarkkojs/skeleton/-/tree/main/.gnupg?ref_type=heads

And also here: https://gitlab.com/jarkkojs/skeleton/-/blob/main/.local/bin/linux-reset-gpg-agent?ref_type=heads

Maybe noteworthy in the script is that there are two sockets that need to be enabled:

- ssh-agent.socket
- ssh-agent-ssh.socket

I've sometimes forgot to enable latter.

Shortest cheat sheet possible for xxd:

xxd -r -p | xxd -p -c 0

@vbabka I've tested these myself in OpenSUSE and Fedora. I'd try both #1 and #3 from previous. In Fedora after boot it was not otherwise working right off the bat.

... and I'm thinking of doing of my own command-line wallet.

My lessons learned from #ethprague was these are the key algorithms:

1. P256-K1 also known as the #bitcoin curve.
2. Keccak-256, as it was before it became SHA-3. AFAIK, they have just some padding incompatibility. This is the hash used in #ethereum.

I don’t see really any problem make them a bit more “stack compatible”. So maybe something to look at after I get my TPM2 public key patch set into the mainline.

So like when running bunch of servers, how to seal your keys properly, pretty basic stuff.