systemd.setenv and a mount.unit

systemd.setenv and a mount.unit

[Jakob Schürz]

Hi there!

Another challenge...
I'm using btrfs. So i make snapshots from my system. And in a script, I 
make a symlink (for example: @system.CURRENT and @system.LAST) for the 
current and the last snapshot.

So i want to add 2 entries in grub2 from which i can boot into the 
current and the last snapshot.

I tried to pass an environmental variable with 
systemd.setenv=BOOTSNAP=@system.CURRENT, and i have a mount-unit 
containing the option

Options=defaults,nofail,subvol=archive-local/@system.$BOOTSNAP

but it doesn't work. If i change $BOOTSNAP to CURRENT, the mount works.
So i made a test.service, containing only
StartExec=/bin/echo $BOOTSNAP
I get the value @system.CURRENT in the logs...

How can I do this mounts?

jakob
-- 
http://xundeenergie.at
http://verkehrsloesungen.wordpress.com/
http://cogitationum.wordpress.com/

Re: systemd.setenv and a mount.unit

[Goffredo Baroncelli]

On 2014-11-19 23:48, Jakob Schürz wrote:
> Hi there!
> 
> Another challenge... I'm using btrfs. So i make snapshots from my
> system. And in a script, I make a symlink (for example:
> @system.CURRENT and @system.LAST) for the current and the last
> snapshot.

Interesting, I was unaware that I could mount a subvolume passing
a "soft" link.

> 
> So i want to add 2 entries in grub2 from which i can boot into the
> current and the last snapshot.
> 
> I tried to pass an environmental variable with
> systemd.setenv=BOOTSNAP=@system.CURRENT, and i have a mount-unit
> containing the option
> 
> Options=defaults,nofail,subvol=archive-local/@system.$BOOTSNAP
> 
> but it doesn't work. If i change $BOOTSNAP to CURRENT, the mount
> works. So i made a test.service, containing only StartExec=/bin/echo
> $BOOTSNAP I get the value @system.CURRENT in the logs...

This is more a systemd related question. However it seems that ExecStart 
supports "...basic environment variable substitution..."; but the mount unit
doesn't. This explain your difficulties. Anyway I suggest you to contact the 
systemd developers to get further support; maybe that this could be a add as
TODO item.

> How can I do this mounts?

For the boot, I used the "rootflags=" command line options. This 
usually is interpreted by the initrd/initramfs as option to pass
to the mount command. In my case I have:

	rootflags=subvol=debian

so, the subvol=debian option is passed to mount. When grub-mkconfig
generates the grub menu entries, does so.


> jakob
BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: systemd.setenv and a mount.unit

[Jakob Schürz]

Am 2014-11-20 um 11:17 schrieb Goffredo Baroncelli:
> On 2014-11-19 23:48, Jakob Schürz wrote:
>> Hi there!
>>
>> Another challenge... I'm using btrfs. So i make snapshots from my
>> system. And in a script, I make a symlink (for example:
>> @system.CURRENT and @system.LAST) for the current and the last
>> snapshot.
>
> Interesting, I was unaware that I could mount a subvolume passing
> a "soft" link.

Fortunately Yes, that works. :)
So i came on this idea, to create 2 (or more) stable links on the 
current, last and so on snapshot. The Problem is the fstab...

>
>>
>> So i want to add 2 entries in grub2 from which i can boot into the
>> current and the last snapshot.
>>
>> I tried to pass an environmental variable with
>> systemd.setenv=BOOTSNAP=@system.CURRENT, and i have a mount-unit
>> containing the option
>>
>> Options=defaults,nofail,subvol=archive-local/@system.$BOOTSNAP
>>
>> but it doesn't work. If i change $BOOTSNAP to CURRENT, the mount
>> works. So i made a test.service, containing only StartExec=/bin/echo
>> $BOOTSNAP I get the value @system.CURRENT in the logs...
>
> This is more a systemd related question. However it seems that ExecStart
> supports "...basic environment variable substitution..."; but the mount unit
> doesn't. This explain your difficulties. Anyway I suggest you to contact the
> systemd developers to get further support; maybe that this could be a add as
> TODO item.

I hope so... and i found out, that this is not a btrfs-challenge.
On the grub-devel-list i saw a discussion to make dynamically entries 
for all snapshots in a certain directory according to this challenge.

But this also didn't solve the fstab-challenge.

So i think i have to place it on a systemd-devel-list...

>
>> How can I do this mounts?
>
> For the boot, I used the "rootflags=" command line options. This
> usually is interpreted by the initrd/initramfs as option to pass
> to the mount command. In my case I have:
>
> 	rootflags=subvol=debian
>
> so, the subvol=debian option is passed to mount. When grub-mkconfig
> generates the grub menu entries, does so.

This I also have in my grub-config, and it works. But it doesn't solve 
the challenge. Mounting more subvolumes according to the 
root-subvolume... :-)

regards
Jakob

Re: systemd.setenv and a mount.unit

[Goffredo Baroncelli]

