Gentoo Archives: gentoo-user

From: Grant Taylor <gtaylor@×××××××××××××××××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: USE flag 'split-usr' is now global
Date: Thu, 08 Aug 2019 03:57:03
Message-Id: db918e61-15a3-2e7f-7e1e-e9acc85061f0@spamtrap.tnetconsulting.net
In Reply to: Re: [gentoo-user] Re: USE flag 'split-usr' is now global by Rich Freeman
1 On 8/6/19 6:31 PM, Rich Freeman wrote:
2 > So, an initramfs doesn't actually have to do ANY of those things,
3 > though typically it does.
4
5 I agree that most systems don't /need/ an initramfs / initrd to do that
6 for them. IMHO /most/ systems should be able to do that for themselves.
7
8 > Nothing prevents an initramfs from booting an alternate kernel
9 > actually, though if it does it will need its own root filesystem
10 > initialized one way or another (which could be an initramfs).
11
12 Agreed.
13
14 Though I think that's rare enough that I chose to ignore it for the last
15 email.
16
17 > Linux bootstrapping linux is basically the whole premise behind
18 > coreboot.
19
20 Sure.
21
22 But coreboot is not a boot loader or a typical OS. coreboot falls into
23 the "firmware" family.
24
25 > Sure, but you don't need it ALL OVER YOUR FILESYSTEM.
26
27 I'd be willing to bet that 75% of what's contained in an initramfs /
28 initrd is already on the root file system. Especially if the initramfs
29 / initrd is tweaked to the local system.
30
31 Taking a quick look at the default initrd of an Ubuntu 16.04 LTS, just
32 about everything I see in the following output exists on the system.
33
34 /boot/initrd.img-4.4.0-87-generic has 1908 items in it.
35
36 129 of them aren't already on the installed system. Consisting of:
37
38 51 /scripts Probably initrd specific
39 61 /bin May be in /sbin /usr/bin /usr/sbin on the local system.
40 6 /conf Probably initrd specific
41 5 /etc
42 2 /lib
43 4 misc
44
45 Digging further, 29 of the 61 for /bin are in /usr/bin. 12 are in
46 /sbin. That's 88 out of 1908 files in the
47 /boot/initrd.img-4.4.0-87-generic file that aren't already all over your
48 file system.
49
50 > Some of the proposed solutions in this thread involved sticking stuff
51 > in /bin and so on. An initramfs is nicely bundled up in a single file.
52
53 So, you're saving 88 files (out of 1908) and storing 1820 additional
54 copies of files that exist in a container that's not easy to work with.
55
56 Why‽
57
58 > Absolutely true, which means it won't interfere with the main system,
59 > as opposed to sticking it in /bin or somewhere where it might.
60
61 How do the files that are needed for the system to operate, being placed
62 where they need to be, interfere with the main system?
63
64 > Such as?
65
66 Allow me to rephrase / clarify slightly.
67
68 There have been many things that I've wanted to do in the past 20 yeras
69 that the initramfs / initrd from the vendor did not support or was not
70 flexible enough to do.
71
72 · Not support root in LVM.
73 · Not support root on LUKS.
74 · Not support iSCSI disks.
75 · Not support root on multi-path.
76 · Not supporting the file system (tools).
77 · Not support the RAID that (tools).
78 · Not support ZFS.
79 · Not support root on NFS.
80
81 These are just the some of the things that I've wanted to do over the
82 years that the initramfs / initrd as provided by the distro did not support.
83
84 I have routinely found initramfs / initrd limiting.
85
86 > It is a linux userspace. It can literally do anything.
87
88 Yes, /conceptually/ it's Linux (userspace) can do anything that Linux
89 can do. /Practically/ it can only do the things that the distro
90 envisioned support for and included in their initramfs / initrd
91 management system.
92
93 > You don't need to use dracut (et al) to have an initramfs.
94
95 (See above.)
96
97 > In fact, you could create your super root filesystem that does all
98 > the fancy stuff you claim you can't do with an initramfs,
99
100 Sure. I did. (Time and time again) it was the machine's root file
101 system doing exactly what I wanted it to do.
102
103 > then create a cpio archive of that root filesystem, and now you have
104 > an initramfs which does the job.
105
106 Why would I want to copy / permute something that's already working to
107 add as an additional layer, which I don't need, complicating the overall
108 process‽
109
110 > Sure, but only if the kernel can find that disk without any userspace
111 > code.
112
113 There's a reason I said "if". The extremely large majority of the
114 systems that I've administered over the last 20 years could do that.
115
116 > What if that disk is on the other side of an ssh tunnel?
117
118 That would be a case where you would actually /need/ an initramfs / initrd.
119
120 I'd like to hear tell of someone actually using a root disk that is
121 accessed through an ssh tunnel. Short of that, I'm going to consider it
122 a hypothetical.
123
124 > If you know the commands to do something, why would you have to wait
125 > for somebody else to implement them?
126
127 Because I have hundreds of machines that need to be supported by junior
128 admins and sticking within the confines of what the distro vendor
129 supports is a good idea.
130
131 Or more simply, sticking within distro vendor's support period.
132
133 > Actually, for most of these the initramfs is the starting
134 > root filesystem (just about all linux server installs use one).
135
136 Remember, an initramfs / initrd is (or gets extracted to) a directory
137 structure.
138
139 Just about all of the servers and workstations (mid five digits worth)
140 that I've administered over the years end up with a SCSI (SATA / SAS)
141 disk off of a controller with the driver in kernel. Include file system
142 and NIC driver too, and you're good to go without an initramfs / initrd.
143 That includes physical and virtual systems.
144
145 The containers that I've worked with also end up being a collection of
146 files on a file system.
147
148 Nope. Very few of them actually /need/ an initramfs / initrd.
149
150 · LUKS
151 · Multipath SAN
152
153 Those are the big reasons for a server / workstation to actually /need/
154 an initramfs / initrd.
155
156 BlueTooth is not an issue for the servers that I've administered and
157 handily enough the notebooks that have had LUKS have also had a keyboard.
158
159 > Usually it just mounts a simple filesystem on a local disk as root
160 > and then pivots.
161
162 Why even bother doing that if it's not actually /needed/?
163
164 > However, an initramfs frees you up from the limitation that it be
165 > something that can be passed directly on the command line.
166
167 I've never really found what I can pass on the kernel's command line to
168 be a problem.
169
170 I have had problems where the distro provided initramfs / initrd
171 management system lost it's lunch at some things I wanted to put on the
172 command line. But Linux itself was quite happy with it.
173
174 > Initramfs is popular because it is way more flexible:
175
176 See above. I've found them to be limiting.
177
178 > 1. You can build a fully modular kernel so that you can use the
179 > same kernel on every system but not be loading countless drivers
180 > for hardware most systems don't use, while still being certain of
181 > being able to boot any particular system.
182
183 That sounds like it's convenient for the distro maintainers.
184
185 > 2. You have more access to labels/uuids/etc for finding the root
186 > filesystem so that when one of your hard drive fails the kernel
187 > doesn't just dumbly use the next one in sequence, assuming they're
188 > even always identified in the same order.
189
190 I've been using file system UUIDs on the kernel command line for decades
191 without problems. I've not /needed/ an initramfs / initrd to do that.
192
193 > 3. You can use "exotic" installations like iscsi and so on, which
194 > seems pretty useful in an enterprise setting.
195
196 One would think.
197
198 Sadly, most enterprise admins that I've been around are scared to death
199 of booting from the SAN.
200
201 The few places that I've seen do it are using Fibre Channel. Which,
202 handily enough, shows up as SCSI directly attached disk.
203
204 > Except then you're tailoring your bootloader to individual systems.
205
206 Not really.
207
208 My current employer has about fifty different model servers in the
209 fleet, from about a dozen different vendors. We keep about five storage
210 drivers in kernel and things just work.
211
212 Former employers had about a hundred different models of servers from
213 about twenty different vendors. We had to keep about twenty drivers in
214 kernel.
215
216 There really wasn't any tailoring.
217
218 > Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the
219 > same kernel/bootloader/etc works everywhere, vs tailoring their boot
220 > process to every individual host.
221
222 I'm going to go out on a limb and guess that half of them couldn't
223 actually tell me how a system boots, from the firmware through init
224 scripts to a login prompt.
225
226 I'll go further out on a limb and blame that on ignorance and / or
227 laziness. Thankfully it's possible to remediate ignorance if the SA is
228 willing. Also, I'm referring to the bad laziness of I don't care if
229 it's less efficient / requires more resources, if it saves me time to
230 cut corners.
231
232 > What could be more elegant?
233
234 Not using something that you don't actually /need/.
235
236 > It minimizes the complexity of the kernel
237
238 No, it really doesn't. It might minimize the kernel config. /Might./
239
240 It's quite possible (and in many ways more secure) to run a kernel
241 without modules.
242
243 > which is why Linus generally prohibits the kernel from having any
244 > more advanced root mounting logic, and why pretty much every Linux
245 > system out there uses one.
246
247 I can't think of a time in the last ten years where the Linux kernel
248 couldn't mount root when the storage driver (and file system) was
249 compiled in with proper parameters on the kernel command line.
250
251 Root on LUKS, iSCSI, software RAID 5; sure, those things need help.
252 Virtually none of the server's I've supported needed any of those for
253 root. Other disks / file systems that were activated via init scripts?
254 Sure.
255
256
257
258 --
259 Grant. . . .
260 unix || die