Re: [arch-general] Systemd with encrypted Btrfs
On Tue, Jul 24, 2012 at 10:58 AM, Aurko Roy roy.au...@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
Re: [arch-general] Systemd with encrypted Btrfs
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 t...@jklm.no wrote: On Tue, Jul 24, 2012 at 10:58 AM, Aurko Roy roy.au...@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/urandomswap 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
Re: [arch-general] Systemd with encrypted Btrfs
On Tue, Jul 24, 2012 at 12:10 PM, Aurko Roy roy.au...@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
Re: [arch-general] Systemd with encrypted Btrfs
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 t...@jklm.no wrote: On Tue, Jul 24, 2012 at 12:10 PM, Aurko Roy roy.au...@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
Re: [arch-general] Systemd with encrypted Btrfs
Hi, On 24 July 2012 11:25, Aurko Roy roy.au...@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.
Re: [arch-general] Systemd with encrypted Btrfs
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 dam...@gmail.com wrote: Hi, On 24 July 2012 11:25, Aurko Roy roy.au...@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.
Re: [arch-general] Systemd with encrypted Btrfs
On Tue, Jul 24, 2012 at 12:40 PM, Aurko Roy roy.au...@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
Re: [arch-general] Systemd with encrypted Btrfs
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 t...@jklm.no wrote:
On Tue, Jul 24, 2012 at 12:40 PM, Aurko Roy roy.au...@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
