Install hangs during UCS configuration

[Grandjean]

Hello @cbservices,

@cbservices

The 4.1 to 4.2 upgrade also worked flawlessly

I’m glad to hear that

@cbservices

So, a couple of suggestions:

1. Remove the option to mount a filesystem at /usr when doing manual partitioning, since this isn’t supported, anyway.

Thanks for your feedback (and for your patience with the UCS 4.2 installation)
I added this to our issue tracker, because I think you are right.
If you are interested, here is the original issue regarding a separate /usr. We already removed /usr from the auto-partition schemes and we detect and block the upgrade from UCS 4.1 if /usr is split from the root partition. Of course it’s always arguable where to draw the line between restricting choices and giving people the possibility to shoot themselves in the foot.

@cbservices

Figure out why the package installation prompts are (sometimes?) waiting silently in the background, so the installation appears to hang.

I tried to reproduce this, even with a separate /usr but had no prompts waiting in dpkg or apt logs . Be assured, that we do a lot of installation tests with all kinds of setups and as far as I know, the installation prompts didn’t occur then. Can you provide the relevant log files (if you still have them)? That would help a lot. Also the exact partitioning scheme, so we are able to come as close to your setup as possible.

@cbservices

systemd is shit.

I think we can agree to disagree Imho there are good reasons to replace the aging sysvinit with a modern init system that has its advantages. And yes, systemd does a lot of things differently and that can be annoying - but that’s nothing bad per se. And to be honest, UCS is one of the last Linux distributions to actually make the switch.
I think there are valid points one can criticize about systemd, just as with every piece of software. The main problem I have with most anti-systemd arguments is that they often boil down to ad hominem attacks against the core developers.

@cbservices

Also, as an aside, the issue with the separate /usr that’s not supported by systemd, doesn’t make sense to me. The systemd documentation states that it does, in fact, work fine with a separate /usr partition, so why does your implementation fail so completely when it’s set up this way?
Just curious, more than anything.

Yeah, it’s a bit complicated. I guess you are referring to Booting Without /usr is Broken written by the systemd people. There they state:

systemd itself is actually completely fine with /usr on a separate file system that is not pre-mounted at boot time. However, the common basic set of OS components of modern Linux machines is not

The important part is: systemd itself is fine, but a lot of Linux components just don’t work if /usr is not mounted before the main boot process. That’s a pity, grown historically, but the current state. Because of this, systemd just doesn’t mount /usr itself, as the article explains:

we now just expect /usr to be pre-mounted from inside the initramfs, to be available before ‘init’ starts

So the solution would be to mount /usr before systemd kicks in, in the so called early user space stage or initramfs. Unfortunately, Debian’s initramfs-tools can’t do this, currently. There has been some work on this, but as far as I can see this is not finished. It would also be possible to run systemd already in initramfs, but that is not implemented either. Another possibility is to use another initramfs, e.g. dracut, that seems to support mounting /usr in early user space - however that would require to also replace the initramfs during upgrade from UCS 4.1 to 4.2 and we would move away from Debian defaults.
As you can see, there are different possibilities, some with unknown consequences. UCS has chosen the one that seems to be the least risky for the majority of users.

Best regards,
Michael Grandjean