From: Karel Zak <kzak@redhat.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Roger Leigh <rleigh@codelibre.net>, util-linux@vger.kernel.org
Subject: Re: /etc/fstab.d yes or not
Date: Mon, 23 Jan 2012 13:21:15 +0100 [thread overview]
Message-ID: <20120123122115.GA29250@x2.net.home> (raw)
In-Reply-To: <CAPXgP11pvch92n1=mMfDsMLoGZMG8xq0e1juXyUO6mxFR6_GYg@mail.gmail.com>
On Fri, Jan 20, 2012 at 06:59:47PM +0100, Kay Sievers wrote:
> > Inventing custom file formats for these (as is the current situation)
> > is both opaque to the admin and less amenable to preservation/upgrading
> > of the admins customisations and the defaults.
>
> I'm not talking about custom file formats, better just add a mount -c,
> and do mount -c /etc/kernelfs.d/*.conf, or whatever will fit systemv
> needs.
This is planned (I talked about it on dracut list few months ago). It
means:
mount --fstab=<path> /mountpoint
to override the default /etc/fstab path. The <path> could be also a
directory. So you can maintain our mountpoints in multiple files and
mount(8) will be able to search in the files if --fstab=<path> is
explicitly specified. I think this should be enough for initramfs
scripts.
The problem is that the configuration won't be visible if
--fstab is not specified -- this is possible to resolve probably
by regular /etc/fstab.d only ;-)
> This is nothing really to share between systemd and systemv here. This
> problem just does not exist for systemd.
Well, Masatake has RHEL customers who want to deploy systems with
rpm/yum, %post scripts are poor solution because it's not too
reliable and verification with rpm -V doesn't work. Do we have any
answer for this use case?
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2012-01-23 12:21 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 14:04 /etc/fstab.d yes or not Karel Zak
2012-01-20 14:04 ` Karel Zak
2012-01-20 14:20 ` Masatake YAMATO
2012-01-20 14:56 ` Kay Sievers
2012-01-20 14:56 ` Kay Sievers
2012-01-20 15:57 ` Roger Leigh
2012-01-20 16:08 ` Kay Sievers
2012-01-20 16:08 ` Kay Sievers
2012-01-24 0:19 ` Boaz Harrosh
2012-01-24 0:19 ` Boaz Harrosh
2012-01-24 9:47 ` bastien ROUCARIES
2012-01-24 9:47 ` bastien ROUCARIES
2012-01-20 14:43 ` Attila Kinali
2012-01-20 14:59 ` Karel Zak
2012-01-20 14:59 ` Karel Zak
2012-01-20 15:03 ` Voelker, Bernhard
2012-01-20 15:20 ` Kay Sievers
2012-01-20 15:20 ` Kay Sievers
2012-01-20 15:49 ` Roger Leigh
2012-01-20 15:49 ` Roger Leigh
2012-01-20 16:13 ` Kay Sievers
2012-01-20 16:22 ` Roger Leigh
2012-01-20 16:22 ` Roger Leigh
2012-01-20 17:59 ` Kay Sievers
2012-01-20 17:59 ` Kay Sievers
2012-01-23 12:21 ` Karel Zak [this message]
2012-01-23 13:01 ` Masatake YAMATO
2012-01-23 13:03 ` Kay Sievers
2012-01-23 13:26 ` Masatake YAMATO
2012-01-23 13:37 ` Kay Sievers
2012-01-23 14:14 ` Masatake YAMATO
2012-01-23 14:32 ` Kay Sievers
2012-01-23 13:55 ` Theodore Tso
2012-01-23 22:07 ` Alan Cox
2012-01-24 1:06 ` Ted Ts'o
2012-01-20 18:20 ` Denys Vlasenko
2012-01-20 18:20 ` Denys Vlasenko
2012-01-20 18:29 ` Kay Sievers
2012-01-20 18:29 ` Kay Sievers
2012-01-20 18:47 ` Al Viro
2012-01-20 18:47 ` Al Viro
2012-01-24 11:02 ` /etc/fstab.d yes or not (resolved) Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120123122115.GA29250@x2.net.home \
--to=kzak@redhat.com \
--cc=kay.sievers@vrfy.org \
--cc=rleigh@codelibre.net \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.