[systemd-devel] moving from SysV to systemd - issue with / being ro
Warpme
warpme at o2.pl
Thu Oct 17 12:25:48 PDT 2013
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
More information about the systemd-devel
mailing list