On 10/17/13 7:59 PM, Colin Guthrie wrote:
'Twas brillig, and Warpme at 17/10/13 18:15 did gyre and gimble:
On 10/17/13 4:27 PM, Colin Guthrie wrote:
Perhaps a dumb question but are you 100% certain that
systemd-remount-fs.service has been run? I've not seen any debug about
it so far on this thread:
systemctl status systemd-remount-fs.service
Console reports "Starting Remount Root and Kernel Filesystems..."
This is the important one
and next (after some other entries) "Started Root and Kernel
Filesystems..."
This one seems different but I guess you maybe just missed the word
"Remount" in the retyping?
Looking on systemctl status systemd-remount-fs.service reports:
Loaded: loaded
Active: active (exited) (with green color)
Exit code=0/SUCCESS
For me this unit looks like started, executed and exited OK.
Yup, that looks good.
FWIW, all it does is run a little utility shipped with systemd that
finds / and /usr in /etc/fstab and attempts to remount them.
The utility binary is [/usr]/lib/systemd/systemd-remount-fs
It seems that it ran and exited with 0 which is successful, but I cannot
see how it could do that unless it had trouble parsing the fstab and
just couldn't spot / or /usr.
My general logic is following:
-let assume initrd script leaves / with mode we are not sure (ro or rw)
-with SysV I don't have anywhere else remount command for / to rw
OK, this did used to be done in (IIRC) rc.sysinit via initscripts
package, but as you say it's not there, I'll take your word for it.
- so
backward logic says script provides / with rw
-now I'm changing last line in script from /sbin/init to
/usr/lib/systemd/systemd (script body is in OP of this thread)
-I'm receiving / with ro mode. So logic says that
/usr/lib/systemd/systemd process changes mode of / from rw to ro
I can see why you get to this conclusion, but I'd be cautious of
assuming this is how things work!
Is there way to tell to systemd not mount/remout / (ideally not touch /
at all) ?
Technically it you can just mask the systemd-remount-fs.service which
will avoid the remounts, but, if I'm honest, I suspect something in your
sysvinit setup *is* doing the remount for you somehow.
Here's what I would suggest:
1. Boot and get a shell where / is ro (i.e. the error state)
2. Run the [/usr]/lib/systemd/systemd-remount-fs manually and see if it
corrects the mount problem.
3. If 2) does NOT solve the problem, run: "/bin/mount / -o remount"
(including the full path). This is all that the above utility does
internally, so if this fails on it's own, then running it via the
utility cannot fix it.
If 3 works but 2 didn't, then the only way I can see it not doing it's
job, but still exiting successfully, is if it fails to properly parse
your fstab.
Here is the source:
http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c
Even if you are not too familiar with c, it should be easy to follow.
HTHs
Col
Col,
Many thx for replay.
It looks like we are moving forward:
2 works.
3 always worked.
So now Q is why manual launching /usr/lib/systemd/systemd-remount-fs
works, and unit with this exec launched by systemd not.
Restarting unit via systemctl restart also fixes problem.
So summarizing:
1.systemd-remount-fs.service status from boot sequence is OK - but / is ro
2.starting /usr/lib/systemd/systemd-remount-fs switches / to rw
3.systemctl restart systemd-remount-fs.service switches / to rw
Console output from 1 & 3 is the same.
So it looks like:
a\ /usr/lib/systemd/systemd-remount-fs from 1 is not doing its job, or
b\ /usr/lib/systemd/systemd-remount-fs is doing its job but later /
somehow is switched back to ro.
Maybe issue is within my fstab?
It has:
none / auto remount,rw 0 0
br
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
