Re: systemd.setenv and a mount.unit
On Thu, Nov 20, 2014 at 11:39:19AM -0700, Chris Murphy wrote: On Thu, Nov 20, 2014 at 4:14 AM, Goffredo Baroncelli kreij...@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. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
systemd.setenv and a mount.unit
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/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: systemd.setenv and a mount.unit
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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: systemd.setenv and a mount.unit
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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: systemd.setenv and a mount.unit
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 majord...@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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: systemd.setenv and a mount.unit
On Thu, Nov 20, 2014 at 4:14 AM, Goffredo Baroncelli kreij...@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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
