Gentoo Archives: gentoo-user

From: thegeezer <thegeezer@×××××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Optional /usr merge in Gentoo
Date: Mon, 19 Aug 2013 16:12:03
Message-Id: 521243C2.404@thegeezer.net
In Reply to: Re: [gentoo-user] Re: Optional /usr merge in Gentoo by Alecks Gates
1 On 08/19/2013 03:37 PM, Alecks Gates wrote:
2 > On Mon, Aug 19, 2013 at 9:30 AM, Alon Bar-Lev <alonbl@g.o> wrote:
3 >> On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates <alecks.g@×××××.com> wrote:
4 >>> On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tanstaafl@×××××××××××.org> wrote:
5 >>>> On 2013-08-18 10:55 PM, Canek Peláez Valdés <caneko@×××××.com> wrote:
6 >>>>> And, putting aside systemd and getting back on topic to the council's
7 >>>>> decision of (eventually) not supporting separated /usr without an
8 >>>>> initramfs; have you ever stopped to consider that, perhaps, that's the
9 >>>>> best *technical* decision? (*gasp*)
10 >>>>
11 >>>> That is *not* the concern here, Canek, and that should be obvious from the comments here.
12 >>>>
13 >>>> Repeat: the primary concern is *not* about separate /usr without initramfs.
14 >>>>
15 >>>> The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev or *anything* other than systemd (ie OpenRC/eudev) will.
16 >>>>
17 >>> *snip*
18 >>>>> When you have almost all distributions converging on that, and even
19 >>>>> *the OpenRC maintainer* (which is the one pushing this, BTW, not the
20 >>>>> systemd guys) supporting that decision, don't you think that perhaps,
21 >>>>> just*perhaps*, everybody screaming about the sky falling (which, BTW,
22 >>>>>
23 >>>>> they are certainly noisy, but I really don't think are that many) are
24 >>>>> overreacting and even (*gasp* again) wrong?
25 >>>>
26 >>>> Again, the main issue is not about separate /usr, so please stop trying to deflect the subject...
27 >>>>
28 >>> Isn't that what this thread is about? "Optional /usr merge in Gentoo"
29 >>>
30 >>> Can someone please explain to me what's so hard and/or complicated
31 >>> about making an initramfs? At this point in time it's extremely
32 >>> simple for me, but I only manage relatively simple systems (although
33 >>> I'd like that to change soon). All I do is add one extra line (for
34 >>> example - "dracut -H --kver=3.11.0-rc6") to my kernel install
35 >>> procedure.
36 >>>
37 >>> Granted, the only reason I have an initramfs is for the plymouth
38 >>> splash screen (other systems aren't desktops) -- but from everything I
39 >>> can see it's not too complicated otherwise.
40 >> Yeah... it is not complicated to but Windows as well, or IBM os-390!!!
41 >>
42 >> You use a tool that hides the initramfs building, and you are amazed
43 >> it is simple?
44 > Dracut isn't *hiding* anything from me, I just don't need anything
45 > more complicated -- who said I'm amazed?
46 >
47 >> The files within the initramfs generation tool are compiled using
48 >> different tool than portage, they are not updated when distribution is
49 >> updated, and they are not even at same version within portage tree.
50 > Why does this matter? Are there some huge security vulnerabilities
51 > I'm unaware of?
52
53 If you have one system to keep on top of, it's simple to make sure to
54 update initramfs after a kernel update
55 If you have many systems, and they are remote, it becomes trickier.
56 A borked kernel update remotely can be easily resolved by panic=1 and
57 having a grub failsafe boot option.
58 It doesn't even need a kernel update. I'm a big fan of LVM, but i found
59 that in the upgrade to sys-fs/lvm2-2.02.99-r2 my usb devices were coming
60 up as invalid pvs on LVM start in the default runlevel, after the
61 initramfs. No biggie locally, and only backups were on those devices.
62 but remotely and at system updating times (silly oclock) it's easy to
63 miss a simple thing like initrd update.
64 worse if what is borked is relied upon -- consider a system that only
65 boots 75% -- it doesn't fail but it doesn't start all services in the
66 default runlevel because the initrd is not updated, or is updated
67 incorrectly.
68 being locked out of boxes remotely at silly oclock sucks, and we don't
69 always have the benefit of OOB management, IPVS or DRBD to not worry
70 about it until after sleep has relaxed the mind.
71
72 this has always been one of the biggest pros of gentoo for me - where
73 everything is a stream of data even the OS is like a slipstream.
74 updating many gentoos however can be a big issue and I do try to keep
75 similar boxes similar hardware because of it -- allowing me to test
76 updates before they get rolled out, and also allows me to add in crucial
77 use flags (dlz, openssl) when they suddenly become required; great to
78 figure out on a test machine first and then roll out x30 rather than
79 figure out 30times over!
80
81 Because of LVM/LUKS i have used initrd for a long time but i can
82 understand why the migration sucks - first install and testing and then
83 maintenance thereafter. Going up to udev200 was scary enough. . . scary
84 because of that remote system status on NIC naming!
85 Equally we don't always have the benefit of a secondary identical
86 monster server to test new configurations on.
87
88 i almost would like to request tighter integration between
89 portage/kernel building/initrd but i'm not convinced the ubuntu way is
90 the correct way as that leads to customisations breaking systems, and
91 gentoo is all about customisation, making the OS fit the hardware.
92
93 >
94 >> It may be acceptable for you... but do not expect everyone will accept
95 >> your setup.
96 > Don't mind me, I'm just looking for the logic. Feel free to explain it to me.
97 >
98 >> Regards,
99 >> Alon
100 >>

Replies

Subject Author
Re: [gentoo-user] Re: Optional /usr merge in Gentoo Neil Bothwick <neil@××××××××××.uk>