Announcement

Collapse
No announcement yet.

Systemd Gets An Fsck Daemon/Service

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

  • #11
    Originally posted by waxhead View Post
    I was actually one of those who believed that systemd was a good thing. These days I see a change that I am not so sure I like. systemd is basically becomming a "standard base system".
    I am not sure if this is a good or bad thing, I am only hoping that it will be modular enough that people can replace parts of systemd with their own stuff without easily breaking compatibility.
    Most new systemd features and development have been OS container related or because it is needed in constrained environment like initrd. The ntp client and networking stuff _can_ be used on desktop, but they have rather limited features; it is very useful stuff for some, but not for all, so even Fedora doesn't use systemd's networking or ntp client.

    systemd really is very modular; the whole intention is that people/distros can turn features on or off so that systemd can scale from tiny embedded devices to supercomputers and massive scale clusters.

    Also look at the systemd interface stability chart under the "Reimplementable Independently" column;


    You will see that many systemd tools are made so they can be independently implemented by others.

    Will some of the systemd tools obsolete other tools? Most likely, but I wouldn't worry; tools gets replaced all the time with better solutions, so some systemd tools are also likely to be out-competed by externally made tools.

    Comment


    • #12
      Please, systemd, take over laptop-mode-tools, pm-utils, acpid, tlp, tuned, and all that clusterfuck of hacks over hacks resembling something made to save power in a mobile system, or in, well, any computer with some idle time. That should be next on the list.

      Comment


      • #13
        Ok, if they want to add it - fine by me.
        But as of current git state there is no way to disable -fsckd at configure time.

        They are free to add any additional bloat they want to, but for the f*cks sake - make a way to disable all the crap at configure time because not everything is needed on every system.
        You may ask: Why this pissed you off?
        Simple: I have my own little fully cross-compiled linux based OS for my little raspberry pi and yes, it's s-d based, it's on NFS root, so I obviously don't need any fsckd on it.
        And I want a way to simply disable it at configure time (have I said "configure time" enough times?) just as I can disable -machined, -importd, -rest-od-the-bloat-d.

        I know I can simply rm the binaries and the units but it's not kocher .

        Comment


        • #14
          The idea of a "standard base system" being bundled under one banner isn't even new to Linux. It's just that GNU isn't pulling their weight any more.

          Comment


          • #15
            I was actually one of those who believed that systemd was a good thing. These days I see a change that I am not so sure I like. systemd is basically becomming a "standard base system".
            I am not sure if this is a good or bad thing, I am only hoping that it will be modular enough that people can replace parts of systemd with their own stuff without easily breaking compatibility.
            There is nothing worse than Linux now. I work with Linux for 10 years. I still did not understand INIT talisman.

            Linux is in desperate need of a standard base system, its the glaring fragmentation (that also has upsides) that makes it quite difficult to develop for Linux, remember that if you are making a distro you don't have to use system d you use it so that you GET a base system and developers will be free to know that if they use this base system porting to other distros that subscribe to it are much simpler, the future in the systemd cosmos as i see it is that it will be the base for contained applications, and operating systems, you will be able to update your system separately from you apps, you will be able to run apps on any distro that has systemdNEXT on it (the dbus changes that are happening for and because of systemd will make this possible)

            Is there a source of information ??
            Every time I find there is an important package Deleted from the system. Because i install a program and delete it.
            It's good separation of system packages and software packages..Some respect LSB

            Comment


            • #16
              Originally posted by Skrapion View Post
              The idea of a "standard base system" being bundled under one banner isn't even new to Linux. It's just that GNU isn't pulling their weight any more.
              But... Clearly it's a conspiracy to replace GNU!

              Comment


              • #17
                This requires disabling fsck inside Dracut, which is not the default

                When Ubuntu first offered this feature in systemd 218-10ubuntu1, I got a nasty surprise: boot hangs when systemd tried to call fsck a second time. Got filechecking as a hung start job on every filesystem. Apparently they were being checked in the initramfs, then checked again and somewhere in this process a hang was created.

                I updated Dracut from 037 to 040 (ported from Debian to Ubuntu) and in the process found the solution: disabling fsck in /etc/dracut.conf . Apparently this was expected to come up for some users, so all you have to do is uncomment the nofscks="yes" line in the default file. No more boot hangs, and now there is the option to cancel fsck runs. Next I have to figure out how to use the human-readable fsck feedback from the console in a scripted plymouth theme and I will have back all the fsck feedback and function plymouth with upstart used to give.

                I made not including fsck tools in dracut the default in my package, so that fsck only occurs after the root fs is mounted ro and the initramfs is closed out. I would advise all others mantaining Dracut packages for distros using current systemd to do the same. Other than that, this is an excellent addition to systemd, as it used to be plymouth was blind to filesystem checks and the console could not stop a check in systemd. Thanks Canonical-and thanks again for contributing this back to upstream for systemd 219!

                Comment


                • #18
                  Originally posted by Luke_Wolf View Post
                  But... Clearly it's a conspiracy to replace GNU!
                  I'd just like to interject for a moment. What you?re referring to as Linux, is in fact, systemd/Linux, or as I?ve recently taken to calling it, systemd plus Linux.

                  Comment


                  • #19
                    Originally posted by Skrapion View Post
                    The idea of a "standard base system" being bundled under one banner isn't even new to Linux. It's just that GNU isn't pulling their weight any more.
                    Your complaint seems a bit off-target, given that GNU are the ones putting together dmd and Guix to offer a legit alternative standard base system. From what I've been reading, dmd and Guix are being developed quite rapidly.

                    Comment


                    • #20
                      Originally posted by GuercH View Post
                      Linux is in desperate need of a standard base system, its the glaring fragmentation (that also has upsides) that makes it quite difficult to develop for Linux, remember that if you are making a distro you don't have to use system d you use it so that you GET a base system and developers will be free to know that if they use this base system porting to other distros that subscribe to it are much simpler, the future in the systemd cosmos as i see it is that it will be the base for contained applications, and operating systems, you will be able to update your system separately from you apps, you will be able to run apps on any distro that has systemdNEXT on it (the dbus changes that are happening for and because of systemd will make this possible)
                      I second this, Linux desperately needs more standardization. Personally, I am desperately waiting for when developers, and not distro maintainers, manage the packaging for their applications. Just the other day I was informed that OpenSUSE ships a misconfigured version of my application that strips out an important feature, and this has been going on for years. Each distro make its own assumptions and it's a constant nightmare. I have another distro that wanted to rename my library and break apps that depend on it. We need something like systemd for the software management world.

                      Comment

                      Working...
                      X