[arch-general] Systemd with encrypted Btrfs
Hello all, After all the intense discussions about systemd I decided to try it out and see for myself. I tried it out on my desktop and was quite impressed by it - it was much faster than the earlier initscript. Further when I would background a daemon (say the network daemon) in rc.conf, I would have to wait for a while even after I logged in for the network to start, whereas in systemd I find the necessary daemons have already started by the time I login. However I ran into a couple of problems running it on my laptop: 1. I have an encrypted swap that randomly generates a new passphrase everytime I reboot, but systemd asks me for a passphrase every time I boot. On pressing enter or entering any random characters it proceeds normally. This is more of an annoyance than a real problem. 2. I have an encrypted btrfs partition which it unlocks normally, but while trying to mount says: "fsck: fsck.btrfs: not found fsck: Error 2 while executing fsck.btrfs for /dev/mapper/myvolume" and this stops the whole boot process. I have to disable that partition on fstab to get systemd to boot properly. Once the boot process is complete, I can see that the decryption has proceeded normally (from systemctl -a) and can remount it normally in a manual fashion. I initially thought that creating fsck.btrfs as a symlink to btrfsck might do the job, but that doesn't work either. Does anybody have any experience successfully mounting (encrypted or not) btrfs partitions using systemd? Thanks, Aurko
On Tue, Jul 24, 2012 at 10:58 AM, Aurko Roy <roy.aurko@gmail.com> wrote:
1. I have an encrypted swap that randomly generates a new passphrase everytime I reboot, but systemd asks me for a passphrase every time I boot. On pressing enter or entering any random characters it proceeds normally. This is more of an annoyance than a real problem.
Note that systemd does not support Arch's traditional crypttab syntax, so you might need to adjust your crypttab file. The format is described in "man crypttab". I have a similar setup to what you describe and my crypttab line is: # cat /etc/crypttab swap /dev/sda2 /dev/urandom swap
2. I have an encrypted btrfs partition which it unlocks normally, but while trying to mount says: "fsck: fsck.btrfs: not found fsck: Error 2 while executing fsck.btrfs for /dev/mapper/myvolume" and this stops the whole boot process. I have to disable that partition on fstab to get systemd to boot properly. Once the boot process is complete, I can see that the decryption has proceeded normally (from systemctl -a) and can remount it normally in a manual fashion. I initially thought that creating fsck.btrfs as a symlink to btrfsck might do the job, but that doesn't work either.
There is no fsck.btrfs binary yet, and btrfsck does not support the expected interface. Until a proper fsck.btrfs exists you should mark your partition as not wanting to be fsck'ed in fstab (i.e. set passno, the last argument, to 0).
Does anybody have any experience successfully mounting (encrypted or not) btrfs partitions using systemd?
I would have thought you'd get a similar failure also with initscripts? Though in that case boot would not pause. -t
Hi, Thanks for the quick reply. I wasn't aware of the changes in crypttab syntax with systemd; but changing it the way you described it did the trick for swap. You're right, on digging deeper (logs) I found that the fsck had failed earlier as well but I never noticed it as the boot process wasn't interrupted. I didn't face it again after setting passno. to 0. I had heard about btrfs being released without a proper fsck in place but I thought that was long ago and that btrfsck was ready for general use. Rodrigo: I already solved it, but thanks for your reply anyway. -aurko On Tue, Jul 24, 2012 at 3:09 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Jul 24, 2012 at 10:58 AM, Aurko Roy <roy.aurko@gmail.com> wrote:
1. I have an encrypted swap that randomly generates a new passphrase everytime I reboot, but systemd asks me for a passphrase every time I boot. On pressing enter or entering any random characters it proceeds normally. This is more of an annoyance than a real problem.
Note that systemd does not support Arch's traditional crypttab syntax, so you might need to adjust your crypttab file. The format is described in "man crypttab". I have a similar setup to what you describe and my crypttab line is:
# cat /etc/crypttab swap /dev/sda2 /dev/urandom swap
2. I have an encrypted btrfs partition which it unlocks normally, but while trying to mount says: "fsck: fsck.btrfs: not found fsck: Error 2 while executing fsck.btrfs for /dev/mapper/myvolume" and this stops the whole boot process. I have to disable that partition on fstab to get systemd to boot properly. Once the boot process is complete, I can see that the decryption has proceeded normally (from systemctl -a) and can remount it normally in a manual fashion. I initially thought that creating fsck.btrfs as a symlink to btrfsck might do the job, but that doesn't work either.
There is no fsck.btrfs binary yet, and btrfsck does not support the expected interface. Until a proper fsck.btrfs exists you should mark your partition as not wanting to be fsck'ed in fstab (i.e. set passno, the last argument, to 0).
Does anybody have any experience successfully mounting (encrypted or not) btrfs partitions using systemd?
I would have thought you'd get a similar failure also with initscripts? Though in that case boot would not pause.
-t
On Tue, Jul 24, 2012 at 12:10 PM, Aurko Roy <roy.aurko@gmail.com> wrote:
You're right, on digging deeper (logs) I found that the fsck had failed earlier as well but I never noticed it as the boot process wasn't interrupted. I didn't face it again after setting passno. to 0. I had heard about btrfs being released without a proper fsck in place but I thought that was long ago and that btrfsck was ready for general use.
I have been using btrfs as my rootfs on all my machines for a couple of years and never seen a corruption that required fsck, so I don't know how well (or not) btrfsck actually works. I would assume it would not be too bad, as it is shipped by at least Oracle. The problem though is that it does not implement the correct API for integration with regular fsck, so it can only be called manually and not automatically on boot. -t
Hi, Thanks for the clarification. Also I was wondering if there was any reason why Arch doesn't have the rc-local.service in systemd by default. There was some stuff I ran in rc.local (reducing brightness, proxy authentication) but it seems there is no rc-local service in systemd. I am working on copying content from fedoras rc-local.service and trying to get it to work on my laptop. -aurko On Tue, Jul 24, 2012 at 3:46 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Jul 24, 2012 at 12:10 PM, Aurko Roy <roy.aurko@gmail.com> wrote:
You're right, on digging deeper (logs) I found that the fsck had failed earlier as well but I never noticed it as the boot process wasn't interrupted. I didn't face it again after setting passno. to 0. I had heard about btrfs being released without a proper fsck in place but I thought that was long ago and that btrfsck was ready for general use.
I have been using btrfs as my rootfs on all my machines for a couple of years and never seen a corruption that required fsck, so I don't know how well (or not) btrfsck actually works. I would assume it would not be too bad, as it is shipped by at least Oracle. The problem though is that it does not implement the correct API for integration with regular fsck, so it can only be called manually and not automatically on boot.
-t
Hi, On 24 July 2012 11:25, Aurko Roy <roy.aurko@gmail.com> wrote:
Thanks for the clarification. Also I was wondering if there was any reason why Arch doesn't have the rc-local.service in systemd by default.
Have a look at the initscripts-systemd package, it contains rc-local and rc-local-shutdown service files.
Hi, Yeah it works fine with the initscripts-systemd package but I had replaced that with the systemd-sysvcompat package for a pure systemd setupd. I was wondering if there is a reason why they've discontinued support for rc.local in that. AFAIK Fedora has a pure systemd setup (I may be wrong there) but still support rc.local. Perhaps I'm missing/misunderstanding something. Thanks, aurko On Tue, Jul 24, 2012 at 3:57 PM, Damien Churchill <damoxc@gmail.com> wrote:
Hi,
On 24 July 2012 11:25, Aurko Roy <roy.aurko@gmail.com> wrote:
Thanks for the clarification. Also I was wondering if there was any reason why Arch doesn't have the rc-local.service in systemd by default.
Have a look at the initscripts-systemd package, it contains rc-local and rc-local-shutdown service files.
On Tue, Jul 24, 2012 at 12:40 PM, Aurko Roy <roy.aurko@gmail.com> wrote:
Yeah it works fine with the initscripts-systemd package but I had replaced that with the systemd-sysvcompat package for a pure systemd setupd. I was wondering if there is a reason why they've discontinued support for rc.local in that. AFAIK Fedora has a pure systemd setup (I may be wrong there) but still support rc.local. Perhaps I'm missing/misunderstanding something.
Fedora still have quite a bit of legacy stuff (probably even more than what we do). I'd argue that rc.local{,.shutdown} is legacy, and that people would be better off by either writing .service files, or fixing whatever bugs are being worked around (which is mostly the use-case) properly. Even if you use systemd-sysvcompat support, you are of course free to copy the rc-local serivce files from the initscripts-systemd pacakge and put them in /etc/systemd/system/ -t
Hi, Thanks for your answer. In the end I decided to stick with systemd-sysvcompat with my own rc-local.service (since I didn't need the other stuff in the initscripts-systemd package). I must say I'm starting to like systemd despite the minor hiccups due to changes in conventions. -aurko On Tue, Jul 24, 2012 at 4:17 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Jul 24, 2012 at 12:40 PM, Aurko Roy <roy.aurko@gmail.com> wrote:
Yeah it works fine with the initscripts-systemd package but I had replaced that with the systemd-sysvcompat package for a pure systemd setupd. I was wondering if there is a reason why they've discontinued support for rc.local in that. AFAIK Fedora has a pure systemd setup (I may be wrong there) but still support rc.local. Perhaps I'm missing/misunderstanding something.
Fedora still have quite a bit of legacy stuff (probably even more than what we do). I'd argue that rc.local{,.shutdown} is legacy, and that people would be better off by either writing .service files, or fixing whatever bugs are being worked around (which is mostly the use-case) properly.
Even if you use systemd-sysvcompat support, you are of course free to copy the rc-local serivce files from the initscripts-systemd pacakge and put them in /etc/systemd/system/
-t
On Tue, Jul 24, 2012 at 10:58 AM, Aurko Roy <roy.aurko@gmail.com> wrote:
2. I have an encrypted btrfs partition which it unlocks normally, but while trying to mount says: "fsck: fsck.btrfs: not found
The problem seems to be that simply there is no such fsck.btrfs. It simply does not exist, yet. There is a btrfsck, but it is not yet ready for general use, IIRC. My solution for this is simply: # ln -s /bin/true /sbin/fsck.btrfs HTH -- Rodrigo
participants (4)
-
Aurko Roy
-
Damien Churchill
-
Rodrigo Rivas
-
Tom Gundersen