Author: Alessandro Selli Date: To: dng Subject: Re: [DNG] initramfs?
On 16/11/18 at 21:01, Simon Hobson wrote: > Hendrik Boom <hendrik@???> wrote:
>
>> (1) Is initramfs so weird that only one or two people in the world can make one?
> **AT THE MOMENT** no it isn't. AIUI (and I stand to be corrected) it's simply a CPIO archive that's been (optionally) compressed. So it can be uncompressed, extracted, modified, and rebuilt using standard tools.
> Also ** at the moment** I can't see that changing since the process that needs to extract that archive at boot time isn't under Poettering's control.
>
> As for the future - who knows.
>
> Also, echoing another comment, I can't remember ever having to fiddle with the contents of one as a means of fixing a problem.
>
In theory anybody could make their own custom initramfs. And in
theory you never have to do it. In practice i needed to do it several
times when encrypting the / filesystem became possible, but manually
hacking the initramfs proves it to be a far different beast than just a
cpio archive. The times I did it on a Fedora I always ended up with an
unbootable system and I had to figure out how dracut could be instructed
to produce those changes into the initramfs it was producing. I
remember spending several hours in a string of days to figure out what
was different in the dracut-produced initramfs from the one that I
manualy hacked, and could not. A few days ago I also failed to unpack
an initramfs file from an Ubuntu 18.* installation following the same
steps that were successful on my Devuan:
1) extract the uncompressed part with cpio noting the block number where
it stops;
2) use dd to extract the part of the original initramfs past the last
block cpio could extract;
3) decompress the file produced in step (2) with xz;
4) extract the decompressed cpio archive produced by step (3).
It was another person's PC so I could not spend enough time to find
out why step (2) was producing an uncompressed cpio archive (I was
expecting a compressed file instead) that failed to produce the missing
part of the filesystem. But I was pissed.
>> (2) What is initramfs good for? Linux used to work just fine without it.
> Yes, I remember the days of having to have either a) a huge kernel with everything including the kitchen sink linked in, or b) having to relink the kernel when the hardware changes.
Instead I remember my custom kernels being smaller before initramfs
became very hard - if not impossible - to do without.
[...]
> I can certainly see the use of initramfs : It allows the use of modular kernels
Wrong, modular kernels have been in use from before the initrd was
introduced.
> (so non of this "you've changed something, lets relink" malarky),
The only thing that could impose the reconfiguration and recompilation
of the kernel is the inclusion of a module that is necessary to mount
the / filesystem at boot. I never had to recompile a kernel for this
reason, as all of my desktops and laptops always boot out of the storage
controller that is embedded on the motherboard.
[...]
> As to the original question ...
> I have no strong feelings either way, but as has already been mentioned, once Debian goes merged, then it's inevitable that more and more packages will assume a merged system. The work required to maintain a derived distro keeping separate /usr/bin and /bin etc will keep increasing. Given the limited dev resource available to Devuan, one has to question whether it would be a good investment to maintain the split.
This is like saying that since more and more packages will assume a
systemd system, the work required to maintain a derived distro that
worked without it will keep increasing, and that we should for this
reason give up and just embrace it.
--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE