Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 24.09.2014 22:08, Tobias Hunger wrote: From f3a193de94959875cd1d83f941ed8fc8275c82eb Mon Sep 17 00:00:00 2001 From: Tobias Hunger tobias.hun...@digia.com Date: Wed, 24 Sep 2014 21:57:00 +0200 Subject: [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags= on kernel command line This allows to configure boot loader entries for systems where the root and usr filesystems are in different subvolumes (or even on different drives). What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Best Regards, Tobias On 08.10.2014 14:13, Harald Hoyer wrote: On 24.09.2014 22:08, Tobias Hunger wrote: From f3a193de94959875cd1d83f941ed8fc8275c82eb Mon Sep 17 00:00:00 2001 From: Tobias Hunger tobias.hun...@digia.com Date: Wed, 24 Sep 2014 21:57:00 +0200 Subject: [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags= on kernel command line This allows to configure boot loader entries for systems where the root and usr filesystems are in different subvolumes (or even on different drives). What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. doh.. didn't sent to mailing list... resent to list only.. sorry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 09.10.2014 09:37, Tobias Hunger wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com mailto:harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Yes :) Sounds legit. Lennart, approved from my side (didn't look at the code, though). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Hmm, so I think this should be merged, but I'd like to ask for one more change. We really want to avoid inventing new non-namespaced kernel command line options, that's really something we should leave to the kernel guys... Hence, I'd propose using mount.usr=, mount.usrflags= and mount.usrfstype=... Or maybe fs. as prefix? Or mnt.? But I think mount. is the nicest one, even if it is slightly more to type. Hope that make sense? (OTOH I just yesterday merged a patch that introduced a new un-namespaced kernel cmdline option rescue, so I am not totall fair here, but I think that's a special case...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 09.10.2014 16:08, Lennart Poettering wrote: On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Hmm, so I think this should be merged, but I'd like to ask for one more change. We really want to avoid inventing new non-namespaced kernel command line options, that's really something we should leave to the kernel guys... Hence, I'd propose using mount.usr=, mount.usrflags= and mount.usrfstype=... Or maybe fs. as prefix? Or mnt.? But I think mount. is the nicest one, even if it is slightly more to type. Hope that make sense? (OTOH I just yesterday merged a patch that introduced a new un-namespaced kernel cmdline option rescue, so I am not totall fair here, but I think that's a special case...) Lennart Just be careful choosing the prefix. It must not be the name of a kernel module, otherwise this kernel module is presented with all those options, which might freak out that module. I accidentally chose rd. not knowing that rd is a module alias for the brd kernel module. Just check with a recent kernel: # modinfo prefix I have the feeling, we should somehow register a namespace for userspace on the kernel command line or have global list. :-/ I just don't want to end with something like org.freedesktop.systemd.log_level=... :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 09.10.2014 16:24, Harald Hoyer wrote: On 09.10.2014 16:08, Lennart Poettering wrote: On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Hmm, so I think this should be merged, but I'd like to ask for one more change. We really want to avoid inventing new non-namespaced kernel command line options, that's really something we should leave to the kernel guys... Hence, I'd propose using mount.usr=, mount.usrflags= and mount.usrfstype=... Or maybe fs. as prefix? Or mnt.? But I think mount. is the nicest one, even if it is slightly more to type. Hope that make sense? (OTOH I just yesterday merged a patch that introduced a new un-namespaced kernel cmdline option rescue, so I am not totall fair here, but I think that's a special case...) Lennart Just be careful choosing the prefix. It must not be the name of a kernel module, otherwise this kernel module is presented with all those options, which might freak out that module. I accidentally chose rd. not knowing that rd is a module alias for the brd kernel module. Just check with a recent kernel: # modinfo prefix Oh, that might not work with builtin modules and not shipped modules. So you have to manually check the kernel source code :-/ I have the feeling, we should somehow register a namespace for userspace on the kernel command line or have global list. :-/ I just don't want to end with something like org.freedesktop.systemd.log_level=... :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
I will update the patch as soon as I get home :-) Best Regards, Tobias PS: How do you send patches to this list via gmail? I pasted the output from git format-patch into the mail client, bit there got to be a better way:-) On Oct 9, 2014 4:08 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Hmm, so I think this should be merged, but I'd like to ask for one more change. We really want to avoid inventing new non-namespaced kernel command line options, that's really something we should leave to the kernel guys... Hence, I'd propose using mount.usr=, mount.usrflags= and mount.usrfstype=... Or maybe fs. as prefix? Or mnt.? But I think mount. is the nicest one, even if it is slightly more to type. Hope that make sense? (OTOH I just yesterday merged a patch that introduced a new un-namespaced kernel cmdline option rescue, so I am not totall fair here, but I think that's a special case...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Thu, 09.10.14 17:30, Tobias Hunger (tobias.hun...@gmail.com) wrote: I will update the patch as soon as I get home :-) Best Regards, Tobias PS: How do you send patches to this list via gmail? I pasted the output from git format-patch into the mail client, bit there got to be a better way:-) It's OK to just attach the git-format-patch formatted patches to your mail, even if it isn't the wahre Lehre. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 9 October 2014 17:30, Tobias Hunger tobias.hun...@gmail.com wrote: PS: How do you send patches to this list via gmail? I pasted the output from git format-patch into the mail client, bit there got to be a better way:-) Using git send-email works surprisingly well with Gmail [1]. Regards, T G-R [1] See https://coderwall.com/p/dp-gka for an example ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Thu, Oct 2, 2014 at 3:15 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 24.09.14 22:08, Tobias Hunger (tobias.hun...@gmail.com) wrote:
The patch is line-broken, please resend non-linebroken version!
I'll fix that, sorry.
+static int add_usr_mount(void) {
+_cleanup_free_ char *what = NULL;
+const char *opts;
+
+if (!arg_usr_what !arg_usr_fstype !arg_usr_options)
+return 0;
+
+if (arg_root_what !arg_usr_what)
+arg_usr_what = strdup(arg_root_what);
Hmm, what's the rationale here? I mean, then we'd mount the same stuff
to /usr that we already mount to / if one field is missing, is that
really disarable? Maybe better do a warning instead?
This patch should make it easy to mount the root:something and
usr:something subvolumes you had proposed earlier. / and /usr both
are separate in that proposal, but expected to be subvolumes of the
same BTRFS partition. So to keep the kernel commandline short, I just
went ahead and copied the missing arg_usr_* from the corresponding
arg_root_*.
Usually arg_usr_what and arg_usr_fstype will be unset and only
arg_usr_options will point to the usr:whatever subvolume on the same
BTRFS partition that is also used for /.
I see no reason not enforce this by removing the other options, though.
snip
Otherwise looks good to me, but I'd really like Harald Hoyer's
feedback on this, before we merge this.
Great:-) My C-foo is seriously rusted.
I am not entirely sure what our strategy here is precisely, and I think
dracut might already have something here.
I did not see anything, but having something in systemd would be nice
for distros not using dracut -- like the archlinux I am on.
Best Regards,
Tobias
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
From 681971f9cca5b3db085f47750f27f3f8d51f5036 Mon Sep 17 00:00:00 2001 From: Tobias Hunger tobias.hun...@digia.com Date: Wed, 24 Sep 2014 21:57:00 +0200 Subject: [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags= on kernel command line This allows to configure boot loader entries for systems where the root and usr filesystems are in different subvolumes (or even on different drives). --- man/systemd-fstab-generator.xml | 76 - src/fstab-generator/fstab-generator.c | 90 +-- 2 files changed, 160 insertions(+), 6 deletions(-) diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml index e3cf5d2..63a3db5 100644 --- a/man/systemd-fstab-generator.xml +++ b/man/systemd-fstab-generator.xml @@ -104,9 +104,83 @@ (initrd) while varnamefstab=/varname is honored by both the main system and -the initrd. /para/listitem +the initrd./para/listitem /varlistentry +varlistentry +termvarnameroot=/varname/term + +listitemparaTakes the root filesystem to mount +in the initrd. +varnameroot=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry + termvarnamerootfstype=/varname/term + +listitemparaTakes the root filesystem type that +will be passed to the mount command. +varnamerootfstype=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry + termvarnamerootflags=/varname/term + +listitemparaTakes the root filesystem mount options +to use. varnamerootflags=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry +termvarnameusr=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem to be mounted by the initrd. If +varnameusrfstype=/varname or +varnameusrflags=/varname is set, then +varnameusr=/varname will default to the value set in +varnameroot=/varname./para + +paraOtherwise this parameter defaults to the +filename/usr/filename entry +found in filename/etc/fstab/filename on the root +filesystem./para + +paravarnameusr=/varname is honored by the initrd. +/para/listitem +/varlistentry +varlistentry + termvarnameusrfstype=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem type that will be passed to the mount +command. If varnameusr=/varname or +varnameusrflags=/varname is set, then +varnameusrfstype=/varname will default to the value set in +varnamerootfstype=/varname./para + +paraOtherwise this value will be read from the +filename/usr/filename entry in +filename/etc/fstab/filename on the root filesystem./para + +paravarnameusrfstype=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry + termvarnameusrflags=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem mount options to use. If +varnameusr=/varname or +varnameusrfstype=/varname is set, then +varnameusrflages=/varname will default to the value set in +varnamerootflags=/varname./para +paraOtherwise this value will be read from the +
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
Thanks for the information, I am not in a hurry and am no longer feeling ignored. It is also reassuring to hear that I did not do something obviously wrong like sending the patch here without also requesting a review on some website or whatever. Some projects are rather imaginative when it comes to patch submission processes nowadays:-) Best Regards, Tobias On Wed, Oct 1, 2014 at 12:26 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Ronny Chevalier wrote on 30/09/14 20:28: Hi, 2014-09-30 21:18 GMT+02:00 Tobias Hunger tobias.hun...@gmail.com: Any feedback at all? Please? Am I doing something wrong in posting my patch here? No you just need to wait that someone review your patch. It rarely takes more than 2 weeks. Also note that Lennart specifically is on vacation at the moment and this is likely one he'd want to review himself. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Wed, 24.09.14 22:08, Tobias Hunger (tobias.hun...@gmail.com) wrote:
The patch is line-broken, please resend non-linebroken version!
+static int add_usr_mount(void) {
+_cleanup_free_ char *what = NULL;
+const char *opts;
+
+if (!arg_usr_what !arg_usr_fstype !arg_usr_options)
+return 0;
+
+if (arg_root_what !arg_usr_what)
+arg_usr_what = strdup(arg_root_what);
Hmm, what's the rationale here? I mean, then we'd mount the same stuff
to /usr that we already mount to / if one field is missing, is that
really disarable? Maybe better do a warning instead?
+
+if (arg_root_fstype !arg_usr_fstype)
+arg_usr_fstype = strdup(arg_root_fstype);
+
+if (arg_root_options !arg_usr_options)
+arg_usr_options = strdup(arg_root_options);
OOM checks missing for this.
+} else if (streq(key, usr) value) {
+
+free(arg_usr_what);
+arg_usr_what = strdup(value);
+if (!arg_usr_what)
+return log_oom();
We recently added free_and_strdup(), which should make the four lines
above shorter:
if (free_and_strdup(arg_usr_what, value) 0)
return log_oom();
+
+} else if (streq(key, usrfstype) value) {
+
+free(arg_usr_fstype);
+arg_usr_fstype = strdup(value);
+if (!arg_usr_fstype)
+return log_oom();
Similar.
Otherwise looks good to me, but I'd really like Harald Hoyer's
feedback on this, before we merge this. I am not entirely sure what
our strategy here is precisely, and I think dracut might already have
something here.
Harald, can you comment?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
Ronny Chevalier wrote on 30/09/14 20:28: Hi, 2014-09-30 21:18 GMT+02:00 Tobias Hunger tobias.hun...@gmail.com: Any feedback at all? Please? Am I doing something wrong in posting my patch here? No you just need to wait that someone review your patch. It rarely takes more than 2 weeks. Also note that Lennart specifically is on vacation at the moment and this is likely one he'd want to review himself. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
Any feedback at all? Please? Am I doing something wrong in posting my patch here? Best Regards, Tobias On Sat, Sep 27, 2014 at 5:59 PM, Tobias Hunger tobias.hun...@gmail.com wrote: Ping? This is really useful to test out the changes proposed in http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html Yes, Lennart seems to want to move to something more strict that can also work with the uefi secure boot, but this helps me get a test system of the ground where the / und /usr mounts are defined in the bootloader entries. Even works with encrypted partitions here;-) Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
Hi, 2014-09-30 21:18 GMT+02:00 Tobias Hunger tobias.hun...@gmail.com: Any feedback at all? Please? Am I doing something wrong in posting my patch here? No you just need to wait that someone review your patch. It rarely takes more than 2 weeks. Best Regards, Tobias On Sat, Sep 27, 2014 at 5:59 PM, Tobias Hunger tobias.hun...@gmail.com wrote: Ping? This is really useful to test out the changes proposed in http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html Yes, Lennart seems to want to move to something more strict that can also work with the uefi secure boot, but this helps me get a test system of the ground where the / und /usr mounts are defined in the bootloader entries. Even works with encrypted partitions here;-) Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
Ping? This is really useful to test out the changes proposed in http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html Yes, Lennart seems to want to move to something more strict that can also work with the uefi secure boot, but this helps me get a test system of the ground where the / und /usr mounts are defined in the bootloader entries. Even works with encrypted partitions here;-) Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
