[opensuse] systemd and /etc/fstab
on Leap 42.3: If I make a change to /etc/fstab so that, for example, I make an item be automounted by systemd, how can I get systemd to re-read this file without rebooting? I have added the following to an entry, and would like to see that the item gets mounted when accessed. noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail I expected something like: systemctl restart automount or systemctl restart mount But this seems not to work. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
on Leap 42.3:
If I make a change to /etc/fstab so that, for example, I make an item be automounted by systemd, how can I get systemd to re-read this file without rebooting?
I suspect: systemctl daemon-reload -- Per Jessen, Zürich (23.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/08/17 07:04 AM, Per Jessen wrote:
Roger Oberholtzer wrote:
on Leap 42.3:
If I make a change to /etc/fstab so that, for example, I make an item be automounted by systemd, how can I get systemd to re-read this file without rebooting?
I suspect: systemctl daemon-reload
Indeed, that is a literally correct to the grammatical way the question was phrased. Yes that will cause the various con figs to be re-read. I rather suspects, though, that Roger would be interested in having the changes to /etc fstab acted upon as well. Isn't English a wonderful language? I would follow the 'reload' with a 'reexec' <Sidebar> There are any number of stories about the Genie of the Lamp, or the Devil, granting the three wishes, very literally, what was asked for not what was actually meant. However I read a few years ago about one that involved a lawyer, and the lawyer did in fact get the better of the Genie. </sidebar> -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 16/08/17 07:04 AM, Per Jessen wrote:
Roger Oberholtzer wrote:
on Leap 42.3:
If I make a change to /etc/fstab so that, for example, I make an item be automounted by systemd, how can I get systemd to re-read this file without rebooting?
I suspect: systemctl daemon-reload
Indeed, that is a literally correct to the grammatical way the question was phrased. Yes that will cause the various con figs to be re-read.
I rather suspects, though, that Roger would be interested in having the changes to /etc fstab acted upon as well.
Anton, he did say "... would like to see that the item gets mounted when accessed" - so after reloading, accessing the mount point should cause it to be mounted, per fstab. /Per -- Per Jessen, Zürich (26.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/08/17 10:45 AM, Per Jessen wrote:
Anton Aylward wrote:
On 16/08/17 07:04 AM, Per Jessen wrote:
Roger Oberholtzer wrote:
on Leap 42.3:
If I make a change to /etc/fstab so that, for example, I make an item be automounted by systemd, how can I get systemd to re-read this file without rebooting?
I suspect: systemctl daemon-reload
Indeed, that is a literally correct to the grammatical way the question was phrased. Yes that will cause the various con figs to be re-read.
I rather suspects, though, that Roger would be interested in having the changes to /etc fstab acted upon as well.
Anton, he did say "... would like to see that the item gets mounted when accessed" - so after reloading, accessing the mount point should cause it to be mounted, per fstab.
My experience was with 13.2 systemd; I don't automount any more, so maybe this is out of date. But systemd doesn't read and act on /etc/fstab. What it does do when it execs is run a generator program. This generator file then produces unit files, one per line of the fstab file. Then the mount function is applied to each of those files. Merely re-reading fstab isn't enough, the generator has to run and the dot-mount unit files have to be generated again and the mount program run on each, perhaps idempotentently, and the auto-mount function has to be restarted to take not of the new unit file. That's why the reexec. Have things changed so that a reread cascades to the required reexec of the generator and a rerun of the mount? I've only progressed as far as 42.2 and haven't used auto mount for some while and really don't have to set up 42.3 & automount just to see of a reload triggers the generator by putting a watch-for-change on the appropriate temporary unit files and so on down the line. Or perhaps it is all vocal enough in the log file to report all this. But lets face it, a systemctl reload; systemctl reexec isn't exactly going to cripple you give you time to brew a new pot of coffee, visit the washroom, chat up the receptionist and still find it waiting for completion. http://www.jokelibrary.net/occupations/pilot.html#pilots_show-off -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 16/08/17 10:45 AM, Per Jessen wrote:
Anton Aylward wrote:
On 16/08/17 07:04 AM, Per Jessen wrote:
Roger Oberholtzer wrote:
on Leap 42.3:
If I make a change to /etc/fstab so that, for example, I make an item be automounted by systemd, how can I get systemd to re-read this file without rebooting?
I suspect: systemctl daemon-reload
Indeed, that is a literally correct to the grammatical way the question was phrased. Yes that will cause the various con figs to be re-read.
I rather suspects, though, that Roger would be interested in having the changes to /etc fstab acted upon as well.
Anton, he did say "... would like to see that the item gets mounted when accessed" - so after reloading, accessing the mount point should cause it to be mounted, per fstab.
My experience was with 13.2 systemd; I don't automount any more, so maybe this is out of date.
But systemd doesn't read and act on /etc/fstab.
What it does do when it execs is run a generator program. This generator file then produces unit files, one per line of the fstab file.
Right. Which is supposed to happen when you run daemon-reload.
Then the mount function is applied to each of those files.
When the mount points are accessed.
Merely re-reading fstab isn't enough, the generator has to run and the dot-mount unit files have to be generated again
Right. daemon-reload should be sufficient I believe. https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.htm... "systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded." -- Per Jessen, Zürich (26.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Right. daemon-reload should be sufficient I believe.
https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.htm...
"systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded."
I tried this on leap42.3 - added the following to fstab: /tmp/anton.iso /tmp/anton iso9660 loop,noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail 0 0 Then I ran 'systemctl daemon-reload' # systemctl | grep automount proc-sys-fs-binfmt_misc.automount Then I ran 'systemctl daemon-reexec' # systemctl | grep automount proc-sys-fs-binfmt_misc.automount Remarkably, it took a reboot: # systemctl | grep automou proc-sys-fs-binfmt_misc.automount tmp-anton.automount -- Per Jessen, Zürich (25.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/08/17 12:36 PM, Per Jessen wrote:
Per Jessen wrote:
Right. daemon-reload should be sufficient I believe.
https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.htm...
"systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded."
I tried this on leap42.3 - added the following to fstab:
/tmp/anton.iso /tmp/anton iso9660 loop,noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail 0 0
Then I ran 'systemctl daemon-reload'
At that point there should have been a new dot-mount file come into existence under /run/systemd/generator You could run a before and after find listing to see if that happened. To my mind that is the most meaningful test to see if the generator ran. Secondly, there is a much more basic test you could have run as a precursor. Create new STATIC mount. If after running just reload files under that mount point are now available, then not only did the the generator run, but the mechanism that mounts the unit files (see a raw 'systemctl' listing) was run on it also did. That is a simple to test to see if the basic mounting mechanism reexec'd and was applied without running a 'systemctl reexec'. In the list of what subsequently happened that is an import test along the way.
# systemctl | grep automount proc-sys-fs-binfmt_misc.automount
Unfortunately that is not meaningful information. It was running before, it was running afterwards. You do not know if it is the same instance or a newly exec'd instance. You weren't running it with extra debugging or logging to see what it actually did. You don't know that it read the new config files. I don't see on the man8 page that there's a SIGCHLD option for force a re-read of the maps.
Then I ran 'systemctl daemon-reexec'
# systemctl | grep automount proc-sys-fs-binfmt_misc.automount
Remarkably, it took a reboot:
# systemctl | grep automou proc-sys-fs-binfmt_misc.automount tmp-anton.automount
The best I can figure is that neither reload no reexec actually ends up restarting the automounter. Since, as I say, there doesn't seem to be a SIGCHLD to force a reread at the deamon, its going to take the restart. You might have tried "systemctl stop autofs; systemctl start autofs" I think that's right. Hmmm When I look at /usr/lib/systemd/system/autofs.service I see the line ExecReload=/usr/bin/kill -HUP $MAINPID Oh! I missed that in the man8 page. MY BAD! So there you have another option systemctl reload autofs -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 16/08/17 12:36 PM, Per Jessen wrote:
Per Jessen wrote:
Right. daemon-reload should be sufficient I believe.
https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.htm...
"systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded."
I tried this on leap42.3 - added the following to fstab:
/tmp/anton.iso /tmp/anton iso9660 loop,noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail 0 0
Then I ran 'systemctl daemon-reload'
At that point there should have been a new dot-mount file come into existence under /run/systemd/generator
I agree and it should have been listed by systemctl.
You could run a before and after find listing to see if that happened. To my mind that is the most meaningful test to see if the generator ran.
Running 'systemctl' should suffice to list known items.
Secondly, there is a much more basic test you could have run as a precursor. Create new STATIC mount.
Adding one line to fstab was pretty basic I thought. :-)
# systemctl | grep automount proc-sys-fs-binfmt_misc.automount
Unfortunately that is not meaningful information.
It seems pretty meaningful that 'tmp-anton.automount' isn't listed, contrary to expectations.
It was running before, it was running afterwards. You do not know if it is the same instance or a newly exec'd instance. You weren't running it with extra debugging or logging to see what it actually did. You don't know that it read the new config files.
Main thing - I know that what I intended was not achieved.
Then I ran 'systemctl daemon-reexec'
# systemctl | grep automount proc-sys-fs-binfmt_misc.automount
Remarkably, it took a reboot:
# systemctl | grep automou proc-sys-fs-binfmt_misc.automount tmp-anton.automount
The best I can figure is that neither reload no reexec actually ends up restarting the automounter.
Perhaps, but why wasn't systemd-fstab-generator rerun with the 'daemon-reload'? -- Per Jessen, Zürich (24.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/08/17 01:44 PM, Per Jessen wrote:
At that point there should have been a new dot-mount file come into existence under /run/systemd/generator
I agree and it should have been listed by systemctl.
I think you are incorrect. It could have been created under /run/systemd/generator/ and that's all. You are only going to see a report with systemctl if systemctl knows about it. Now why should it know about it unless it has something running against it?? you are thinking of systemctl as a kind of super 'ls'. Perhaps, but only of the active units. If the unit isn't active then it won't appear. The whole issue we are dealing with is that for some reason the new unit, for /tmp/anton.iso never did have something running against it. Systemctl raw listings are of things that are, or have been, running.
You could run a before and after find listing to see if that happened. To my mind that is the most meaningful test to see if the generator ran.
Running 'systemctl' should suffice to list known items.
Known to be what? lookit, I'm sure that when testing the developers ran the fstab/generator just like that, just to produce the dot-mount unit files and check that they were what they expected them to be AND NOTHING ELSE. No exec of the mount program on each and everyone one of them. There's nothing magical about the generator. It's just a generator. I don't understand your resistance to the alternative approach I've suggested. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 16/08/17 01:44 PM, Per Jessen wrote:
At that point there should have been a new dot-mount file come into existence under /run/systemd/generator
I agree and it should have been listed by systemctl.
I think you are incorrect. It could have been created under /run/systemd/generator/ and that's all. You are only going to see a report with systemctl if systemctl knows about it. Now why should it know about it unless it has something running against it??
Because I ran a daemon-reload, surely. Whether I create a unit manually or a generator does it, after a daemon-reload, systemd should know about it. When I create a service called "anton.service" and do a 'systemctl daemon-reload', systemd will know about it. That's the whole idea.
The whole issue we are dealing with is that for some reason the new unit, for /tmp/anton.iso never did have something running against it. Systemctl raw listings are of things that are, or have been, running.
See my previous posting - I neglected to add '--all'. -- Per Jessen, Zürich (23.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/08/17 01:44 PM, Per Jessen wrote:
Secondly, there is a much more basic test you could have run as a precursor. Create new STATIC mount.
Adding one line to fstab was pretty basic I thought. :-)
I'm glad you put the smiley there. There's basic and there BASIC. A simple static mount is more BASIC than a multi-step approach using an an autormounter and indirection and load on demand is basic. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/08/17 01:44 PM, Per Jessen wrote:
Perhaps, but why wasn't systemd-fstab-generator rerun with the 'daemon-reload'?
You didn't test for it. As I said, you didn't see if there was a new unit file under /run/systemd/generator That is what the generator produces. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Anton Aylward wrote:
On 16/08/17 12:36 PM, Per Jessen wrote:
Per Jessen wrote:
Right. daemon-reload should be sufficient I believe.
https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.htm...
"systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded."
I tried this on leap42.3 - added the following to fstab:
/tmp/anton.iso /tmp/anton iso9660 loop,noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail 0 0
Then I ran 'systemctl daemon-reload'
At that point there should have been a new dot-mount file come into existence under /run/systemd/generator
I agree and it should have been listed by systemctl.
Mea culpa - forgot to add '--all', i.e. 'systemctl --all'. With that, the newly generated unit is listed as expected. All sorted. -- Per Jessen, Zürich (22.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
The best I can figure is that neither reload no reexec actually ends up restarting the automounter.
I don't believe the systemd auto-mount scheme needs a running task. I would expect systemd to run inotify() on the applicable mount points and kick off the (generated) units when a mount is needed.
Since, as I say, there doesn't seem to be a SIGCHLD to force a reread at the deamon, its going to take the restart.
You might have tried "systemctl stop autofs; systemctl start autofs" I think that's right.
'autofs' is the original automounter, not the systemd ditto. -- Per Jessen, Zürich (23.7°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/08/17 01:53 PM, Per Jessen wrote:
Anton Aylward wrote:
The best I can figure is that neither reload no reexec actually ends up restarting the automounter.
I don't believe the systemd auto-mount scheme needs a running task. I would expect systemd to run inotify() on the applicable mount points and kick off the (generated) units when a mount is needed.
Since, as I say, there doesn't seem to be a SIGCHLD to force a reread at the deamon, its going to take the restart.
You might have tried "systemctl stop autofs; systemctl start autofs" I think that's right.
'autofs' is the original automounter, not the systemd ditto.
*sigh* The way system service files work is that they execute some higher level command, possibly run some daemon. Take a look at what's in - smd.seerver - postfix.service - fetchmail.service - cups.service - sshd.service - sddm.service and so forth. And of course, autofs.service : [Unit] Description=Automounts filesystems on demand Documentation=man:automount(8) man:autofs(5) After=network.target remote-fs.target nss-lookup.target nss-user-lookup.target Before=systemd-logind.service [Service] Type=forking PIDFile=/var/run/automount.pid EnvironmentFile=-/etc/sysconfig/autofs ExecStart=/usr/sbin/automount $AUTOFS_OPTIONS -p /var/run/automount.pid ###### ^^^^^^^^^^^^^^^^^^^^ ###### Please note the above line ExecReload=/usr/bin/kill -HUP $MAINPID TimeoutSec=180 KillMode=mixed [Install] WantedBy=multi-user.target Of course you can verify that these things started by systemd because of the imperatives in the dot-service files are there and running with the 'ps' command. Contrary to myth and mis-information spread by denouncers, systemd is not some great super-program that is soaking up the function of everything else. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 16/08/17 01:53 PM, Per Jessen wrote:
Anton Aylward wrote:
The best I can figure is that neither reload no reexec actually ends up restarting the automounter.
I don't believe the systemd auto-mount scheme needs a running task. I would expect systemd to run inotify() on the applicable mount points and kick off the (generated) units when a mount is needed.
Since, as I say, there doesn't seem to be a SIGCHLD to force a reread at the deamon, its going to take the restart.
You might have tried "systemctl stop autofs; systemctl start autofs" I think that's right.
'autofs' is the original automounter, not the systemd ditto.
*sigh* The way system service files work is that they execute some higher level command, possibly run some daemon.
Wow, I never knew. Anton, please skip the condescending attitude. It has no place here. These days, there are two different styles of automatically mounting filesystems - systemd-automount and autofs. I use the latter in a few places, and afaict, systemd automount is not a drop-in replacement. systemd-automount primarily(?) works with mount units auto-generated from fstab - autofs is quite different, it works with the automount daemon. To have some simple auto-mounted, e.g. an ISO image on /tmp/anton, under systemd there is _no_ need for autofs. systemd will suffice. To work with autofs, you need a different, manual config - systemd will not auto generate anything for you. -- Per Jessen, Zürich (22.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Aug 16, 2017 at 6:03 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
But systemd doesn't read and act on /etc/fstab.
In fact I think it does: man systemd.automount The relevant text here is: FSTAB Automount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). For details how systemd parses /etc/fstab see systemd.mount(5). I want it to re-read this file after I have edited it. As Per said, I will know it worked when I access the file system and trigger the automount. There are systemd-specific flags that can be added to /etc/fstab. I will try systemctl reload when I am back at the machine. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/08/17 01:08 PM, Roger Oberholtzer wrote:
But systemd doesn't read and act on /etc/fstab.
In fact I think it does: man systemd.automount
I think that (a) you are behind on my exchange with Per and the test sequence I've suggested, what to look at and how systemd actually works and what it does; and (b) being a bit loose with language. Ultimately there is the /usr/sbin/automount program that the autofs.service unit directs the relevant parts of system (perhaps via you giving a systemctl command) to start (on boot) or restart. As far as I can tell, what you've been doing, what Per has been doing, is generating a new dot-mount file under /run/systemd/generator but never doing a restart of the autofs via the autofs.service with systemctl. Unless and until the running autofs re-reads the map noting is going to happen. <quote src=AUTOMOUNT(8)> NOTES If the automount daemon catches a USR1 signal, it will umount all currently unused autofs managed mounted file systems and continue running (forced expire). If it catches the TERM signal it will umount all unused autofs managed mounted file systems and exit if there are no remaining busy file systems. .... The daemon also responds to a HUP signal which triggers an update of the maps for each mount point. </quote> Unless you (stop & restart) or reset the deamon with a HUP signal, its not going to do anything about the changes propagated down from /etc/fstab. In effect doing a 'systemctl daemon-reload' does not do a 'systemctl reload *'. This is in accordance with the man page on the 'reload' option for systemctl: This command should not be confused with the daemon-reload command. What you want is to follow up with a systemctl reload autofs.service -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 16/08/17 01:08 PM, Roger Oberholtzer wrote:
But systemd doesn't read and act on /etc/fstab.
In fact I think it does: man systemd.automount
I think that (a) you are behind on my exchange with Per and the test sequence I've suggested, what to look at and how systemd actually works and what it does; and (b) being a bit loose with language.
Ultimately there is the /usr/sbin/automount program that the autofs.service unit directs the relevant parts of system (perhaps via you giving a systemctl command) to start (on boot) or restart.
It isn't needed in this scenario.
As far as I can tell, what you've been doing, what Per has been doing, is generating a new dot-mount file under /run/systemd/generator but never doing a restart of the autofs via the autofs.service with systemctl.
It isn't needed in this scenario.
Unless and until the running autofs re-reads the map noting is going to happen.
I beg to differ - I have no problem getting an ISO image auto-mounted here, without autofs. -- Per Jessen, Zürich (21.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Wed, Aug 16, 2017 at 6:03 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
But systemd doesn't read and act on /etc/fstab.
In fact I think it does: man systemd.automount
The relevant text here is:
FSTAB Automount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details).
For details how systemd parses /etc/fstab see systemd.mount(5).
I want it to re-read this file after I have edited it. As Per said, I will know it worked when I access the file system and trigger the automount.
FWIW, this worked for me in my test setup. Ignore my report about having to reboot. amend fstab systemctl daemon-reload systemctl --all | grep mount ls -l /mtpoint -- Per Jessen, Zürich (21.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Roger Oberholtzer wrote:
I want it to re-read this file after I have edited it. As Per said, I will know it worked when I access the file system and trigger the automount.
FWIW, this worked for me in my test setup. Ignore my report about having to reboot.
amend fstab
My test case is just auto mounting an ISO image: /tmp/openSUSE-13.2-NET-i586.iso /tmp/anton iso9660 loop,noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail 0 0
systemctl daemon-reload systemctl --all | grep anton
tmp-anton.automount tmp-anton.mount
ls -l /tmp/anton
office36:~ # l /tmp/anton/ total 752 dr-xr-xr-x 5 root root 2048 Nov 10 2011 ./ drwxrwxrwt 13 root root 745472 Aug 17 08:08 ../ -r--r--r-- 1 root root 133 Nov 10 2011 ARCHIVES.gz dr-xr-xr-x 3 root root 2048 Nov 10 2011 boot/ -r--r--r-- 1 root root 200 Nov 10 2011 ChangeLog -r--r--r-- 1 root root 3470 Nov 10 2011 content -r--r--r-- 1 root root 481 Nov 10 2011 content.asc -r--r--r-- 1 root root 81 Nov 10 2011 directory.yast -r--r--r-- 1 root root 683 Nov 10 2011 INDEX.gz -r--r--r-- 1 root root 1514 Nov 10 2011 ls-lR.gz dr-xr-xr-x 2 root root 2048 Nov 10 2011 media.1/ dr-xr-xr-x 3 root root 2048 Nov 10 2011 suse/ Here is what systemd did, including the unmount after the idle timeout: Aug 17 08:08:21 office36 systemd[1]: tmp-anton.automount: Got automount request for /tmp/anton, triggered by 14925 (ls) Aug 17 08:08:21 office36 systemd[1]: Mounting /tmp/anton... Aug 17 08:08:21 office36 mount[14926]: mount: /dev/loop0 is write-protected, mounting read-only Aug 17 08:08:21 office36 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3 Dec 31 23:59:58 office36 kernel[885]: Last message 'ISO 9660 Extensions:' repeated 1 times, suppressed by syslog-ng on office36.local.net Aug 17 08:08:21 office36 kernel: ISO 9660 Extensions: RRIP_1991A Aug 17 08:08:21 office36 systemd[1]: Mounted /tmp/anton. Aug 17 08:09:21 office36 systemd[1]: Unmounting /tmp/anton... Aug 17 08:09:21 office36 systemd[1]: Unmounted /tmp/anton. -- Per Jessen, Zürich (19.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-08-17 08:13, Per Jessen wrote:
My test case is just auto mounting an ISO image:
/tmp/openSUSE-13.2-NET-i586.iso /tmp/anton iso9660 loop,noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail 0 0
systemctl daemon-reload systemctl --all | grep anton
tmp-anton.automount tmp-anton.mount
ls -l /tmp/anton
office36:~ # l /tmp/anton/ total 752 dr-xr-xr-x 5 root root 2048 Nov 10 2011 ./ drwxrwxrwt 13 root root 745472 Aug 17 08:08 ../ -r--r--r-- 1 root root 133 Nov 10 2011 ARCHIVES.gz dr-xr-xr-x 3 root root 2048 Nov 10 2011 boot/ -r--r--r-- 1 root root 200 Nov 10 2011 ChangeLog -r--r--r-- 1 root root 3470 Nov 10 2011 content -r--r--r-- 1 root root 481 Nov 10 2011 content.asc -r--r--r-- 1 root root 81 Nov 10 2011 directory.yast -r--r--r-- 1 root root 683 Nov 10 2011 INDEX.gz -r--r--r-- 1 root root 1514 Nov 10 2011 ls-lR.gz dr-xr-xr-x 2 root root 2048 Nov 10 2011 media.1/ dr-xr-xr-x 3 root root 2048 Nov 10 2011 suse/
Here is what systemd did, including the unmount after the idle timeout:
Aug 17 08:08:21 office36 systemd[1]: tmp-anton.automount: Got automount request for /tmp/anton, triggered by 14925 (ls) Aug 17 08:08:21 office36 systemd[1]: Mounting /tmp/anton... Aug 17 08:08:21 office36 mount[14926]: mount: /dev/loop0 is write-protected, mounting read-only Aug 17 08:08:21 office36 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3 Dec 31 23:59:58 office36 kernel[885]: Last message 'ISO 9660 Extensions:' repeated 1 times, suppressed by syslog-ng on office36.local.net Aug 17 08:08:21 office36 kernel: ISO 9660 Extensions: RRIP_1991A Aug 17 08:08:21 office36 systemd[1]: Mounted /tmp/anton. Aug 17 08:09:21 office36 systemd[1]: Unmounting /tmp/anton... Aug 17 08:09:21 office36 systemd[1]: Unmounted /tmp/anton.
Very interesting. I'll try with one new nfs mount I'm setting up. I did: telcontar.valinor:/data/storage_c/repositorios_zypp/ /var/cache/zypp/nfs_packages nfs defaults,noauto,x-systemd.automount,x-systemd.idle-timeout=300,_netdev,nfsvers=4 0 0 I verified that I can mount it manually. The mount point is not empty, contains some safety links. Isengard:~ # ls /var/cache/zypp/nfs_packages 42.2 LocalRPMs not_mounted Isengard:~ # systemctl daemon-reload Isengard:~ # systemctl --all | grep nfs_packages var-cache-zypp-nfs_packages.automount loaded inactive dead var-cache-zypp-nfs_packages.automount var-cache-zypp-nfs_packages.mount loaded inactive dead /var/cache/zypp/nfs_packages Isengard:~ # ls /var/cache/zypp/nfs_packages 42.2 LocalRPMs not_mounted Isengard:~ # Isengard:~ # systemctl status var-cache-zypp-nfs_packages.automount ● var-cache-zypp-nfs_packages.automount Loaded: loaded (/etc/fstab; bad; vendor preset: disabled) Active: inactive (dead) Where: /var/cache/zypp/nfs_packages Docs: man:fstab(5) man:systemd-fstab-generator(8) Isengard:~ # systemctl status var-cache-zypp-nfs_packages.mount ● var-cache-zypp-nfs_packages.mount - /var/cache/zypp/nfs_packages Loaded: loaded (/etc/fstab; bad; vendor preset: disabled) Active: inactive (dead) Where: /var/cache/zypp/nfs_packages What: telcontar.valinor:/data/storage_c/repositorios_zypp/ Docs: man:fstab(5) man:systemd-fstab-generator(8) Isengard:~ # Doesn't work here.... I have not rebooted yet. Log: <4.6> 2017-08-17T12:32:06.129930+02:00 Isengard sshd 1432 - - Accepted publickey for root from 192.168.1.14 port 33556 ssh2: DSA SHA256:IL5fWYgcmeebsYvfWB41P1Z/+UrPHNRpaw77F/UWRf0 <10.6> 2017-08-17T12:32:06.131884+02:00 Isengard sshd 1432 - - pam_unix(sshd:session): session opened for user root by (uid=0) <4.6> 2017-08-17T12:32:06.137686+02:00 Isengard systemd-logind 1230 - - New session 3765 of user root. <3.6> 2017-08-17T12:32:06.166072+02:00 Isengard systemd 1 - - Started Session 3765 of user root. <0.5> 2017-08-17T12:32:25.716194+02:00 Isengard kernel - - - [676987.563945] FS-Cache: Loaded <0.5> 2017-08-17T12:32:25.731445+02:00 Isengard kernel - - - [676987.578756] FS-Cache: Netfs 'nfs' registered for caching <0.5> 2017-08-17T12:32:25.735579+02:00 Isengard kernel - - - [676987.583888] Key type dns_resolver registered <0.5> 2017-08-17T12:32:25.748427+02:00 Isengard kernel - - - [676987.595807] NFS: Registering the id_resolver key type <0.5> 2017-08-17T12:32:25.748460+02:00 Isengard kernel - - - [676987.595848] Key type id_resolver registered <0.5> 2017-08-17T12:32:25.748463+02:00 Isengard kernel - - - [676987.595849] Key type id_legacy registered <10.6> 2017-08-17T12:35:01.684069+02:00 Isengard cron 1566 - - pam_unix(crond:session): session opened for user root by (uid=0) <3.6> 2017-08-17T12:35:01.701435+02:00 Isengard systemd 1 - - Started Session 3766 of user root. <10.6> 2017-08-17T12:35:03.931190+02:00 Isengard CRON 1566 - - pam_unix(crond:session): session closed for user root <3.6> 2017-08-17T12:38:49.393551+02:00 Isengard systemd 1 - - Reloading. <3.4> 2017-08-17T12:38:49.617059+02:00 Isengard systemd 1 - - nss-lookup.target: Dependency Before=nss-lookup.target dropped <10.6> 2017-08-17T12:40:01.941073+02:00 Isengard cron 1684 - - pam_unix(crond:session): session opened for user root by (uid=0) <3.6> 2017-08-17T12:40:01.961454+02:00 Isengard systemd 1 - - Started Session 3767 of user root. <10.6> 2017-08-17T12:40:04.187497+02:00 Isengard CRON 1684 - - pam_unix(crond:session): session closed for user root <4.6> 2017-08-17T12:40:32.078181+02:00 Isengard sshd 1713 - - Accepted publickey for root from 192.168.1.14 port 33614 ssh2: DSA SHA256:IL5fWYgcmeebsYvfWB41P1Z/+UrPHNRpaw77F/UWRf0 <10.6> 2017-08-17T12:40:32.080128+02:00 Isengard sshd 1713 - - pam_unix(sshd:session): session opened for user root by (uid=0) <4.6> 2017-08-17T12:40:32.087533+02:00 Isengard systemd-logind 1230 - - New session 3768 of user root. <3.6> 2017-08-17T12:40:32.113514+02:00 Isengard systemd 1 - - Started Session 3768 of user root. The NFS entries there correspond to the manual "mount /var/cache/zypp/nfs_packages" command. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 2017-08-17 12:48, Carlos E. R. wrote:
Doesn't work here....
I have not rebooted yet.
Isengard:~ # systemctl restart remote-fs.target Isengard:~ # This works - thanks, Per :-) <3.6> 2017-08-17T12:49:07.027858+02:00 Isengard systemd 1 - - Stopped target Remote File Systems. <3.6> 2017-08-17T12:49:07.033710+02:00 Isengard systemd 1 - - Stopping Remote File Systems. <3.5> 2017-08-17T12:49:07.034632+02:00 Isengard systemd 1 - - var-cache-zypp-nfs_packages.automount: Directory /var/cache/zypp/nfs_packages to mount over is not empty, mounting anyway. <3.6> 2017-08-17T12:49:07.035218+02:00 Isengard systemd 1 - - Set up automount var-cache-zypp-nfs_packages.automount. <3.6> 2017-08-17T12:49:07.035676+02:00 Isengard systemd 1 - - Reached target Remote File Systems. <3.6> 2017-08-17T12:49:10.000532+02:00 Isengard systemd 1 - - var-cache-zypp-nfs_packages.automount: Got automount request for /var/cache/zypp/nfs_packages, triggered by 2061 (ls) <3.5> 2017-08-17T12:49:10.001203+02:00 Isengard systemd 1 - - Network Manager is not active. <3.4> 2017-08-17T12:49:10.017029+02:00 Isengard systemd 1 - - Dependency failed for Network Manager Wait Online. <3.5> 2017-08-17T12:49:10.017653+02:00 Isengard systemd 1 - - NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start failed with result 'dependency'. <3.6> 2017-08-17T12:49:10.018141+02:00 Isengard systemd 1 - - Reached target Network is Online. <3.6> 2017-08-17T12:49:10.018684+02:00 Isengard systemd 1 - - Mounting /var/cache/zypp/nfs_packages... <3.6> 2017-08-17T12:49:10.116225+02:00 Isengard systemd 1 - - Mounted /var/cache/zypp/nfs_packages. <10.6> 2017-08-17T12:50:01.537993+02:00 Isengard cron 2089 - - pam_unix(crond:session): session opened for user root by (uid=0) <3.6> 2017-08-17T12:50:01.553447+02:00 Isengard systemd 1 - - Started Session 3772 of user root. <10.6> 2017-08-17T12:50:03.784108+02:00 Isengard CRON 2089 - - pam_unix(crond:session): session closed for user root Command "mount" produces this listing - notice the double entry, as in the log: systemd-1 on /var/cache/zypp/nfs_packages type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) telcontar.valinor:/data/storage_c/repositorios_zypp on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.16,local_lock=none,addr=192.168.1.14,_netdev) Isengard:~ # -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 2017-08-17 12:53, Carlos E. R. wrote:
Command "mount" produces this listing - notice the double entry, as in the log:
systemd-1 on /var/cache/zypp/nfs_packages type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) telcontar.valinor:/data/storage_c/repositorios_zypp on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.16,local_lock=none,addr=192.168.1.14,_netdev) Isengard:~ #
After a while, it changes to: systemd-1 on /var/cache/zypp/nfs_packages type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) which I suppose is the watchout, but it is not mounted. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Thu, Aug 17, 2017 at 1:36 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2017-08-17 12:53, Carlos E. R. wrote:
Command "mount" produces this listing - notice the double entry, as in the log:
systemd-1 on /var/cache/zypp/nfs_packages type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) telcontar.valinor:/data/storage_c/repositorios_zypp on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.16,local_lock=none,addr=192.168.1.14,_netdev) Isengard:~ #
After a while, it changes to:
systemd-1 on /var/cache/zypp/nfs_packages type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
which I suppose is the watchout, but it is not mounted.
So a reboot is currently the only way for the changes in /etc/fstab to take effect. Still, I see the unit files generated for the fstab entries. So that happens without a reboot. It is whatever is using these unit files to automount that seems not to get this new picture. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Aug 17, 2017 at 1:36 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2017-08-17 12:53, Carlos E. R. wrote:
Command "mount" produces this listing - notice the double entry, as in the log:
systemd-1 on /var/cache/zypp/nfs_packages type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) telcontar.valinor:/data/storage_c/repositorios_zypp on /var/cache/zypp/nfs_packages type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.16,local_lock=none,addr=192.168.1.14,_netdev)
Isengard:~ #
After a while, it changes to:
systemd-1 on /var/cache/zypp/nfs_packages type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
which I suppose is the watchout, but it is not mounted.
So a reboot is currently the only way for the changes in /etc/fstab to take effect.
Nono, you just need the restart too: systemctl restart remote-fs.target
Still, I see the unit files generated for the fstab entries. So that happens without a reboot. It is whatever is using these unit files to automount that seems not to get this new picture.
That is the missing start of ths automount unit. If you start one manually, you can verify it works. -- Per Jessen, Zürich (26.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Aug 16, 2017 at 9:47 PM, Per Jessen <per@computer.org> wrote:
I want it to re-read this file after I have edited it. As Per said, I will know it worked when I access the file system and trigger the automount.
FWIW, this worked for me in my test setup. Ignore my report about having to reboot.
amend fstab systemctl daemon-reload systemctl --all | grep mount
I get this for the mount point of interest: source-vol1.automount loaded inactive dead source-vol1.automount source-vol1.mount loaded inactive dead /source/vol1 Moving to that directory does not cause it to be mounted. Odd that it is listed twice. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Wed, Aug 16, 2017 at 9:47 PM, Per Jessen <per@computer.org> wrote:
I want it to re-read this file after I have edited it. As Per said, I will know it worked when I access the file system and trigger the automount. FWIW, this worked for me in my test setup. Ignore my report about having to reboot.
amend fstab systemctl daemon-reload systemctl --all | grep mount
I get this for the mount point of interest:
source-vol1.automount loaded inactive dead source-vol1.automount source-vol1.mount loaded inactive dead /source/vol1
Moving to that directory does not cause it to be mounted.
Did you try 'ls' ?
Odd that it is listed twice.
automount and mount - I think 'automount' is the unit that drives 'mount'. Anyway, check /var/log/messages for systemd output related - you should see why your mtpt wasn't mounted. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Aug 17, 2017 at 9:27 AM, Per Jessen <per@computer.org> wrote:
Moving to that directory does not cause it to be mounted.
Did you try 'ls' ?
Yes. Even though the unit files were in place, it required a reboot for the mounts to happen. "systemctl reload autofs" had no effect.
Odd that it is listed twice.
automount and mount - I think 'automount' is the unit that drives 'mount'.
Anyway, check /var/log/messages for systemd output related - you should see why your mtpt wasn't mounted.
It doesn't say anything. It just didn't happen until after the reboot. When autofs fails, you get an error and the message that the directory does not exist. This is good so you know that you are really accessing what you expect. systemd said nothing. I was in an empty directory (e.g. the mount point). This is especially troublesome when doing something like a backup that is expected to be on the mounted volume - not the disk containing the mount point. This is not a big issue. I am just trying to decide on moving things from autofs to systemd. I like the idea of all the mounts being in one file. But autofs has been working fine. A reboot is not really an issue. These things on my system are rather stable over time. The question is if we move to using systemd for this in our product systems... It would still be interesting to know the expected (i.e. systemd official) series of events that lead from editing /etc/fstab to the edits being used. Thanks for all the help to everyone who responded. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Aug 17, 2017 at 9:27 AM, Per Jessen <per@computer.org> wrote:
Moving to that directory does not cause it to be mounted.
Did you try 'ls' ?
Yes. Even though the unit files were in place, it required a reboot for the mounts to happen.
That is weird - hmm, I can't make that work now either. I must have dreamt it. Just now, to get it to work without reboot, I did: systemctl start <automount-unit> e.g. systemctl start tmp-anton.automount
"systemctl reload autofs" had no effect.
As it shouldn't, it isn't involved here.
Odd that it is listed twice.
automount and mount - I think 'automount' is the unit that drives 'mount'.
Anyway, check /var/log/messages for systemd output related - you should see why your mtpt wasn't mounted.
It doesn't say anything. It just didn't happen until after the reboot.
Yeah. See above. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Roger Oberholtzer wrote:
On Thu, Aug 17, 2017 at 9:27 AM, Per Jessen <per@computer.org> wrote:
Moving to that directory does not cause it to be mounted.
Did you try 'ls' ?
Yes. Even though the unit files were in place, it required a reboot for the mounts to happen.
That is weird - hmm, I can't make that work now either. I must have dreamt it. Just now, to get it to work without reboot, I did:
systemctl start <automount-unit> e.g.
systemctl start tmp-anton.automount
I found a couple of references saying you need one of these after the daemon-reload: systemctl restart remote-fs.target or systemctl restart local-fs.target I haven't tried it. brgds Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-08-17 10:19, Per Jessen wrote:
I found a couple of references saying you need one of these after the daemon-reload:
systemctl restart remote-fs.target
This one did the trick for me.
or
systemctl restart local-fs.target
I haven't tried it.
-- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Roger Oberholtzer composed on 2017-08-16 12:30 (UTC+0200):
on Leap 42.3:
If I make a change to /etc/fstab so that, for example, I make an item be automounted by systemd, how can I get systemd to re-read this file without rebooting?
I have added the following to an entry, and would like to see that the item gets mounted when accessed.
noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail
I expected something like:
systemctl restart automount
or
systemctl restart mount
But this seems not to work.
In what I think is the same vein, I to a lot of repartitioning and moving and cloning of partitions. So, I have to follow-up with fstab edits, which I too frequently do imperfectly. As example, LABEL=f24h50 /mnt/f24 ext4 noatime,nofail 0 0 was supposed to be replaced by LABEL=f26h50 /mnt/f26 ext4 noatime,nofail 0 0 but instead I did LABEL=f22h50 /mnt/f26 ext4 noatime,nofail 0 0 and found mount /mnt/f26 failed. I fixed it and tried again. Mount returned no error, but neither did f26h50 get mounted. After reading the whole thread, it's entirely unclear to me what one is supposed to do after such an edit fixup to successfully mount f26h50, short of rebooting. Likewise similarly by s/nofail/noauto/g above. This was such a simple error to deal with pre-systemd. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Anton Aylward -
Carlos E. R. -
Felix Miata -
Per Jessen -
Roger Oberholtzer