On 2014-11-20 11:35, Jakob Schürz wrote:
> Am 2014-11-20 um 11:17 schrieb Goffredo Baroncelli:
[....]
>> 
>> rootflags=subvol=debian
>> 
>> so, the subvol=debian option is passed to mount. When
>> grub-mkconfig generates the grub menu entries, does so.
> 
> This I also have in my grub-config, and it works. But it doesn't
> solve the challenge. Mounting more subvolumes according to the
> root-subvolume... :-)
> 

Ah! You never told that this is your request.

I can only suggest that after snapshooting the "/",
you snapshot their subvolumes, placing these under
the root snapshoot itself:

Supposing to have the following four subvolumes

/root/
/root/etc
/root/usr
/root/var

When you need to snapshot, you should:

# btrfs subvolume snapshot /root /backup-root-20141120
# btrfs subvolume snapshot /root/etc /backup-root-20141120/etc
# btrfs subvolume snapshot /root/usr /backup-root-20141120/usr
# btrfs subvolume snapshot /root/var /backup-root-20141120/var

So in order to remount an "old" filesystem, you need to make only
1 mount.










> regards Jakob
> 
> -- To unsubscribe from this list: send the line "unsubscribe
> linux-btrfs" in the body of a message to majordomo@vger.kernel.org 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: systemd.setenv and a mount.unit

[Chris Murphy]

On Thu, Nov 20, 2014 at 4:14 AM, Goffredo Baroncelli <kreijack@inwind.it> wrote:

> Supposing to have the following four subvolumes
>
> /root/
> /root/etc
> /root/usr
> /root/var
>
> When you need to snapshot, you should:
>
> # btrfs subvolume snapshot /root /backup-root-20141120
> # btrfs subvolume snapshot /root/etc /backup-root-20141120/etc
> # btrfs subvolume snapshot /root/usr /backup-root-20141120/usr
> # btrfs subvolume snapshot /root/var /backup-root-20141120/var
>
> So in order to remount an "old" filesystem, you need to make only
> 1 mount.

I like this layout better than either the openSUSE or Fedora layouts.
It's easier to mount and old filesystem, where on Fedora each
subvolume must be explicitly mounted. And it ensures old binaries
aren't in the current mount path – kinda like running in a chroot –
where on openSUSE the snapshots containing old binaries are in the
current mount path.


-- 
Chris Murphy

Re: systemd.setenv and a mount.unit

[David Sterba]

On Thu, Nov 20, 2014 at 11:39:19AM -0700, Chris Murphy wrote:
> On Thu, Nov 20, 2014 at 4:14 AM, Goffredo Baroncelli <kreijack@inwind.it> wrote:
> 
> > Supposing to have the following four subvolumes
> >
> > /root/
> > /root/etc
> > /root/usr
> > /root/var
> >
> > When you need to snapshot, you should:
> >
> > # btrfs subvolume snapshot /root /backup-root-20141120
> > # btrfs subvolume snapshot /root/etc /backup-root-20141120/etc
> > # btrfs subvolume snapshot /root/usr /backup-root-20141120/usr
> > # btrfs subvolume snapshot /root/var /backup-root-20141120/var
> >
> > So in order to remount an "old" filesystem, you need to make only
> > 1 mount.
> 
> I like this layout better than either the openSUSE or Fedora layouts.
> It's easier to mount and old filesystem, where on Fedora each
> subvolume must be explicitly mounted. And it ensures old binaries
> aren't in the current mount path – kinda like running in a chroot –
> where on openSUSE the snapshots containing old binaries are in the
> current mount path.

While the old binaries are in the current mount path, they're not
generally accessible due to 0750 on the .snapshots directory.

The 'single mountpoint for whole root' is not perfect in case there are
files that are independent on the system files, like logs or some
application data in wellknown paths.

The other option is to have separate subvolumes for the selected paths
and either mount them in fstab or do more work when the old filesystem
has to be rolled back and transformed to the expected layout.

Both have their pros and cons so this is a matter of user choice. Eg. if
the logs are forwarded and not kept locally, no applications store data
on root partition. Going to an older snapshot is trivial and without
unexpected consequences.

And of course the layouts are both ways convertible.

Re: systemd.setenv and a mount.unit

[Brendan Hide]

On 2014/11/20 00:48, Jakob Schürz wrote:
> Hi there!
>
> Another challenge...
> I'm using btrfs. So i make snapshots from my system. And in a script, 
> I make a symlink (for example: @system.CURRENT and @system.LAST) for 
> the current and the last snapshot.
>
> So i want to add 2 entries in grub2 from which i can boot into the 
> current and the last snapshot.
>
> I tried to pass an environmental variable with 
> systemd.setenv=BOOTSNAP=@system.CURRENT, and i have a mount-unit 
> containing the option
>
> Options=defaults,nofail,subvol=archive-local/@system.$BOOTSNAP
Perhaps I'm reading it incorrectly. I interpret this as:
Options=defaults,nofail,subvol=archive-local/@system.@system.CURRENT

-- 
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97