TODO

[illiliti]

• [x] Cleanup/remove dirty code
  • [x] Rework trap_helper()
• [x] Proper docs, man pages (scdoc)
• [X] ~~Event-based initramfs~~ impossible without sacrificing portability
• [ ] TPM LUKS
• [ ] LUKS dm-verify/dm-integrity
• [ ] LUKS external key/header on block device/file system
• [ ] CPU microcode
• [x] Hooks
• [x] ~~Firmware~~ can be managed via hooks
• [x] Keymaps
• [x] ZFS
• [ ] TPM ZFS (https://github.com/openzfs/zfs/pull/9852)
• [ ] RAID (dmraid, mdraid)
• [ ] Suspend/hibernate
• [x] Kernel command line parameters
• [ ] Live USB integration
• [x] Mode without device manager using deprecated /proc/sys/kernel/hotplug (i'm still looking for better way to drop device managers)
• [ ] Fix remaining bugs (open an issue if you found something)

Suggestions are welcome

[travankor]

There are two standards of TPM out there --1.2 and 2.0. This might be something complex to support. And by suspend/hibernate, you mean a way to erase the encryption keys from RAM? You can also try to store this value in TPM (not sure about this).

There's also dm-verity/AEAD as something to support.

[illiliti]

There are two standards of TPM out there --1.2 and 2.0. This might be something complex to support.

2.0 will be supported

And by suspend/hibernate, you mean a way to erase the encryption keys from RAM? You can also try to store this value in TPM (not sure about this).

By suspend/hibernate i mean support suspending/hibernating for systems without systemd. If user stored their keys in TPM, it will be used to resume

There's also dm-verity/AEAD as something to support.

Agreed. Looks not too complex to implement

[eudaldgr]

What do you mean with 'Live USB integration'?

[illiliti]

I want to create something like that you already did - https://github.com/eudaldgr/kiss-live, but without dependency on KISS Linux environment

[apprehensions]

when can the version TODO be done? i would like to package tinyramfs for Void linux, and it requires something along the lines of tags, v0.1 for example.

alternatively, you can simply just open a new tag, nothing more.

[illiliti]

when can the version TODO be done?

When i have more free time to work on it. Or if someone donate some $$ to me.

i would like to package tinyramfs for Void linux, and it requires something along the lines of tags, v0.1 for example.

Done: https://github.com/illiliti/tinyramfs/releases/tag/0.1.0

[fungilife]

Kernel command line parameters

You have this checked, I wonder if we mean the same As I have two different init/srv,supv systems on my system I am trying through grub to start the alternative by adding in the kernel/linux line init=/usr/bin/runit-init which works fine with mkinitcpio (arch based distro)

No matter what I do it still boots on the default /usr/bin/init If I switch the link pointing to it runit starts fine.

I am also unsure at this point (I've boot 5.4 5.10 5.15 and 6.5) if the RESUME=swap-uuid modifier is accepted

What is the appropriate wording for using xz in the config Initially I had used xz with flags, it went to kernel panic, then just "xz" and still it said unknown options used with xz "gzip -9" works.

It is also throwing hdaudio couldn't be configured so disabled at the start of booting process, although sound (alsa) on oem Intel onboard audio, worked, setup was a little different.

Otherwise good

A proposed AUR with systemd not removed is available here, if someone wants to pick-it up https://git.disroot.org/joborun-pkg/jobcomm/src/branch/main/tinyramfs/PKGBUILD-4-AUR

[dkwo]

For microcode: at least intel, provided one knows the cpu info (e.g. via the function that dracut uses), isn't this as simple as iucode_tool --write-earlyfw=intel-ucode.img /usr/lib/firmware/intel-ucode/06-4e-03 and then cat intel-ucode.img old.initram > new.initram ?

[illiliti]

@fungilife

No matter what I do it still boots on the default /usr/bin/init

init=<path> is not honored by tinyramfs at the moment. Will fix that, thanks for reporting.

I am also unsure at this point (I've boot 5.4 5.10 5.15 and 6.5) if the RESUME=swap-uuid modifier is accepted

resume/suspend support is not implemented, so not accepted

Initially I had used xz with flags, it went to kernel panic, then just "xz" and still it said unknown options used with xz

Some extreme levels(like -9) of xz are not supported by the kernel, which is why you get kernel panic. I agree that this should be documented at least.

It is also throwing hdaudio couldn't be configured so disabled at the start of booting process, although sound (alsa) on oem Intel onboard audio, worked, setup was a little different.

Maybe some module didn't make it into the initramfs image for some reason. Could be a tinyramfs bug or misconfiguration on your side. Either way more info like exact error message is needed to tell more.

@dkwo

isn't this as simple as iucode_tool --write-earlyfw=intel-ucode.img /usr/lib/firmware/intel-ucode/06-4e-03 and then cat intel-ucode.img old.initram > new.initram ?

Yes, it is simple as that. I just wanted to automate that, so you don't have to do it yourself.

[dkwo]

btw, I also get kern.err: hdaudio hdaudioC0D2: Unable to configure, disabling, so maybe it has to do with missing modules

[fungilife]

Initially I had used xz with flags, it went to kernel panic, then just "xz" and still it said unknown options used with xz

Some extreme levels(like -9) of xz are not supported by the kernel, which is why you get kernel panic. I agree that this should be documented at least.

I've never used -9 it is either 6 or 7 and still didn't work, substituting to gz it works fine, so not a working problem, but I think it needs some investigating and testing/updating documentation.

XZ itself has changed in recent issues upstream due to multithreading options -T(0...) and to assure correct cksums even the default single thread compression has changed, maybe this has thrown something off?

Will resume/suspend flags be able to be used in upcoming versions and is there an alternative of passing this to the kernel other than the boot flags?

[firasuke]

For "Live USB integration" I believe the approach mentioned in #17 is good and distro-agnostic enough to be included in tinyramfs.

[dkwo]

besides the microcode feature, would it make sense to provide (hooks for) unified kernel image as well as unlock luks with yubikey?

[dkwo]

May I add an fsck hook to the wish list?