| 1 |
On 8/5/19 5:45 AM, Mick wrote: |
| 2 |
> Interesting concept, thanks for sharing. |
| 3 |
|
| 4 |
You're welcome. |
| 5 |
|
| 6 |
> Unless I misunderstand how this will work, it will create duplication |
| 7 |
> of the fs for /bin and /sbin, which will both use extra space and |
| 8 |
> require managing. |
| 9 |
|
| 10 |
Yes, it will create some duplication. Though I don't think that /all/ |
| 11 |
of the contents of /bin and /sbin would need to be duplicated. Think |
| 12 |
about the minimum viable binaries that are needed. |
| 13 |
|
| 14 |
Perhaps something like busybox would even suffice. |
| 15 |
|
| 16 |
> Will you mount -bind the underlying fs in fstab? |
| 17 |
|
| 18 |
You could. I have done so in some VMs that I've tested various things. |
| 19 |
|
| 20 |
My use case on my VPS is for an encrypted data partition. So I have |
| 21 |
things like the following: |
| 22 |
|
| 23 |
/home -> /var/LUKS/home |
| 24 |
/etc/mail -> /var/LUKS/etc/mail |
| 25 |
/etc/bind -> /var/LUKS/etc/bind |
| 26 |
|
| 27 |
/var/LUKS/home/gtaylor does have an absolute minimum directory structure |
| 28 |
so that I can ssh in with my key and run a script to unlock / open and |
| 29 |
mount the LUKS volume and start some services (mostly email and DNS |
| 30 |
related). |
| 31 |
|
| 32 |
> How will you make sure installations of the same binaries are |
| 33 |
> installed/copied in both underlying and mounted /usr/* fs and kept |
| 34 |
> in sync? By changing all affected ebuilds? |
| 35 |
|
| 36 |
I don't have an answer to this qustion. I've not needed an answer to |
| 37 |
this question. |
| 38 |
|
| 39 |
I think I would likely create a script that would copy specific files |
| 40 |
from the /usr path to the underlying /(usr) path as needed. |
| 41 |
|
| 42 |
I doubt there would be many files. |
| 43 |
|
| 44 |
I don't see any need to alter an untold number of ebuilds for a system |
| 45 |
architecture / file system decision. |
| 46 |
|
| 47 |
> It is a hack alright, to restore the previous default /usr |
| 48 |
> functionality, so a useful option to consider. |
| 49 |
|
| 50 |
That's why I shared it. |
| 51 |
|
| 52 |
It's also an example of an idea that works for my use case that you are |
| 53 |
free to take and modify for your use case. I don't need to know about |
| 54 |
your use case, much less have an answer for it, when I'm sharing my use |
| 55 |
case. (Harking back to the different types of communities in the |
| 56 |
previous email.) |
| 57 |
|
| 58 |
> If I were to be asked my preference would be to revert the systemd |
| 59 |
> inspired changes which caused this loss of functionality. ;-) |
| 60 |
|
| 61 |
Fair enough. |
| 62 |
|
| 63 |
Though I would question just how much and what is broken by having a |
| 64 |
separate /usr file system without systemd. }:-) Specifically, is it |
| 65 |
truly broken? Or does it need some minor tweaks? |
| 66 |
|
| 67 |
|
| 68 |
|
| 69 |
-- |
| 70 |
Grant. . . . |
| 71 |
unix || die |
Archives