You are not logged in.
Pages: 1
Hello,
I have some trouble with a diskless workstation that tries to run with debian/testing. In this configuration, systemd doesn't work as expected and it often kills X without reason. This morning, apt upgrade tries to install usrmerge and I don't want to merge / and /usr. Is it possible to run devuan without merging / and /usr ?
Best regards,
JB
Offline
Yes, it's still possible to run without usrmerge in devuan. If you use one of our installer isos, you will be asked whether you want it or not. Default is not.
Offline
Kudos to the developers for forking the init-system-helpers package. Great work. Thank you!
Brianna Ghey — Rest In Power
Offline
Yes, it's still possible to run without usrmerge in devuan. If you use one of our installer isos, you will be asked whether you want it or not. Default is not.
Thanks for your answer. And in a predictable future ?
Regards,
JB
Offline
And in a predictable future?
Debian will work out all the bugs and everything will be fine. Just like always.
(Sorry, I couldn't resist. Any other answer would have turned NSFW.)
Offline
And in a predictable future?
Debian will work out all the bugs and everything will be fine. Just like always.
I don't understand usrmerge (and I don't like it) and I prefer to keep / and /usr on different partitions (with / in read only). / should contain all program required to boot a minimal and usable system. usrmerge prohibits this configuration and in embedded systems, a root partition in read only is mandatory (to restart a device even if /usr is totally broken after, for example, a power outage). That being said, in embedded systems, we wait for a rescue directory (like /rescue in NetBSD world) where all critical programs are statically linked.
In diskless configuration (my workstation is in nfsroot), usrmerge also leads to multiply nfs request. I have tried, a diskless workstation with usrmerge is slower that the same workstation without usrmerge.
In both cases, merging / and /usr is a very bad idea. For me, usrmerge and systemd are the exactly the same nonsense.
Offline
/ should contain all program required to boot a minimal and usable system
That recommendation stems from a time when disk size was measured in MiB. The restriction makes no sense in a modern system.
Standards bureaucracies like the Linux Foundation (which consumed the Free
Standards Group in its' ever-growing accretion disk years ago) happily
document and add to this sort of complexity without ever trying to understand
why it was there in the first place. 'Ken and Dennis leaked their OS into the
equivalent of home because an RK05 disk pack on the PDP-11 was too small" goes
whoosh over their heads.
Brianna Ghey — Rest In Power
Offline
JBert wrote:/ should contain all program required to boot a minimal and usable system
That recommendation stems from a time when disk size was measured in MiB. The restriction makes no sense in a modern system.
Nope.
Keep / in read only (and /usr in read/write) is not related to disk size.
Offline
For those who are interested in the greybeard history of why "bin" was split between "/bin" and "/usr/bin" :
http://lists.busybox.net/pipermail/busy … 74114.html
--K
Offline
Is there an echo in here?
Brianna Ghey — Rest In Power
Offline
Hello,
yes, there is... kaiyel points to good an accurate information.
In today's times, the disks are big enough to hold most of a filesystem. But:
If you intend to separate just the /home filesystems to its own partition, do it by all means, that's a very good reason.
But, if, out of old (and good) habits you want to keep /usr separate, you have to be sure you can access enough system- and filesystem-repair binaries in the root filesystem in case of severe filesystem problems that prevent automatic mounting these other filesystems.
Therefore things like mount, fsck, ps etc have to be kept in the /bin or /sbin directory (which is in the root filesystem).
In old SysV times I have encountered funny constructions like the basic OS tools kept in the rootfilesystem/usr directory, and /usr was used as mountpoint for it's separate filesystem. If the mount is successful at boot, you have all the tools. If not, you could still try to repair with whatever tools are kept beneath the mountpoint /usr.
I know, it sounds boring these days, but it had its reasons not too long ago.
Good day to all.
Last edited by Andre4freedom (2022-09-30 08:43:44)
Offline
Pages: 1