[systemd-devel] moving from SysV to systemd - issue with / being ro

[Colin Guthrie]

'Twas brillig, and Warpme at 17/10/13 20:25 did gyre and gimble:
> 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

IMO, it shouldn't have remount as the option here. I think this is only
something that should be given on the command line.

That said, as the tool worked properly, it would seem that *something*
is re-re-mounting it ro again *after* the systemd tool runs... or for
some reason, /etc/fstab is non-existent (or empty) when the systemd tool
is run at boot. I doubt this is the case, but maybe.

As the tool has various log_debug() calls in it, if you boot with
systemd.log_level=debug, I believe you should see those messages in your
log. If you don't see them, but do see them when you manually run the
tool later, then this points to a problem with the /etc/fstab during
early boot.

HTHs

col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/