3 ms·
I upgraded my main workstation to the recent Ubuntu with systemd, and sadly that has turned into a big problem. I use btrfs, and have several subvolumes as wel
by rogerbinns 11y ago
I upgraded my main workstation to the recent Ubuntu with systemd, and sadly that has turned into a big problem. I use btrfs, and have several subvolumes as well as multi-drive filesystems. At some point systemd decides to filesystem check something it doesn't need to, and then times out. Sadly this kind of thing is really difficult to diagnose. The exact same devices are already mounted - the second mount is just a different subvolume. If it just went ahead and mounted instead of outsmarting itself, then all would be good. Thankfully I can make it boot using upstart which works fine.
It is very frustrating that /etc/fstab has just worked for several years, but now systemd does the wrong thing. I really want to like and use systemd.
An Ubuntu bug report did not help (ignore the wrong title) https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447879 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/14478...
- vezzy-fnord 11y agoTo the best of my knowledge, the intention is to deprecate fstab(5) entirely in favor of automatic GPT partition discovery. Where this isn't possible, systemd-fstab-generator(8) will translate the contents of fstab(5) into native systemd units (mount, automount, swap...) and henceforth the semantics will be subject to the ordering and scheduling policies of systemd itself. Mount and swap units are in theory supposed to just be wrappers to the regular system tools that merely extend them to the Unit semantics, but as a whole I'm unsurprised that these assumptions may not play well with more complex storage configurations. That's always been a recurring systemd pain point.
- rogerbinns 11y agoMy frustration is that systemd isn't working in this case, that it is trying to do something pointless (check an already mounted filesystem), AND that I have no way to diagnose or correct it since there is no useful information to work with. When I had my drives on different controllers things were even worse because btrfs device scan didn't complete running before systemd then tried to mount an incomplete filesystem. Automatic partition discovery is going to have its own issues. For example plugging in a drive from another system/backups is not something you want mounted in the right places on the wrong system! fstab is also a nice place to put non-physical filesystems like tmpfs (I use it for /tmp /var/tmp $HOME/.cache $HOME/.ccache /space/work). Having to create separate .mount files for each of those would be a big pain. I really want to use and like systemd, but it does fundamentally need to work first.
- baghira 11y agoThere is no need to create mount units, all those thing will work from /etc/fstab, which overrides the generator. And I don't think the intent is to deprecated /etc/fstab. The list of possible automounts is limited: http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html http://www.freedesktop.org/software/systemd/man/systemd-gpt-... the point really being that of having a system that can boot without /etc. I've read quite a few complaints about Ubuntu 15.04+btrfs problems, for what is worth I had no problems with Fedora22 and Opensuse Tumbleweed.
- zxcvcxz 11y agoIf you prefer Btrfs why not just use OpenSUSE? It uses btrfs by default. Changing the default filesystem on your OS is, imo, setting your self up for trouble.
- rogerbinns 11y agoI have been using btrfs for several years and it has been fine, except for the few occasions it ran out of space. The problem here is a switch from upstart to systemd has somehow resulted in the latter not behaving as the former wrt to /etc/fstab.
- digi_owl 11y agoHilarious given that systemd devs are big proponents of btrfs. But then one wonder why the F systemd is involved with mounting at all. Or a whole lot of other things...