On Sep 03, Serge <sergem...@gmail.com> wrote: > * ability to easily edit content of root partition and put some additional > software to mount /usr Can you show some actual real life examples?
> (much easier than making changes to initramfs) And anyway, adding programs to the initramfs is as trivial as dropping an hook script in /etc/initramfs-tools/, so this is a very weak argument. > * ability to boot with separate /usr without initramfs (people still use that) Just because somebody does it it does not mean that it is worth supporting. > * recover from epic disaster > > (https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac) > * log in locally as root and check/fix things having non-mountable usr You can do this as well from the initramfs or an on-disk recovery image like the one installed by the grml-rescueboot package. > * larger initramfs adds problems for embedded systems Please provide some actual data which shows how this would be a problem and on which embedded systems. > * update of binaries in root partition does not update binaries in initramfs Nothing new here. > Yes, that's what I'm talking about. It was not solved before, and it's still > not solved. New initramfs approach solves nothing. It just turns one problem > into another one, requires additional work and adds slots for new bugs. You got it backwards: mounting /usr in the initramfs actually fixes the problems with a standalone /usr, and the work needed is minimal because we can reuse the code which is available to mount /. > You can't be sure about that. It could be that on some system the stuff needed > to mount /usr was on /srv partition. And it worked because /srv was put before > /usr in /etc/fstab. In "historical approach" it works, but not in > "initramfs approach". Please show some real world examples of such a configuration. -- ciao, Marco
signature.asc
Description: Digital signature
