FS#43915 - [systemd] 219 breaks nfs mounting at boot

Attached to Project: Arch Linux
Opened by Andreas Radke (AndyRTR) - Sunday, 22 February 2015, 22:02 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 22 March 2015, 15:08 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Tobias Powalowski (tpowa)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

I can't get my systems to mount my nfsv4 share at initial boot. I can mount it manually without any trouble. rpcbind and nfs-client are running. I'm using netctl on my systems. journal doesn't show any useful error. I assume some change timing or dependency issue here. Downgrading to systemd 218 makes it mount well again.

Any idea? Can somebody confirm this?
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 22 March 2015, 15:08 GMT
Reason for closing:  Not a bug
Additional comments about closing:  remote-fs.target needs to be enabled if you want remote FS support at bootup. This will be re-enabled in a future package.
Comment by Andreas Radke (AndyRTR) - Sunday, 22 February 2015, 22:09 GMT
logfile with systemd 219:
   logfile (97.4 KiB)
Comment by Dave Reisner (falconindy) - Sunday, 22 February 2015, 22:09 GMT
Debug logs? What state is the share's mount unit in when this happens?
Comment by Tobias Powalowski (tpowa) - Monday, 23 February 2015, 06:02 GMT
Are you using x-systemd.automount, this is broken for me too with 219.
Comment by Andreas Radke (AndyRTR) - Monday, 23 February 2015, 15:55 GMT
debug log non-smp with systemd 219:
   logfile (762.9 KiB)
Comment by Manfred Miederer (LessWire) - Thursday, 26 February 2015, 03:13 GMT
For me it's broken too since 219, but i use sshfs (x-systemd.automount,_netdev in fstab).
Comment by Heinrich Siebmanns (Harvey) - Thursday, 26 February 2015, 08:03 GMT
It's broken with or without x-systemd.automount and the filesysstem to be mounted does not matter anyway.
Comment by Andreas Radke (AndyRTR) - Friday, 27 February 2015, 19:06 GMT
reported upstream: https://bugs.freedesktop.org/show_bug.cgi?id=89365
Comment by Zachary Cook (Zeik) - Monday, 16 March 2015, 07:06 GMT
This looks to be an Arch specific issue, since the PKGBUILD/.install doesn't enable remote-fs.target by default as of 219-1

I think the "Arch Way" solution here is to get rid of all the hackery in the PKGBUILD and .install file that remove these sensible defaults and use upstream's /usr/lib/systemd/system-preset/90-systemd.preset file instead.
Comment by Tobias Powalowski (tpowa) - Monday, 16 March 2015, 07:15 GMT
Confirmed enabling remote-fs.target makes it work again.
Comment by Dave Reisner (falconindy) - Monday, 16 March 2015, 13:39 GMT
> I think the "Arch Way" solution here is to get rid of all the hackery in the PKGBUILD [...]
You've got it quite backwards. Removing this "hackery" means that we forcibly enable a bunch of things at boot which people may or may not want (and this will happen again on every upgrade). Removing the symlinks gives the power back to the admin to make the choice as to what they want to. 90-systemd.preset enables far more than I want to provide as a default.
Comment by Andreas Radke (AndyRTR) - Monday, 16 March 2015, 14:51 GMT
Ok, confirmed. Admin needs to enable remote-fs.target as of v219.

Should we post a .install msg about such a change or even a news item? We will need to add a note to all related wiki pages for remote filesystems.
Comment by Dave Reisner (falconindy) - Monday, 16 March 2015, 14:59 GMT
Seems unnecessary -- we can enable on post_upgrade to 219-x and on post_install.

Loading...