1 |
Rich Freeman wrote: |
2 |
|
3 |
> On Wed, Jan 4, 2012 at 8:50 AM, Steven J Long |
4 |
> <slong@××××××××××××××××××.uk> wrote: |
5 |
>> The thing I don't understand is why it is necessary to move stuff from |
6 |
>> /bin to /usr/bin. After all, if you're running the "approved" setup you |
7 |
>> don't have a separate /usr so all the binaries are available from the |
8 |
>> get-go. |
9 |
> |
10 |
> Where is this approved setup documented? |
11 |
|
12 |
I could swear we were told in prior discussions on this list that a separate |
13 |
/usr partition is not considered supported by upstream udev, but searching |
14 |
all I can find is that an initramfs is required.[1] |
15 |
|
16 |
Having read the other page[2] that has been pointed out, the answer to my |
17 |
question "what does this enable that we can't do currently?" is: |
18 |
snapshotting the OS by backing up just the /usr partition. |
19 |
|
20 |
I can see the attraction in that, especially for organisations. Though it |
21 |
does make me smile that it depends on having a separate /usr partition to |
22 |
work. ;) |
23 |
|
24 |
The whole saga has just seemed confused to me: one minute a separate /usr is |
25 |
a terrible idea, the next we have to move every binary to /usr in order to |
26 |
snapshot a separate /usr. Loath as I am to agree with him, I have to concur |
27 |
with Ciaran McCreesh that this is "a case of carelessly letting the horse |
28 |
escape and then trying to convince everyone that no-one needs a horse |
29 |
anyway."[3] |
30 |
|
31 |
> Well, it is hard to think of a meaningful raid+lvm configuration that |
32 |
> doesn't require an initramfs of some sort with the dependence on files |
33 |
> in /usr during boot. So, getting our initramfs options improved and |
34 |
> supporting this configuration just makes sense regardless before we |
35 |
> unmask newer versions of udev. |
36 |
> |
37 |
I was under the impression that anyone using lvm+raid (+luks) on root |
38 |
already has an initramfs, and there are docs out there about that, but sure, |
39 |
improving those docs and the software is always a good idea. |
40 |
|
41 |
> Raid+lvm isn't exactly an unusual use-case. Many distros actually use |
42 |
> at least lvm by default now. |
43 |
> |
44 |
Yeah I've been using lvm for several years now, with a separate /usr and no |
45 |
initramfs, though not on root. For the last few months, I've been running |
46 |
with the tweaked udev startup scripts I mentioned before, so /usr is mounted |
47 |
before udev starts (which is possible since I don't have any requirement on |
48 |
udev-initialised hardware to mount local drives.) |
49 |
|
50 |
Regardless of the ability to backup just /usr, I'm still not convinced about |
51 |
moving every binary there. It certainly isn't necessary, in that the |
52 |
packages we install respect prefix, and there's no need to change the |
53 |
ebuilds to make packages work; further most admins already have their own |
54 |
backup scripts in-place. |
55 |
|
56 |
I for one, would like to be able to run in single-user mode off just the |
57 |
rootfs, in case for instance, something goes wrong with lvm and /usr won't |
58 |
mount; and I don't want to duplicate all those utilities in an initramfs. If |
59 |
that's not going to be possible, fair enough: that's life. |
60 |
|
61 |
[1] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken |
62 |
[2] http://fedoraproject.org/wiki/Features/UsrMove |
63 |
[3] http://article.gmane.org/gmane.linux.gentoo.devel/72130 |
64 |
-- |
65 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |