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 |