Gentoo Archives: gentoo-dev

From: "J. Roeleveld" <joost@××××××××.org>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: eudev project announcement
Date: Fri, 21 Dec 2012 10:25:54
Message-Id: 2519759.yK9dD2bOet@eve
In Reply to: Re: [gentoo-dev] Re: eudev project announcement by "Michał Górny"
1 On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
2 > On Fri, 21 Dec 2012 09:10:22 +0100
3 >
4 > "J. Roeleveld" <joost@××××××××.org> wrote:
5 > > On Thursday, December 20, 2012 09:31:36 AM Michał Górny wrote:
6 > > > On Thu, 20 Dec 2012 00:27:26 +0100
7 > > >
8 > > > "J. Roeleveld" <joost@××××××××.org> wrote:
9 > > > > On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote:
10 > > > > > On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote:
11 > > > > > > On Mon, December 17, 2012 22:31, Greg KH wrote:
12 > > > > > > > On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
13 > > > > > > >> Olav Vitters <olav@×××××××.nl> wrote:
14 > > > > > > >> >On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
15 > > > > > > >> >> As I said in an earlier email, Lennart Poettering claims
16 > > > > > > >> >> that it
17 > > > > > > >> >> does
18 > > > > > > >> >> not work. We are discussing some of the things necessary to
19 > > > > > > >> >> make
20 > > > > > > >> >> it
21 > > > > > > >> >
22 > > > > > > >> >work.
23 > > > > > > >> >
24 > > > > > > >> >Just to repeat:
25 > > > > > > >> >In this thread it was claimed that a separate /usr is not
26 > > > > > > >> >supported by
27 > > > > > > >> >systemd/udev.
28 > > > > > > >> >
29 > > > > > > >> >A case which works with latest systemd on various
30 > > > > > > >> >distributions. I
31 > > > > > > >> >checked with upstream (not Lennart), and they confirmed it
32 > > > > > > >> >works.
33 > > > > > > >> >I
34 > > > > > > >> >can
35 > > > > > > >> >wait for Lennart to say the same, but really not needed.
36 > > > > > > >> >
37 > > > > > > >> >I assume this will again turn into a "but I meant something
38 > > > > > > >> >else".
39 > > > > > > >>
40 > > > > > > >> Olav.
41 > > > > > > >>
42 > > > > > > >> Lennart has stated that he considers a seperate /usr without
43 > > > > > > >> init*
44 > > > > > > >> broken.
45 > > > > > > >
46 > > > > > > > Yes, as do I, and so do a lot of other developers.
47 > > > > > >
48 > > > > > > It is only "broken", because upstream decided to move everything
49 > > > > > > into
50 > > > > > > /usr
51 > > > > > > that was previously in /.
52 > > > > >
53 > > > > > No, not at all, please see the web page that describes, in detail,
54 > > > > > the
55 > > > > > problems that has been going on for quite some time now, with the
56 > > > > > /usr
57 > > > > > and / partitions and packages.
58 > > > > >
59 > > > > > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
60 > > > > >
61 > > > > > One good solution to this issue is to move everything into /usr, and
62 > > > > > that's something that has wonderful benifits in the long run, and is
63 > > > > > something that I expect all Linux distros to eventually implement.
64 > > > > > Those that don't, will suffer because of it.
65 > > > > >
66 > > > > > Again, see the web page for why moving stuff into /usr is a good
67 > > > > > idea
68 > > > > > for the reasons behind this.
69 > >
70 > > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
71 > >
72 > > > > Example: /usr Network Share
73 > > > > When /usr is on a network share, why not add a / on network as well?
74 > > > > I have multiple systems and as they all have different uses, they all
75 > > > > have
76 > > > > different software installed.
77 > > > >
78 > > > > Example: Multiple Guest Operating Systems on the Same Host
79 > > > > See answer to previous example.
80 > > > >
81 > > > > How many environments actually currently exist where a shared /usr is
82 > > > > being
83 > > > > used?
84 > > >
85 > > > Are you aware that these environments are actually one of the most
86 > > > important reasons for moving everything to /usr? I don't know what
87 > > > hackery you're using to keep the systems in sync and working but it is
88 > > > braindead enough.
89 > >
90 > > An init* needs to be kept in sync with the rest of the system as well. As
91 > > that is a compressed filesystem, it takes a lot more effort to keep that
92 > > in sync in comparison to a "normal" filesystem.
93 > > I consider having to write scripts to unpack, modify and repack an init*
94 > > to be more hackery then to keep a bootable root-filesystem working that
95 > > can mount all the filesystems needed for the whole environment.
96 > > Anything needed to mount /usr, /var, /run (and any other part needed for
97 > > the boot-process) should not be allowed to depend on anything in any of
98 > > those directories prior to those being mountable.
99 > >
100 > > > The difference between keeping part of the system in rootfs
101 > > > and initramfs is that you can discard initramfs after using it. It can
102 > > > be anything which is enough to get the /usr mounted and system
103 > > > starting. Files on rootfs *have* to be in sync with those on /usr
104 > > > or you're getting random failures.
105 > >
106 > > The same is true for an init*.
107 > > If an update of part of the OS leads to subtle changes in the filesystem
108 > > where older versions can no longer properly access them, the init* is
109 > > broken.
110 > Just let me know when you have to maintain a lot of such systemd
111 > and upgrade, say, glibc. Then maybe you'll understand.
112
113 A shared /usr means I need to update ALL the systems at once.
114 When /usr is not shared, I can update groups at a time.
115
116 To save time, a shared filesystem containing binary packages can easily be
117 used and this is what I use myself.
118 I have one VM that is used to rebuild the packages when I want to do an update
119 and the real host then simply uses the binary packages.
120 The configuration items needed for emerge are synchronized between the build
121 system and the actual server.
122
123 The main reason why I would never share an OS filesystem between multiple
124 systems is to avoid the situation where a failed upgrade takes down the entire
125 environment.
126 And a shared OS filesystem also introduces a very nice Single Point of
127 Failure. What will happen when the NFS-server (or whatever is used) goes down
128 for whatever reason?
129
130 In other words, to make an environment that has a very nice single point of
131 failure possible, existing working environments are classed as "broken".
132
133 --
134 Joost

Replies

Subject Author
Re: [gentoo-dev] Re: eudev project announcement "Michał Górny" <mgorny@g.o>