On 16/11/18 at 21:01, Simon Hobson wrote: > Hendrik Boom <hend...@topoi.pooq.com> 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 <alessandrose...@linux.com> VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng