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


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to