11:59 a.m.
Original is here:
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
Future updates will be cross-posted.
-------
(This first update is big. Subsequent updates should be smaller.)
Changes:
+ Anaconda defaults to Btrfs for automatic partitioning for all
desktop installation media
+ libvirtd patches have landed that will set 'nodatacow' (chattr +C)
on VM image containing directories when on Btrfs, by default:
virt-manager, GNOME Boxes, Cockpit, et al, will benefit from this
directly; minimally tested OK, needs some further testing
+ Numerous btrfs kernel patches, related to Fedora concerns and
requests have landed on upstream linux-btrfs@, including new
'rescue=all' mount option to better tolerate read-only mount despite
file system damage
+ anaconda fix for Silverblue on Btrfs, set "rootflags" boot parameter
so startup succeeds
+ various compose related fixes for non-ISO images; PR submitted, not
yet merged into production (consequence is, these Rawhide images are
not being created right now for armhfp: Workstation, KDE, Xfce, LXDE,
MATE, Sugar)
+ btrfs driver is now built-in to the kernel, rather than as a module
+ Red Hat CKI (Continuous Kernel Integration) have added btrfs to
their regular xfstests and will report failures upstream
Communication:
+ Fedora Magazine article(s) are in the idea and specification phase.
https://pagure.io/fedora-workstation/issue/162
https://discussion.fedoraproject.org/t/btrfs-by-default/22020
https://teams.fedoraproject.org/project/asamalik-fedora-magazine/us/216?k...
Documentation:
+ Draft material available for review, organization and content
development in-progress.
https://pagure.io/fedora-workstation/issue/158
+ Clarification is needed to what degree effort should be spent on updating
upstream wiki so it doesn't conflict with Fedora reality; versus
Fedora specific content focus.
Noteworthy bugs:
+ Btrfs corruption tracked down to bad RAM (confirmed with
memtest86+); will result in improvements to 'btrfs check --repair' to
better handle this case; does also expose the difficulty with Btrfs
only stating the facts rather than pointing the finger at the cause.
https://bugzilla.redhat.com/show_bug.cgi?id=1857996
+ Btrfs tracking bug
https://bugzilla.redhat.com/show_bug.cgi?id=1851166
--
Chris Murphy
12:24 p.m.
On Mon, 27 Jul 2020 at 18:00, Chris Murphy <lists(a)colorremedies.com> wrote:
[..]
+ btrfs driver is now built-in to the kernel, rather than as a
module
Classic .. from frying pan to open fire.
Why the heck dist kernel cannot be without ANY fs support? I've been using
such a kernel (sic!) 15y ago !!!
Why is it still automonter hardcoded into the kernel even if it is
completely useless on a typical single workstation?
(which is still probably most of the cases when Fedora is used now).
Currently dracut can generate initrd with loading correct root fs module
and even block layer (nvme/sata) or network layer network card module if
boot is done with loading by grub kernel and initrd over network on using
NFS on root fs.
Why do people who choose other FSess like xfs or ext4 or even f2fs for some
embedded systems are forced to have wasted available small memory footprint
by things which can be loaded as modules on demand?
Only because with such a kernel it could not be possible to say that Fedora
is supporting btrfs as default fs? (and buy this it would make all those
talks about default fs obsolete?).
Why Fedora cannot have only btrfs as default *proposed by
anaconda/kickstart* FS?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
12:30 p.m.
On Mon, Jul 27, 2020 at 1:24 PM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
On Mon, 27 Jul 2020 at 18:00, Chris Murphy <lists(a)colorremedies.com> wrote:
[..]
>
> + btrfs driver is now built-in to the kernel, rather than as a module
Classic .. from frying pan to open fire.
Why the heck dist kernel cannot be without ANY fs support? I've been using such a
kernel (sic!) 15y ago !!!
Why is it still automonter hardcoded into the kernel even if it is completely useless on
a typical single workstation?
(which is still probably most of the cases when Fedora is used now).
Currently dracut can generate initrd with loading correct root fs module and even block
layer (nvme/sata) or network layer network card module if boot is done with loading by
grub kernel and initrd over network on using NFS on root fs.
Why do people who choose other FSess like xfs or ext4 or even f2fs for some embedded
systems are forced to have wasted available small memory footprint by things which can be
loaded as modules on demand?
Only because with such a kernel it could not be possible to say that Fedora is supporting
btrfs as default fs? (and buy this it would make all those talks about default fs
obsolete?).
Why Fedora cannot have only btrfs as default proposed by anaconda/kickstart FS?
I don't completely understand what you're asking here, but it was
specifically requested to build it into the kernel to support booting
systems without an initramfs during the discussion of the change
proposal. The kernel maintainers were fine with it, so we went ahead
and did just that.
And your insinuation that Fedora is mostly used for single-user
workstations is wrong, as I know of surprisingly large companies that
use Fedora for servers and cloud machines. :)
--
真実はいつも一つ！/ Always, there's only one truth!
12:32 p.m.
On Mon, Jul 27, 2020 at 06:24:06PM +0100, Tomasz Kłoczko wrote:
On Mon, 27 Jul 2020 at 18:00, Chris Murphy
<lists(a)colorremedies.com> wrote:
[..]
> + btrfs driver is now built-in to the kernel, rather than as a module
>
Classic .. from frying pan to open fire.
Why the heck dist kernel cannot be without ANY fs support? I've been using
such a kernel (sic!) 15y ago !!!
Tomasz,
take a step back... This is just a kernel config change, no reason to
get angry.
Why is it still automonter hardcoded into the kernel even if it is
completely useless on a typical single workstation?
It is used by systemd for
various less-frequently used mount points
and automount entries can be configured in /etc/fstab.
Zbyszek
(which is still probably most of the cases when Fedora is used now).
Currently dracut can generate initrd with loading correct root fs module
and even block layer (nvme/sata) or network layer network card module if
boot is done with loading by grub kernel and initrd over network on using
NFS on root fs.
Why do people who choose other FSess like xfs or ext4 or even f2fs for some
embedded systems are forced to have wasted available small memory footprint
by things which can be loaded as modules on demand?
Only because with such a kernel it could not be possible to say that Fedora
is supporting btrfs as default fs? (and buy this it would make all those
talks about default fs obsolete?).
Why Fedora cannot have only btrfs as default *proposed by
anaconda/kickstart* FS?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
1:20 p.m.
On Mon, 27 Jul 2020 at 18:35, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
wrote:
[..]
> Why the heck dist kernel cannot be without ANY fs support?
I've been
using
> such a kernel (sic!) 15y ago !!!
Tomasz,
take a step back... This is just a kernel config change, no reason to
get angry.
> Why is it still automonter hardcoded into the kernel even if it is
> completely useless on a typical single workstation?
It is used by systemd for various less-frequently used mount points
and automount entries can be configured in /etc/fstab.
Really?
(my jaw is on the floor crashed into the pieces)
I must honestly confess that in the meantime systemd swallowed autofs as
well!
So (a bit off-topic) what was wrong with autofs as a separate small process
started only when it was necessary? Do you remember that?
Because with some bits of the autofs user space process in systemd when
someone would be using automonter maps loaded over LDAP (going over glibc
NSS layer) it will be some redundancy between those parts.
PS. I think that now I have the proper impuls/reason to port SMF to Linux.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
2:04 p.m.
On Mon, Jul 27, 2020 at 07:20:16PM +0100, Tomasz Kłoczko wrote:
On Mon, 27 Jul 2020 at 18:35, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl>
wrote:
[..]
> > Why the heck dist kernel cannot be without ANY fs support? I've been
> using
> > such a kernel (sic!) 15y ago !!!
>
> Tomasz,
> take a step back... This is just a kernel config change, no reason to
> get angry.
>
> > Why is it still automonter hardcoded into the kernel even if it is
> > completely useless on a typical single workstation?
> It is used by systemd for various less-frequently used mount points
> and automount entries can be configured in /etc/fstab.
>
Really?
(my jaw is on the floor crashed into the pieces)
I must honestly confess that in the meantime systemd swallowed autofs as
well!
So (a bit off-topic) what was wrong with autofs as a separate small process
started only when it was necessary? Do you remember that?
Having automount support directly in pid1 allows automounts to be part
of the unit graph — with dependencies and triggering and failure actions.
The code to talk to the kernel interface is rather simple. The part
to tie into the rest of the unit framework is bigger. Having a separate
daemon would only make that bigger part even more complicated.
Because with some bits of the autofs user space process in systemd
when
someone would be using automonter maps loaded over LDAP (going over glibc
NSS layer) it will be some redundancy between those parts.
You can still have the automount daemon. For the cases where you want
use automounts defined in LDAP that's totally appropriate.
PS. I think that now I have the proper impuls/reason to port SMF to
Linux.
kloczek
:)
Zbyszek
2:27 p.m.
New subject: systemd autofs support (Was: Re: Btrfs by default status updates, 2020-07-26)
On Mon, 27 Jul 2020 at 20:05, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
wrote:
[..]
> So (a bit off-topic) what was wrong with autofs as a separate
small
process
> started only when it was necessary? Do you remember that?
Having automount support directly in pid1 allows automounts to be part
of the unit graph — with dependencies and triggering and failure actions.
The code to talk to the kernel interface is rather simple. The part
to tie into the rest of the unit framework is bigger. Having a separate
daemon would only make that bigger part even more complicated.
Still it does not explain why automonting cannot be just a regular unit
with a separated process.
That way it still can be part of the "the unit graph", and both systemd
units and SMF services are using dependencies.
As communication with kennel space is done over /de/autofs and just checked
and autofs and systemd are using that interface almost the same way.
At the moment it seems that the autofs bit is used only to mout per logged
user tmpfs which looks like it could be mounted/umounted using the user
systemd unit WITHOUT automounter. Am I right? If yes, using the automonter
is kind of overkill because all that could be done without autofs. Instead
have in kernel autofs and in userspace communication over /dev/autofs thi
could be done with a top 0.5KB systemd unit yext file which will execute
mount/umount commands with some exact params.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
2:38 p.m.
New subject: systemd autofs support (Was: Re: Btrfs by default status
updates, 2020-07-26)
On Mon, Jul 27, 2020 at 08:27:24PM +0100, Tomasz Kłoczko wrote:
On Mon, 27 Jul 2020 at 20:05, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl>
wrote:
[..]
> > So (a bit off-topic) what was wrong with autofs as a separate small
> process
> > started only when it was necessary? Do you remember that?
>
> Having automount support directly in pid1 allows automounts to be part
> of the unit graph — with dependencies and triggering and failure actions.
> The code to talk to the kernel interface is rather simple. The part
> to tie into the rest of the unit framework is bigger. Having a separate
> daemon would only make that bigger part even more complicated.
>
Still it does not explain why automonting cannot be just a regular unit
with a separated process.
That way it still can be part of the "the unit graph", and both systemd
units and SMF services are using dependencies.
As communication with kennel space is done over /de/autofs and just checked
and autofs and systemd are using that interface almost the same way.
It probably could. The general reason to keep things built into pid1
is that the code to communicate state to the separate process and failure
back to the main process would be more code than the actual "business logic"
running in the separate process. But let's not discuss this here — if
we start discussing systemd design, we'll have another megathread on
fedora-devel, and I don't think anyone wants that. systemd-devel is
a more appropriate place.
At the moment it seems that the autofs bit is used only to mout per
logged
user tmpfs which looks like it could be mounted/umounted using the user
systemd unit WITHOUT automounter. Am I right? If yes, using the automonter
is kind of overkill because all that could be done without autofs. Instead
have in kernel autofs and in userspace communication over /dev/autofs thi
could be done with a top 0.5KB systemd unit yext file which will execute
mount/umount commands with some exact params.
It is also used for anything which has x-systemd.automount, so the list is
open-ended.
Zbyszek
5:09 a.m.
On Mo, 27.07.20 18:24, Tomasz Kłoczko (kloczko.tomasz(a)gmail.com) wrote:
On Mon, 27 Jul 2020 at 18:00, Chris Murphy
<lists(a)colorremedies.com> wrote:
[..]
> + btrfs driver is now built-in to the kernel, rather than as a module
>
Classic .. from frying pan to open fire.
Why the heck dist kernel cannot be without ANY fs support? I've been using
such a kernel (sic!) 15y ago !!!
To make things more robust and for things to work without an initrd,
and because its a bit faster too if it's a module we are very likely
to load anyway...
I am pretty sure we should build-in all modules that are highly likely
to be used in common installs (and i am pretty sure a file system we
use per default qualifies).
Why is it still automonter hardcoded into the kernel even if it is
completely useless on a typical single workstation?
binfmt_misc is mounted with that by default.
And systemd will mount the ESP and the boot loader partition with the
automounter by default, so that it's only mounted on access and
quickly unmounted again afterwards, to ensure it stays in a clean
state whenever possible. (This logic is turned off if these mounts are
explicitly listed in fstab tough, unfortunately fedora does that).
Lennart
--
Lennart Poettering, Berlin
5:22 a.m.
On Mo, 27.07.20 19:20, Tomasz Kłoczko (kloczko.tomasz(a)gmail.com) wrote:
Really?
(my jaw is on the floor crashed into the pieces)
I must honestly confess that in the meantime systemd swallowed autofs as
well!
It didn't. It supports a small subset of the whole autofs logic, in
order to make fs-based activation work, i.e. provide a path in the fs
before its mounted in order to improve robustness, increase
parallelization and pull things in on demand only.
i.e. a good usecase for this is mounting the ESP with this, so that
the fs remains untouched unless actually accessed. i.e. for file
systems that are fragile to some point and which are seldom accessed
it's great to guarantee that they are clean (i.e. not dirty/mounted)
whenever possible. And when it is accessed we pull in fsck@.service
for the fs in the bg and then mount it, all invisibly to the
program accessing it.
Another great usecase for this is actually any form of removable
media, such as USB sticks: it allows us to pretend-mount removable USB
sticks without actually having the fs mounted in the kernel all the
time. This means we have a much larger chance of leaving a clean fs on
the USB stick if the user yanks the stick from the plug without
cleanly unmounting it first, because the fs is simply not mounted at
all unless accessed. systemd-mount exposes this nicely (and ideally
udisks would always use this functionality for all USB media, which
would also mean fsck would be called at the right times, which udisks
currently doesn#t call at all, which sucks hard).
What's also great is that we can properly detach file systems in the
right order if systemd knows the deps. i.e. a service backing a mount
can be stopped at the right time when an autofs mount is shutdown,
which is hard if the stuff is entirely opaque to systemd...
BTW, this was one of the features available pretty early on in
systemd, since before systemd was even adopted by Fedora. No need to
lose it about this so many years after. And it's not complex code,
it's a relatively simple API (though it feels a bit dated in style).
It's not usable for NIS stye autofs mounts, as it doesn't support
maps. Use autofs4 package if you want that.
Lennart
--
Lennart Poettering, Berlin
5:53 a.m.
New subject: systemd autofs support (Was: Re: Btrfs by default status
updates, 2020-07-26)
On Mo, 27.07.20 20:27, Tomasz Kłoczko (kloczko.tomasz(a)gmail.com) wrote:
On Mon, 27 Jul 2020 at 20:05, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl>
wrote:
[..]
> > So (a bit off-topic) what was wrong with autofs as a separate small
> process
> > started only when it was necessary? Do you remember that?
>
> Having automount support directly in pid1 allows automounts to be part
> of the unit graph — with dependencies and triggering and failure actions.
> The code to talk to the kernel interface is rather simple. The part
> to tie into the rest of the unit framework is bigger. Having a separate
> daemon would only make that bigger part even more complicated.
>
Still it does not explain why automonting cannot be just a regular unit
with a separated process.
That way it still can be part of the "the unit graph", and both systemd
units and SMF services are using dependencies.
As communication with kennel space is done over /de/autofs and just checked
and autofs and systemd are using that interface almost the same way.
If you have a service you need to stop when unmounting a .mount unit
that is wrapped by an autofs, then you need to do that in the right
order, which is easy if .automount and .mount are known to systemd and
things can just be ordered using the usual dependency tree. But if you
do all that outside of systemd then you either have to communicate a
lot between that process and PID 1 or the service needs to be a child
process of that process, and thus live outside of systemd service
management, i.e. have no sandboxing, no resource mgmt, not dep tree
integration and so on. The communication between that outside process
and PID 1 would be at least as complex (probably many times so) as the
syscall/ioctl iface between PID 1 in the kernel if we just do it
ourselves. I mean, that's the thing here: IPC comes at a cost, and the
IPC that the kernel API is is really nice to use, it's just function
calls exported by glibc.
Splitting out stuff into process makes a lot of sense, if they either
are complex or dangerous. But the autofs ioctl calling is
neither. It's simple and not anymore dangerous than calling mount() itself...
At the moment it seems that the autofs bit is used only to mout per
logged
user tmpfs which looks like it could be mounted/umounted using the user
systemd unit WITHOUT automounter. Am I right? If yes, using the
automonter
We do not use the automount logic for that. We do use it for mounting
the ESP/boot loader partition (unless OS overrides that and turns this
out, which Fedora/Anaconda unfortunately — needlessly — do), for
binfmt_misc and removable USB device handling.
is kind of overkill because all that could be done without autofs.
Instead
have in kernel autofs and in userspace communication over /dev/autofs thi
could be done with a top 0.5KB systemd unit yext file which will execute
mount/umount commands with some exact params.
I don't think it's worth pulling in yet another package just for
calling a few ioctls, sorry.
Lennart
--
Lennart Poettering, Berlin
7:02 a.m.
On Tue, 28 Jul 2020 at 11:11, Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
[..]
> Why is it still automonter hardcoded into the kernel even if it
is
> completely useless on a typical single workstation?
binfmt_misc is mounted with that by default.
And systemd will mount the ESP and the boot loader partition with the
automounter by default, so that it's only mounted on access and
quickly unmounted again afterwards, to ensure it stays in a clean
state whenever possible. (This logic is turned off if these mounts are
explicitly listed in fstab tough, unfortunately fedora does that).
So .. someone knows why it cannot be mounted on "mount -a" when entry
for binfmt_misc would be in fstab or even over .mount unit?
$ rpm -ql systemd | grep proc-sys; echo; systemctl status
proc-sys-fs-binfmt_misc.mount
proc-sys-fs-binfmt_misc.mount/usr/lib/systemd/system/proc-sys-fs-binfmt_misc.automount
/usr/lib/systemd/system/proc-sys-fs-binfmt_misc.mount
/usr/lib/systemd/system/sysinit.target.wants/proc-sys-fs-binfmt_misc.automount
● proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File
System
Loaded: loaded (/proc/self/mountinfo; disabled; vendor preset:
disabled)
Active: active (mounted) since Thu 2020-07-23 18:36:17 BST; 4 days ago
TriggeredBy: ● proc-sys-fs-binfmt_misc.automount
Where: /proc/sys/fs/binfmt_misc
What: binfmt_misc
Docs:
https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
Tasks: 0 (limit: 154244)
Memory: 188.0K
CPU: 12ms
CGroup: /system.slice/proc-sys-fs-binfmt_misc.mount
● proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File
System
Loaded: loaded (/proc/self/mountinfo; disabled; vendor preset:
disabled)
Active: active (mounted) since Thu 2020-07-23 18:36:17 BST; 4 days ago
TriggeredBy: ● proc-sys-fs-binfmt_misc.automount
Where: /proc/sys/fs/binfmt_misc
What: binfmt_misc
Docs:
https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
Tasks: 0 (limit: 154244)
Memory: 188.0K
CPU: 12ms
CGroup: /system.slice/proc-sys-fs-binfmt_misc.mount
Probably .. because as you see there are two units for binfmt_misc.
One is just a static/regular .mount unit and the second one which is using
autofs.
IMO using automounter to mount sysfs, procfs and binfmt_misc is really
OVERKILL.
If the regular unit works flawlessly it looks like systemd could be
compiled without autofs.
For example mqueue is mounted over .mount unit
$ cat /usr/lib/systemd/system/dev-mqueue.mount | grep -v \#
[Unit]
Description=POSIX Message Queue File System
Documentation=man:mq_overview(7)
Documentation=
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
DefaultDependencies=no
Before=sysinit.target
ConditionPathExists=/proc/sys/fs/mqueue
ConditionCapability=CAP_SYS_ADMIN
[Mount]
What=mqueue
Where=/dev/mqueue
Type=mqueue
Options=nosuid,nodev,noexec
Looks like all other pseudo filesystems are mounted over .mount units with
probably one exception .. binfmt_misc.
Probably .. because as I've pointed there are two units for that fs.
$ rpm -ql systemd | grep \\.mount$
/usr/lib/systemd/system/dev-hugepages.mount
/usr/lib/systemd/system/dev-mqueue.mount
/usr/lib/systemd/system/local-fs.target.wants/tmp.mount
/usr/lib/systemd/system/proc-sys-fs-binfmt_misc.mount
/usr/lib/systemd/system/sys-fs-fuse-connections.mount
/usr/lib/systemd/system/sys-kernel-config.mount
/usr/lib/systemd/system/sys-kernel-debug.mount
/usr/lib/systemd/system/sys-kernel-tracing.mount
/usr/lib/systemd/system/sysinit.target.wants/dev-hugepages.mount
/usr/lib/systemd/system/sysinit.target.wants/dev-mqueue.mount
/usr/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
/usr/lib/systemd/system/sysinit.target.wants/sys-kernel-config.mount
/usr/lib/systemd/system/sysinit.target.wants/sys-kernel-debug.mount
/usr/lib/systemd/system/sysinit.target.wants/sys-kernel-tracing.mount
/usr/lib/systemd/system/tmp.mount
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
7:18 a.m.
On Di, 28.07.20 13:02, Tomasz Kłoczko (kloczko.tomasz(a)gmail.com) wrote:
So .. someone knows why it cannot be mounted on "mount -a"
when entry
for binfmt_misc would be in fstab or even over .mount unit?
You can do that, of course, but binfmt_misc is a .ko we don't want to
load unless needed.
With the scheme we have right now we'll load it only when someone
fiddles with the binfmt_misc dir.
IMO using automounter to mount sysfs, procfs and binfmt_misc is
really
OVERKILL.
We don't use the automounter for sysfs or procfs, that would make
little sense. These file systems are mounted early on from PID 1,
before doing pretty much anything else, since much of the Linux
kernel's API we need is exposed through these virtual file systems.
binfmt_misc is kinda an exotic feature though, and unless you install
java or mono or qemu for foreign archs you are unlikely to use it.
If the regular unit works flawlessly it looks like systemd could be
compiled without autofs.
You can compile it without autofs. But why bother? it's tiny and useful.
For example mqueue is mounted over .mount unit
$ cat /usr/lib/systemd/system/dev-mqueue.mount | grep -v \#
[Unit]
Description=POSIX Message Queue File System
Documentation=man:mq_overview(7)
Documentation=
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
DefaultDependencies=no
Before=sysinit.target
ConditionPathExists=/proc/sys/fs/mqueue
ConditionCapability=CAP_SYS_ADMIN
[Mount]
What=mqueue
Where=/dev/mqueue
Type=mqueue
Options=nosuid,nodev,noexec
Looks like all other pseudo filesystems are mounted over .mount units with
probably one exception .. binfmt_misc.
Probably .. because as I've pointed there are two units for that fs.
Only binfmt_misc is typically a kernel module of its own. For stuff
that is built-in it's pointless trying to avoid module loading.
Lennart
--
Lennart Poettering, Berlin
8:56 a.m.
On Tue, 28 Jul 2020 at 13:22, Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
[..]
> Looks like all other pseudo filesystems are mounted over .mount
units
with
> probably one exception .. binfmt_misc.
> Probably .. because as I've pointed there are two units for that fs.
Only binfmt_misc is typically a kernel module of its own. For stuff
that is built-in it's pointless trying to avoid module loading.
https://www.investopedia.com/terms/d/death-1000-cuts.asp
Alternatively it is possible to use here KISS or Okhan Razor.
If in case of things like full scale distribution you don't care about
details sooner or later bad things will start.
I'm not talking about modularisation of the binfmt_misc (which IIRC is
possible to compile as the module).
I'm talking about currently compiled into the kernel autofs support (and
building it as the loadable module).
In this case it looks like already mounting binfmt_misc over the existing
(dist) .mount unit is in place.
And going back to the original question.
Why not provide the kernel with all possible to use file systems which are
possible to use as root fs as modules?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
1366
days inactive
1367
days old
13 comments
5 participants
participants (5)
-
Chris Murphy -
Lennart Poettering -
Neal Gompa -
Tomasz Kłoczko -
Zbigniew Jędrzejewski-Szmek