On 01/05/2016 01:17 AM, Adam Borowski wrote: > On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote: >> Am 04.01.2016 um 19:12 schrieb Eric Valette: >>>> Remember that / and /usr don't have to reside on the same partition with >>>> the usrmerge proposal: they only have to be both available >>>> post-initramfs. The initramfs already takes care to mount /usr (for the >>>> systemd case as initscripts needs updates for sysvinit as was said >>>> elsewhere). So no repartitioning should be required on upgrades. >>> As explained elsewhere in this thread, using initramfs is still not >>> mandatory in debian >> >> an initramfs is not mandatory as long as you don't have /usr on a >> separate partition. >> No initramfs + split /usr is not supported and has been broken for a while. > > I guess you meant "with systemd". It does works with any other init system. It also "works" with systemd (the same as with other init systems), you can just try it in a VM if you like. (Compile your own kernel, change your block device driver + your root filesystem driver from module to compiled-in, have a separate /usr partition and boot an otherwise default Jessie system with systemd - it will boot and mount /usr.) Which binary is run as PID 1 has never been the issue, both sysvinit and systemd support /usr not being mounted at the beginning. The problem is that a lot of other things (that have nothing to do with PID 1) might break (and even do, examples have been provided in this thread) - and the _only_ reason you associate that with systemd is that systemd developers chose to add a warning to systemd 5 years ago in order to put people on the right track if they experience some really weird problems in their systems (because breakage due to this can be *very* subtle). It's not supported in systemd only in the sense that the developers really don't want to have to spend time helping people debug problems with other software that in the end turn out to be because /usr wasn't available early enough. All this has been explained in this thread multiple times. Regards, Christian
Attachment:
signature.asc
Description: OpenPGP digital signature