<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 1, 2013 at 3:16 PM, Tom Gundersen <span dir="ltr"><<a href="mailto:teg@jklm.no" target="_blank">teg@jklm.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On Fri, Mar 1, 2013 at 2:26 PM, Lennart Poettering<br>
<<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br>
> Also, besides / and /usr, is there anything else that would ever show up<br>
> in fstab.sys? If it's only these two, then it appears much nicer to me<br>
> to simply have two kernel cmdline options for these (we have one<br>
> anyway... for /). I mean, being generic and stuff is all cool, but let's<br>
> not make things too generic here, if there's no reason to.<br>
<br>
</div>I don't know how useful it is, but I have seen people asking for<br>
support for subdirs of /usr as separate mounts. If we agree that<br>
that's something we don't want to support by default that's fine with<br>
me.<br>
<div class="im"><br>
>> Two alternatives were considered, but decided against:<br>
>>  * configure usr= on the kernel commandline in the same way as root= is.<br>
>>    However, this would be restricted to only the /usr mountpoint, and the<br>
>>    kernelcommandline is crowded enough as it is, so it seems more reasonable to<br>
>>    store the configuration in /etc (as we can). Moreover, this logic would allow<br>
>>    us to use more configuration sources from /etc in the future should that be<br>
>>    necessary.<br>
><br>
> But this sounds like something you need anyway, if you ever want to<br>
> support "generic" initrds that work everywhere, and whose sole source of<br>
> configuration is cmdline hence, right? With just one more option on the<br>
> kernel cmdline for usr= I don't really buy the "too crowded"<br>
> issue... Dunno. Do you see any further uses of this?<br>
<br>
</div>I believe one instance where this might be useful would be to share<br>
/usr/share between different architectures, but I suppose that could<br>
have been solved by a specially crafted initrd and don't need to be<br>
supported by default.<br>
<div class="im"><br>
>>  * configure the 'sys-mounts' in /etc/fstab. This would require a heuristic to<br>
>>    decide which mounts sohuld be taken care of by the initramfs and which to be<br>
>>    taken care of by the real init. I could not come up with a non-hacky way of<br>
>>    doing that. Perhaps there is use-case for mounting with one set of options in<br>
>>    the initrd and remounting with a different set of options in the real init<br>
>>    (like can be done for the rootfs)? Keeping everything in fstab would make<br>
>>    that impossible.<br>
><br>
> Well, you could always introduce "x-initrd" as a mount option to set for<br>
> mounts, if you really want to be this generic, and then filter for<br>
> it. And also imply it for / and for /usr. But honestly, the usr= kernel<br>
> cmdline thingy sounds much simpler and sexier to me?<br>
<br>
</div>If we only want to support / and /usr, and don't care about stuff like<br>
/usr/local or /usr/share on separate mounts, then going with usr=<br>
makes sense to me. It would also make everything else much simpler (no<br>
need to reload settings after mounting sysroot). I already wrote the<br>
patch for usr=, so I'll send it out soon.<br>
<br>
Harald, what do you think?</blockquote><div> <br>"x-initrd" or "x-initrd.mount" sounds good, but I would imply "x-initrd" for "/usr" if "noauto" is not set.<br></div></div>
<div>
<br></div><div>/etc/fstab.sys could just be copied to /etc/fstab in the initramfs. For the rest "x-initrd" can be used easily.<br><br></div><div>Main
 usage is for things, which get mounted in the initramfs, survive the 
switch-root and cannot be remounted with different options, because they
 are busy.<br>
<br></div>/dev/shm and /run come to my mind. <br></div></div>