On 14.12.2016 16:31, van Sleeuwen, Berry wrote:
> Hi All,
> 
> I have installed a new SLES12 SP2 guest. The root partition is on one 
> partition (/dev/dasda1). The remaining system directories are stored within 
> an lvm, rootvg. This lvm contains logical volumes for /usr, /opt, /home, /tmp 
> and /var.
> 
> During boot, when systemd is started it tries to umount /usr. After a couple 
> of tries umount ends. But I did have one occasion where the umount apparently 
> succeeded as the guest came up in emergency mode, without /usr mounted.
> 
> 2016-12-14T15:54:41.052380+01:00 SLES12 systemd[1]: systemd 228 running in 
> system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP 
> +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD 
> -IDN)
> 2016-12-14T15:54:41.052387+01:00 SLES12 systemd[1]: Detected virtualization 
> zvm.
> 2016-12-14T15:54:41.052389+01:00 SLES12 systemd[1]: Detected architecture 
> s390x.
> 2016-12-14T15:54:41.052391+01:00 SLES12 systemd[1]: Set hostname to <SLES12>.
> 2016-12-14T15:54:41.052394+01:00 SLES12 systemd[1]: nss-lookup.target: 
> Dependency Before=nss-lookup.target dropped
> 2016-12-14T15:54:41.052396+01:00 SLES12 systemd-modules-load[784]: Inserted 
> module 'ecryptfs'
> 2016-12-14T15:54:41.052398+01:00 SLES12 umount[774]: umount: /usr: target is 
> busy
> 2016-12-14T15:54:41.052401+01:00 SLES12 umount[774]: (In some cases useful 
> info about processes that
> 2016-12-14T15:54:41.052403+01:00 SLES12 umount[774]: use the device is found 
> by lsof(8) or fuser(1).)
> … <snip> …
> 2016-12-14T15:54:41.052446+01:00 SLES12 umount[836]: umount: /usr: target is 
> busy
> 2016-12-14T15:54:41.052448+01:00 SLES12 umount[836]: (In some cases useful 
> info about processes that
> 2016-12-14T15:54:41.052450+01:00 SLES12 umount[836]: use the device is found 
> by lsof(8) or fuser(1).)
> 2016-12-14T15:54:41.052453+01:00 SLES12 systemd[1]: usr.mount: Mount process 
> exited, code=exited status=32
> 2016-12-14T15:54:41.052462+01:00 SLES12 systemd[1]: Failed unmounting /usr.
> 2016-12-14T15:54:41.052464+01:00 SLES12 systemd[1]: usr.mount: Unit is bound 
> to inactive unit dev-mapper-rootvg\x2dusrlv.device. Stopping, too.
> 2016-12-14T15:54:41.052466+01:00 SLES12 systemd[1]: Unmounting /usr...
> … <snip> …
> 2016-12-14T15:54:41.052625+01:00 SLES12 systemd-udevd[855]: Network interface 
> NamePolicy= disabled by default.
> 2016-12-14T15:54:41.052628+01:00 SLES12 umount[864]: umount: /usr: target is 
> busy
> 2016-12-14T15:54:41.052630+01:00 SLES12 umount[864]: (In some cases useful 
> info about processes that
> 2016-12-14T15:54:41.052632+01:00 SLES12 umount[864]: use the device is found 
> by lsof(8) or fuser(1).)
> 2016-12-14T15:54:41.052634+01:00 SLES12 systemd[1]: usr.mount: Mount process 
> exited, code=exited status=32
> 2016-12-14T15:54:41.052636+01:00 SLES12 systemd[1]: Failed unmounting /usr.
> 2016-12-14T15:54:41.052638+01:00 SLES12 systemd[1]: usr.mount: Unit is bound 
> to inactive unit dev-mapper-rootvg\x2dusrlv.device, but not stopping since we 
> tried this too often recently.
> 2016-12-14T15:54:41.052640+01:00 SLES12 systemd[1]: Stopped File System Check 
> on /dev/rootvg/usrlv.
> 2016-12-14T15:54:41.052643+01:00 SLES12 systemd[1]: Reached target Local File 
> Systems (Pre).
> … Boot continues with starting services etc.
> 
> Why does the startup produce these errors? And how can it be resolved?
> 
> Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
> Berry van Sleeuwen
> Flight Forum 3000 5657 EW Eindhoven
> • +31 (0)6 22564276
>  [cid:image001.jpg@01CE3508.E10AE080]                
> [cid:image002.jpg@01CE3508.E10AE080]
> 
> 
> 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.
> 

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/

Reply via email to