Announcement

Collapse
No announcement yet.

systemd's mkosi-initrd Talked Up As Better Alternative To Current Initrd Handling

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    This development sounds great for servers with higher security requirements and seems like a logical continuation of the trend around layered, immutable system images.

    Even in case of root access, embedding malware into the initrd will become impossible. Start a small hypervisor or xen dom0 this way and it'll greatly increase the chance that you can get rid of an infection just by rebooting the machine (provided that it isn't embedded into a guest VM and can just break out of the VM jail again).

    Since not every distribution is going to adopt this new behaviour and regular general purpose distros tend to not use immutable system images, one can just switch over to dracut/mkinitcpio/initramfs-tools/mkinitramfs/genkernel/... if he doesn't like this new initrd concept or even avoid it entirely.

    IMO having more options on how to do things is nearly always positive if it's just an opt-in/opt-out kind of thing.

    Comment


    • #22
      So for this to work, it seems you need to use systemd, TPM and any bugs get passed off to package maintainers?? Hmm smacks of being 100% useful for business users yet fucks up everyone else. No surprise i's RedHat crap
      .

      Comment


      • #23
        Originally posted by ext73 View Post
        that's a very bad idea :/
        How insightful.

        Comment


        • #24
          Originally posted by hamishmb View Post
          So, even though I personally use systemd, I'm happy that projects like Devuan exist, for example.
          Recently Devuan project got their repository key expired. Says quite a lot about systemd haters' competency.

          Comment


          • #25
            Originally posted by cjcox View Post

            I don't think it's "hate" to have a different preference or listening to systemd's own team as they say, "you always have a choice to use systemd or not".

            Now, whether or not "choice" and "freedom" is a goal of systemd? It's certainly a project that wants to "tell you" what is "right and good". Can anyone disagree with that?
            What doesn't make much sense in your speech is that no one is saying what is good or what is bad, there is simply a project that today is used by most distributions for init, many other projects like this are born to integrate in systemd. What's wrong with that?
            The distributions are then free to use mkosi or continue to use the one they use now. What's the problem ?
            Or do you want to dictate to developers what they need to work on?​

            Comment


            • #26
              Originally posted by dekkzz78 View Post
              So for this to work, it seems you need to use systemd, TPM and any bugs get passed off to package maintainers?? Hmm smacks of being 100% useful for business users yet fucks up everyone else. No surprise i's RedHat crap
              .
              For "this to work" you don't need TPM. You'll need TPM only for secure boot/measured boot — and only if you decide to use it at all​.

              Of course you'll need systemd. It's all based on functionality provided by systemd. But I must stress that any distro wishing to do so, can provide its own pre-built, signed ramdisk-images, with the usual tools, without touching any of this.

              This is just a transparent, convenient, baked with systemd sauce, tool to do it "the right way"™.
              Last edited by _ReD_; 14 September 2022, 04:15 PM.

              Comment


              • #27
                Originally posted by juxuanu View Post
                It's nice, but sometimes you need to modify your initrd. Add modules, etc.
                Yeah, i still hate that you need a new monolithic initrd for every kernel. Nowadays the common bootloaders can load multiple initrd archives fine.

                On the the VMs I just use the debian "cloud" kernel, built-in nvme und ext4 für the basic root partition, no dynamic modules needed.

                Ultimately I think kernels should come if their own built-in initrd, carrying modules for 99% of storage modules so you can mount your basic rootfs without another kernelspecific initrd. In fact, don't ever touch the inirtd, should be just an extension of the kernel to mount stuff and run the rest of the current initramfs functionality on your (potential reduced functionality) rootfs.

                Comment


                • #28
                  "systemd's mkosi-initrd talked up"

                  It was just a month ago that that SystemD Antichrist moved to Micro$oft !
                  Here we go again ...

                  Comment


                  • #29
                    Originally posted by sinepgib View Post

                    systemd (the project) is a big umbrella, so it isn't unlikely that mkosi-initrd is compatible with inits other than systemd (the init). It is a valid question.



                    It's not always about hate. Some people would rather not have glibc and use musl instead, some people like pid 1 to be more restricted to achieve extra robustness, some need to cover specially constrained environments for which systemd is either not ideal or not even appropriate, etc. Of course there are haters and they're quite vocal and toxic, but there's also a wider umbrella of people who would rather not use systemd (or not use it in all of their systems).
                    I personally am fully on board with systemd, but I like some of the things s6 propose and would like to give it a try (although it's not ready for prime time due to lack of a sensible frontend).
                    I use systemd fully but it's really done a bad job at getting any kind of adoption in the embedded space.

                    That said, the embedded space tend to use their own dumb methods of booting so I don't think this would apply there anyway.

                    Comment


                    • #30
                      Originally posted by juxuanu View Post
                      It's nice, but sometimes you need to modify your initrd. Add modules, etc.
                      This would still be doable, either by still building your own image as before or using extensions.

                      initramfs not being encrypted/signed at the moment is one of the big barriers to hibernation with secure boot on

                      Comment

                      Working...
                      X