I just noticed that on SLES 11 SP1 if you run dracut -f one of the last things 
it says is 
Stored kernel commandline:
and it includes
rd.lvm.lv=system/usr

(system is our VG name)

SLES 12 SP2 does not include that.

So yea, it would be good to get SUSE's opinion.   Is this intentional or a bug?

Marcy
-----Original Message-----
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Friday, December 16, 2016 1:47 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] systemd Failed unmounting /usr

It's an interesting article. Indeed I have seen some other dependencies that do 
not work well without /usr mounted during boot. For instance in SLES10/SLES11 
the /etc/init.d/boot.rootfsck (or rather /sbin/chkconfig) depends on 
/usr/bin/perl but with a separate /usr this is not available at that point. The 
/usr is to be mounted only after the root filesystemcheck.

But I do wonder, there are a lot of shops that use a separate partition for 
/usr so I would expect to have seen more about this. In our linux group they 
use the separate /usr setup and we have to take their defaults. In fact, their 
default setup has been changed recently so I would have expected them to change 
this setup if that would have been identified as a problem.

The page at freedesktop refers mostly to Fedora. It also links to another page 
(https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/) that 
talks about moving /bin and /sbin into the /usr/* counterparts, once again 
referring to Fedora.

Also these pages mention that having /usr on a separate partition is still 
supported. But is it? The point I have seen is that initramfs should mount /usr 
during early boot but it looks like it's not working correctly as an attempt is 
made to umount it by systemd.

@Mark Post, What is the position of Suse in this matter? Is Suse also working 
towards moving the /bin and /sbin to /usr/*?


Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen

-----Original Message-----
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Viktor 
Mihajlovski
Sent: Thursday, December 15, 2016 1:55 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: systemd Failed unmounting /usr


Oh yes ... a similar issue has bitten me a few years ago when I was trying to 
configure the systemd service for the UPS for my server box at home.

Anyway, with systemd you are actually discouraged from maintaining a separate 
/usr filesystem, details here:
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

In a nutshell: I have given up and keep /usr in my root filesystem now.
Been a happy systemd camper ever since.

--

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: 
Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit http://wiki.linuxvm.org/ This 
e-mail and the documents attached are confidential and intended solely for the 
addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

Reply via email to