'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/ _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
