Im running Debian 8 (jessie/testing) amd64 with systemd.

On my system partition containing a btrfs filesystem, I do have the following layout:


In order to fully boot from a snapshot, I currenty have to change the subvolume:

  • in /etc/fstab
  • in the grub console (edit mode)

when booting.


The change to '/etc/fstab' requires a running system - i.e. from a flashdrive - what I want to avoid


Assume something is really broken, and I had to boot from a snapshot#1:
I'd rather only change the subvolume in the grub console, and have the rootfs mounted on the correct subvolume (here: snapshot#1).

Without a change in /etc/fstab, systemd would still mount the rootfs from the entry specified in /etc/fstab -> yielding the wrong rootfs to be mounted


  • Can systemd be told to mount the rootfs from the 'rootflags=subvol=' parameter of '/proc/cmdline'
  • Or is there another solution to circumvent this problem

I think it might be helpful. There is a list of kernel command line params which systemd understands: http://www.freedesktop.org/software/systemd/man/kernel-command-line.html
There is an option fstab=, and rd.fstab

Takes a boolean argument. Defaults to "yes". If "no", causes the generator to ignore any mounts or swaps configured in /etc/fstab. rd.fstab= is honored only by initial RAM disk (initrd) while fstab= is honored by both the main system and the initrd.

So if set in grub/grub2 (I don't know what you are using) root=/dev/required_dev fstab=no it should boot as expected.

| improve this answer | |
  • good proposal, though I run into a kernel panic - my initrd(?) does not seem to know what to mount as rootfs (unable to mount unknown device block(0,0)). At least I'm sure it's ignoring my fstab === Any further hints? – Florian Mar 13 '15 at 8:46
  • So you are appending to kernel line root=/dev/reuired_dev ...fstab = no and it is failing. Several reasons can result in such a failure, you can see this link. And I will need more info about you device schema – taliezin Mar 13 '15 at 9:03
  • As you were! I just updated my system (with a foreshadowing in mind) - seems this was a bug, because now everything works as expected!! Tnx very much. === btw: would you also favor adding fstab=no as a standard option, and working with unit.mounts? – Florian Mar 13 '15 at 9:35
  • I could not get the question. Could you clarify? – taliezin Mar 13 '15 at 9:41
  • In order to ease switching to a snapshot: I would prefer not to use /etc/fstab at all, but only the root= cmdline parameter. As other mounts (like /home, i.e.) become unavailable without an fstab, I'd convert them to systemd unit files (i.e. home.mount) === My question is, would you rather disregard this approach, and if: why? – Florian Mar 13 '15 at 9:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.