1 |
On 8/6/19 10:28 AM, Rich Freeman wrote: |
2 |
> An initramfs is just a userspace bootloader that runs on top of linux. |
3 |
|
4 |
I disagree. |
5 |
|
6 |
To me: |
7 |
|
8 |
· A boot loader is something that boots / executes a kernel with |
9 |
various parameters. |
10 |
· An initramfs / initrd (concept) is the micro installation that runs |
11 |
under the kernel that was booted (by the boot loader). |
12 |
|
13 |
The initramfs / initrd micro installation does the following: |
14 |
|
15 |
1) fulfills prerequisites (e.g. loads requisite drivers, initializes |
16 |
networking for and discovers storage, decrypts block devices) |
17 |
2) mounts root (and some other) file systems |
18 |
3) launches additional init scripts. |
19 |
|
20 |
None of those steps include booting / executing an alternate kernel. |
21 |
|
22 |
Remember that the contents of an initramfs / initrd is a micro |
23 |
instillation that simply includes the minimum number of things to do |
24 |
steps 1–3 above. |
25 |
|
26 |
The initrd is literally an image of a block device with a root file |
27 |
system on it that includes the minimum number of things to do steps 1–3 |
28 |
above. |
29 |
|
30 |
The initramfs is a CPIO archive of the minimum number of things to do |
31 |
steps 1–3 above which get extracted to a temporary location (usually a |
32 |
ram disk). |
33 |
|
34 |
Both an initrd and an initramfs are a micro installation for the purpose |
35 |
of initializing the main installation. They are not a boot loader. |
36 |
|
37 |
> Nobody has any problem with conventional bootloaders, and if you want |
38 |
> to do anything with one of those you have to muck around in low-level |
39 |
> C or assembly. |
40 |
|
41 |
That's because a boot loader, e.g. GRUB, lilo, loadlin, do something |
42 |
different and operate at a lower level than system init scripts. |
43 |
|
44 |
> There has been talk of gathering up all the stuff you need from |
45 |
> /usr to bootstap everything, and then adding some scripting to mount |
46 |
> everything. The proposals have been to shove all that in / somewhere |
47 |
> (perhaps even in /bin or /sbin). If instead you just stick it all in |
48 |
> a cpio archive you basically have an initramfs, |
49 |
|
50 |
Not basically. That /is/ what an initramfs / initrd contains. |
51 |
|
52 |
> and you don't need to have cruft all over your filesystem to do it. |
53 |
|
54 |
Actually yes you do need that cruft. |
55 |
|
56 |
Let's back up and talk about what that cruft is. |
57 |
|
58 |
It's the minimum libraries and binaries required to: |
59 |
|
60 |
1) Requisite libraries |
61 |
- C library |
62 |
- other similar / minimal / unavoidable libraries |
63 |
2) Requisite binaries |
64 |
- fsck |
65 |
- mount |
66 |
- networking utilites (for iSCSI / NFS / etc.) |
67 |
- other similar / minimal / unavoidable binaries |
68 |
3) Scripts to bring the rest of the system up |
69 |
- minimal init scripts to go from a post-kernel-execution (what |
70 |
was traditionally /sbin/init) to launching second stage init scripts |
71 |
|
72 |
To me, all of these things are going to exist on the main installation |
73 |
/anyway/. There is going to be minimal, if any, difference between the |
74 |
version put in the initramfs / initrd and what's in the main / (root). |
75 |
|
76 |
So, to me, what you're calling "cruft" is core system files that are |
77 |
going to exist anyway. |
78 |
|
79 |
If anything, having an initramfs / initrd means that you're going to |
80 |
have an additional copy of said core system files in a slightly |
81 |
different format (initramfs / initrd) that's not usable by the main system. |
82 |
|
83 |
> There are already configurable and modular solutions like dracut which |
84 |
> do a really nice job of building one, |
85 |
|
86 |
Yes. We've had many different tools in the last 28 years of Linux and |
87 |
longer for Unix for making the management of the boot process simpler. |
88 |
|
89 |
It comes down to loading the kernel from something and starting the |
90 |
kernel with proper parameters (that's the boot loader's job) and |
91 |
starting something (traditionally /sbin/init) from some storage somewhere. |
92 |
|
93 |
> and they make your bootstrapping process infinitely flexible. |
94 |
|
95 |
Nope. I don't agree. |
96 |
|
97 |
There have been many things that I've wanted to do in the past 20 years |
98 |
that initramfs / initrd aren't flexible enough to do. |
99 |
|
100 |
But adding an init script that calls tools on the root file system is |
101 |
infinitely more flexible. I'm not restricted to doing things that |
102 |
dracut (et al.) know how to do. |
103 |
|
104 |
If I can boot the kernel, point it at a root disk, and launch an init |
105 |
system, I can do anything I want with the system. |
106 |
|
107 |
Let me say it this way. If I can put together commands to do something, |
108 |
I can get thee system to do it on boot. I don't have to wait for dracut |
109 |
to be updated to support the next wiz-bang feature. |
110 |
|
111 |
> If you want root to be a zip file hosted on a webserver somewhere |
112 |
> that isn't a problem. If you want root to be a rar file on a |
113 |
> gpg-encrypted attachment to a message stored on some IMAP server, |
114 |
> you could do that too. To make all that work you can just script it |
115 |
> in bash using regular userspace tools like curl or fetchmail, without |
116 |
> any need to go mucking around with lower-level code. Then once your |
117 |
> root filesystem is mounted all that bootstrapping code just deletes |
118 |
> itself and the system operates as if it was never there (strictly |
119 |
> speaking this isn't required but this is usually how it is done). |
120 |
|
121 |
You need /something/ to be your starting root file system. For most |
122 |
servers / workstations / VMs / containers, that's a local directory |
123 |
structure. |
124 |
|
125 |
Sadly, I think people have thrust additional (IMHO) largely unnecessary |
126 |
complexity into the init process just to be able to support more exotic |
127 |
installations. Then, they have said "We want to be consistent in how we |
128 |
boot, so we need to use this more complex thing everywhere." To which, |
129 |
many greybeards have responded "I don't need nor want that on my simple |
130 |
server." |
131 |
|
132 |
If you /actually/ /need/ a micro installation to make your main |
133 |
installation available, then go for it. But if you don't /actually/ |
134 |
/need/ a micro installation, well Occam's Razor / Parsimony. |
135 |
|
136 |
> I doubt we'll see a /usr merge anytime soon, or any huge rush to |
137 |
> break a separate /usr completely without an initramfs. |
138 |
|
139 |
Okay. |
140 |
|
141 |
> However, there are already use cases known where a separate /usr can |
142 |
> cause problems without either an initramfs or some kind of early-boot |
143 |
> shell script (there have already been solutions tossed out for that |
144 |
> which are much simpler than the ones in this thread). |
145 |
|
146 |
How does the "early-boot shell script" that you speak of differ from an |
147 |
init-script? |
148 |
|
149 |
> The biggest example I've heard is bluetooth keyboards - that was what |
150 |
> made most of the zealots give up on supporting anything that could |
151 |
> possibly be needed for bootstrapping being in /, as bluetooth has a |
152 |
> bunch of deps and at that point you might as well shove gnome in /bin. |
153 |
|
154 |
If you want to burden your init system with supporting things like |
155 |
BlueTooth, that's your choice. I sure as hell wouldn't do that. |
156 |
|
157 |
> So, for the forseeable future your system probably won't break if |
158 |
> you are using a separate /usr, but if it does the policy has been |
159 |
> established for a long time that nobody is obligated to fix it (nor |
160 |
> are they prohibited from doing so). |
161 |
|
162 |
~chuckle~ |
163 |
|
164 |
> Really, though, you should take the time to appreciate an initramfs |
165 |
> whether you decide to use one or not. |
166 |
|
167 |
You seem to be assuming that people /don't/ appreciate an initramfs / |
168 |
initrd. When for me personally, I do understand and appreciate what an |
169 |
initramfs / initrd does. Enough so that I know that the systems that I |
170 |
run don't /need/ one. |
171 |
|
172 |
> They're a really elegant solution to the problem. |
173 |
|
174 |
I wouldn't use the words "elegant" or "solution". "kludge" comes to mind. |
175 |
|
176 |
> Sometimes I think that half the objection is due to the fact that |
177 |
> they use cpio which is a bit obscure |
178 |
|
179 |
You are free to think that. I'm free to disagree with what you think. |
180 |
|
181 |
> if they were tarballs people would be tearing them apart and playing |
182 |
> with them more. |
183 |
|
184 |
I know many people that have played with them (initramfs and / or |
185 |
initrd). Many of whom have looked at what they do and realized that |
186 |
they don't actually /need/ them to boot their system. So they choose to |
187 |
not use them, thereby reducing unnecessary complexity in the boot process. |
188 |
|
189 |
|
190 |
|
191 |
-- |
192 |
Grant. . . . |
193 |
unix || die |