On Wed, Jul 17, 2019 at 01:45:21PM +0000, Witold Baryluk wrote: > Hey John, > > > The gist is: A lot of projects don't test their code on systems with > separate > > /usr partitions anymore, so things get silently broken. > > I don't have separate /usr, just single / (ext4) partition, and just > separate /boot (ext2), and still systemd fails to mount this /boot file > system, similar to Michael issue. So, I dont think it is really related to > separate /usr vs non separate /usr. > > PS. On my amd64 system with systemd, I do have separate /usr, and it does > work.
Recall my original statement of the issue. Separate "/usr" is ok. Other persistent filesystems, say, "/boot", do *not* work. This is consistent with what the rest of us are seeing who have run into this problem with "systemd". I agree with the assertion/speculation that what we're seeing shouldn't be unique to Alpha, and I don't think it is. The "everything on /" default partitioning scheme is sensible for people new to UN*X who simply want to get Linux up and running as quickly and easily as possible. For people with a little bit of experience and a sense of historical perspective, separate persistent filesystems are the way to go. Most of the "heavy" disk I/O is associated with directories like "/tmp" and "/var", not to mention swap partitions. "/tmp" is non- persistent in modern distros, so we'll ignore it for now. On the other hand, "/var" sees quite a bit of disk I/O (software updates, spooling, e-mail, etc.), and it makes sense for "/var" to be on a separate partition so that *when* a crash occurs, the resulting filesystem corruption won't affect "/". Other persistent filesystems are a matter of individual taste/preference, but in general, the idea is to distinguish between those parts of the directory hierarchy that are relatively stable vs. those that are likely to see a lot of writing. Modern filesystems aren't as likely to be unrecoverable after a crash, so we can get away with a monolithic "everything on /" philosophy. That wasn't always the case, and old fossils like me that got burned decades ago haven't forgotten the lessons that were learned the hard way :-(. Another consideration is that disks used to be much smaller, and multiple persistent partitions were pretty much a forced choice, i.e., you couldn't put everything on a single spindle, and there was no way to construct a large logical volume out of multiple smaller physical ones as we can do today. The standard hard disks available for a DEC PWS when that system first hit the market would certainly have required either separate persistent filesystems or logical volume capability to be useful. At the time I first installed Linux on an Alpha, I think only RedHat was using LVM by default (although they no longer supported Alpha at that point), and I can't remember whether anyone else's installer even offered it as an option. In summary, I guess I'm saying there are valid reasons in 2019 for having multiple persistent fiiesystems, even with large physical disks and the ability to create large logical volumes out of multiple smaller ones. --Bob