On Thu, Feb 12, 2015 at 05:33:26PM +0100, Martin Pitt wrote:
\o/ looking forward to let /etc/mtab die a bit more :-)
util-linux v2.26 (released last week) provides
--enable-libmount-force-mountinfo
configure option to make mtab's grave more robust.
Karel
--
Karel Zak
On Mon, 23.02.15 14:36, Karel Zak (k...@redhat.com) wrote:
On Thu, Feb 12, 2015 at 05:33:26PM +0100, Martin Pitt wrote:
\o/ looking forward to let /etc/mtab die a bit more :-)
util-linux v2.26 (released last week) provides
--enable-libmount-force-mountinfo
configure option
On Thu, 12.02.15 11:58, Martin Pitt (martin.p...@ubuntu.com) wrote:
Lennart Poettering [2015-02-12 11:22 +0100]:
To make systemd robust against this, I fixed
mount_load_proc_self_mountinfo() to actually do what it intends to do,
instead of loading /etc/mtab (which is still util-linux'
Lennart Poettering [2015-02-12 11:22 +0100]:
To make systemd robust against this, I fixed
mount_load_proc_self_mountinfo() to actually do what it intends to do,
instead of loading /etc/mtab (which is still util-linux' default for
mnt_table_parse_mtab()).
Urks, we never want to read
On Thu, Feb 12, 2015 at 10:40:15AM +0100, Martin Pitt wrote:
So explicitly specify the file that we actually want to parse.
[1] first boot after a distro upgrade, or a package bug, or administrators
configuring it explicitly for some reason
https://launchpad.net/bugs/1419623
---
Hey Karel,
Karel Zak [2015-02-12 12:25 +0100]:
-r = mnt_table_parse_mtab(tb, NULL);
+r = mnt_table_parse_mtab(tb, /proc/self/mountinfo);
This is bad solution. It resolves the issue, but forces libmount to
not read /run/mount/utab.
Can you please explain why? As far as I
On Thu, 12.02.15 10:40, Martin Pitt (martin.p...@ubuntu.com) wrote:
So right after we popped out of initramfs (which doesn't have an
fstab, nor /etc/mtab, nor does it do anything else than mouting /
read-only) we see all these mounts which can't possibly happen that
early -- e. g.
On Thu, Feb 12, 2015 at 12:25:33PM +0100, Karel Zak wrote:
On Thu, Feb 12, 2015 at 10:40:15AM +0100, Martin Pitt wrote:
So explicitly specify the file that we actually want to parse.
[1] first boot after a distro upgrade, or a package bug, or administrators
configuring it explicitly
Martin Pitt [2015-02-12 12:40 +0100]:
Can you please explain why?
Nevermind, I see it now. So what actually would work is to call it
with a nonexisting file, a directory, a symlink, or just about
anything else which isn't a regular file. Thus
mnt_table_parse_mtab(tb, /) would actually work
Hello again,
Martin Pitt [2015-02-11 23:42 +0100]:
Lennart Poettering [2015-02-11 17:05 +0100]:
Actually, the fact that the unit changes directly from dead to
mounted is interesting. The unit does not go through mounting,
which means that it's not the unit that is invoking the /bin/mount
On Thu, 12.02.15 13:27, Karel Zak (k...@redhat.com) wrote:
On Thu, Feb 12, 2015 at 12:01:13PM +0100, Lennart Poettering wrote:
And the stuff from /run is always merged into it, regardless which
file is read?
No, if you specify any filename and the file exists than it does not
read from
On Thu, Feb 12, 2015 at 03:38:13PM +0100, Lennart Poettering wrote:
If I am right then as soon as you fixed libmount so that the whole
handling of /etc/mtab can be turned off, then you will make that the
default in Fedora, and no changes to systemd will be necessary at all,
correct?
Correct.
On Thu, Feb 12, 2015 at 12:01:13PM +0100, Lennart Poettering wrote:
And the stuff from /run is always merged into it, regardless which
file is read?
No, if you specify any filename and the file exists than it does not
read from /run, I have fixed this mistake
Hey Lennart and Karel,
Lennart Poettering [2015-02-12 15:38 +0100]:
I will not apply it to systemd git.
Ack. I put a hacked version into the Debian package for now, as we'll
have to live with util-linux 2.25 for the impending release:
14 matches
Mail list logo
