think DefaultMemoryHigh=75% would be an OK
approach which would allow us adjust to the "beefiness" of a machine
automatically.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an e
very
recent. For example, the pre-boot random seed stuff has been added in
v243, of which we only posted an -rc1 so far,
However, the basics have been around very early on, yes.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list --
o how the majority does it, not necessarily just how
RPM likes it, unless the software is clearly focussed on the RPM world
only.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an ema
the rules then
"-rc1" is as OK as "-rc.1", the only difference being that the former
is *one* dot separated identifier, and the latter are *two* dot
separated identifiers, but both are OK according to the spec.
Lennart
--
Lennart Poettering, Berlin
Lennart did not see, is that all this
> lack of care, results in longer breakage time in Fedora.
Well, I am pretty sure (like most RPMs) ours could use more love and
dedication, but there are only so many people working on this and only
24h in a day. If you feel it needs more love, then volu
ined outside of the
main repo:
https://github.com/systemd/systemd-stable
Either way, I doubt this discussion is relevant to Fedora, is it?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe se
posed as a
file system. RPM should not own files below /proc. Something should
own/create /proc itself, since it needs to exist to be overmounted
with procfs, but beyond that stuff below /proc should be off limits
for any package manager I figure.
Lennart
--
Lennart Poettering, Berlin
_
he system boot.
That said, that only works if / is writable. Which is not a given.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Cod
. I've got
> no idea why systemd doesn't see it.
Wat does udevadm info on the block device node say? i.e. does the
device carry the right tag, does it have SYSTEMD_READY=0 set?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing lis
ERFACE
Unfortunately, Fedora/grub do not support either.
(Which is a pity of course, since it also means there's no working
"systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl
kexec" support).
Lennart
--
Lennart Poettering, Berlin
___
aptop.
You probably need some base RPM to own the dir /usr/lib64/pkgconfig then,
which is currently owned by pkgconf-pkg-config, no?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
On Do, 25.04.19 13:14, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> On 4/25/19 5:14 AM, Lennart Poettering wrote:
> > For the hashtable seeds we use classic /dev/urandom (i.e. entropy from
> > a possibly non-initialized pool) since it's OK if those seeds are
>
On Mi, 24.04.19 17:28, Björn Persson (Bjorn@rombobjörn.se) wrote:
> Lennart Poettering wrote:
> >As mentioned before: systemd itself already needs entropy itself (it
> >assigns a random 128bit id to each service invocation, dubbed the
> >"invocation ID" of it, and
pool) since it's OK if those seeds are
crappy initially, as long as they get better over time, since we
reseed if we see too many hash collisions.
We never use /dev/random or GRND_RANDOM.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing
t. Very low-hanging in fact, you don't get to fix bugs that often
by inserting a single character in your sources... ;-)
I mean, how is this ever going to be fixed if not by simply dropping
rngd from the default install and then fixing everything poppi
temd
is invoked. i.e. not as regular service, but as kind of an init before
the real init.
The current mode is just entirely bogus...
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe sen
ng rngd
afterwards? To reach the point where rngd can be run we already need
the pool to be full, and hence rngd can't do any good at all anymore,
whatsoever.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.
On Mi, 24.04.19 12:02, Nikos Mavrogiannopoulos (n...@redhat.com) wrote:
> On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering
> wrote:
> > Sure, you can invoke rngd before systemd, in which case it would have
> > to be able to run as PID 1 itself pretty much and then ha
ll, "jarsigner" is broken then. It appears to use /dev/random
instead of /dev/urandom. if you use the latter, then you can pull out
as much randomness as you want, it's not affected by "entropy
depletion".
See man page about that:
http://man7.
On Do, 18.04.19 09:16, stan (upai...@zoho.com) wrote:
> On Thu, 18 Apr 2019 10:22:27 +0200
> Lennart Poettering wrote:
>
> > On Mi, 17.04.19 11:29, Japheth Cleaver (clea...@terabithia.org) wrote:
>
> > > This seems like a false dichotomy, no? Surely, things like t
ly for each driver judging by how much the
device is trusted or not.
(Also note that virtio-rng is something systemd automatically loads if
it's not around but the environment would support it, and it appears
to credit entropy too.)
Lennart
--
Lennart Poettering, Berlin
___
On Mi, 17.04.19 16:05, Chris Murphy (li...@colorremedies.com) wrote:
> On Wed, Apr 17, 2019 at 11:36 AM Lennart Poettering
> wrote:
> >
> > Yeah, all that stuff is stuff the kernel could do better on its
> > own. If the CPU jitter stuff or the TPM stuff is a good idea, t
seconds, hit ctl-c to kill cat. Watch what happens to the
> entropy.
Well, don't use /dev/random. Use /dev/urandom. The official
documentation declares /dev/random a "legacy interface".
http://man7.org/linux/man-pages/man4/random.4.html
Lennart
--
Lennart Poettering, Berlin
__
On Mi, 17.04.19 11:29, Japheth Cleaver (clea...@terabithia.org) wrote:
> On 4/17/2019 10:36 AM, Lennart Poettering wrote:
> > On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote:
> >
> > > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
>
On Mi, 17.04.19 13:01, Jason L Tibbitts III (ti...@math.uh.edu) wrote:
> >>>>> "LP" == Lennart Poettering writes:
>
> LP> That's not true anymore. There's a kernel compile time option now
> LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And
On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote:
> On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
> >
> >
> > > > I think all of these are good ide
s that
super early). So, why run a service that is supposed to fill up the
entropy pool at a point where we don't need it anymore, and if the
kernel can do what it does most likely already on its own?
Isn't it time to kick rngd out of the default install, in particular
on the wo
the script that
> is being run in an audit event.
To my knowledge audit collects the comm name of any process already, no?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel
nstalled won't break Chrome as it will
> just ignore the 'at' command execution error due to 'exit 0' a few
> lines below it.
Just out of curiosity, why does a web browser need a daily chrome job?
Lennart
--
Lennart Poettering, Berlin
_
it allows users in "wheel" to do a lot of stuff
without password. We require "auth_admin_keep" from pk for the action
of enabling lingering.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.or
ad of PID 1) then it is
lifecycled (and its processes killed as needed) by the user service
manager. And you can configure the way you want killing to behave like
you would for any systemd service: with KillMode= in the unit file.
Lennart
--
Lennart Poettering, Berlin
___
On Do, 11.04.19 11:32, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> On 4/11/19 10:16 AM, Lennart Poettering wrote:
> > However, that's intended for system services only (i.e. for services
> > running as users UID < 1000). For regular users (i.e. human ones,
>
ver was the intention of to provide the exact same feature set as
cron. And I wouldn't push users who want cron to use systemd timers
instead. But I'd say the semantics and security model we expose in
systemd timers is actually better fitting for the various housekeeping
jobs we ship a
activation-on-socket + activation-on-hardware +
activation-on-anything-else can be nicely done for the same service.
Or to say this even differently: service activation in systemd is
substantially more powerful than in inetd: it's not exclusively about
*on-demand* socket activation, but sock
atus=226/NAMESPACE)
Follow-up on this:
This does sound a lot like a different iteration of this:
https://hansdegoede.livejournal.com/20910.html
i.e. turning off enforcing mode might have solved the issue for you.
Lennart
--
Lennart Poettering, Berlin
ennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
cularly special though...
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-c
staller needs them.
I mean, it could be as easy that these services remain off, but the
installer does a "systemctl enable --now …" on them as soon as it
notices it needs them. That way the livesys and the host installed
version can be 100% identical
great, yes.
Those scripts, can't we make them part of some RPM btw? I filed a bug
about that yesterday:
https://bugzilla.redhat.com/show_bug.cgi?id=1698119
These scripts are a bit annoying since they are the only SysV scripts
left really (not even LSB!), have no purposes on an installed
On Di, 09.04.19 20:12, Richard Hughes (hughsi...@gmail.com) wrote:
> On Tue, 9 Apr 2019 at 19:27, Lennart Poettering wrote:
> > Hmm? Can you elaborate? Why does fwupd's runtime have something to do
> > with display flickers? Not grokking the connection?
>
> M
On Di, 09.04.19 19:24, Richard Hughes (hughsi...@gmail.com) wrote:
> On Tue, 9 Apr 2019 at 19:21, Lennart Poettering wrote:
> > Very similar is actually "fwupd", why does that need to run all the
> > time? Seems like something that should be bus activatable, and
> &g
On Di, 09.04.19 14:16, Cole Robinson (crobi...@redhat.com) wrote:
> On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
> >> multipathd [...] And beyond that, this daemon is really ugly too: it logs
&
lly "fwupd", why does that need to run all the
time? Seems like something that should be bus activatable, and
exit-on-idle, but why run it all the time?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedorap
can't
because the dir doesn't actually exist.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://ge
On Di, 09.04.19 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
> > multipathd [...] And beyond that, this daemon is really ugly too: it logs
> >at high log levels during boot that it found n
Heya,
today I installed the current Fedora 30 Workstation beta on my new
laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
crashed five times or so on me, always kicking me out of anaconda
again, just because I wanted to undo something). But I don't really
want to discuss that. Wh
in a given snap reliably enough.
Well, the SIGSTOP thing is racy: processes can fork() quicker than you
can pause them. Together with the pids controller you should be fine
though, as you can put a limit on forks.
Lennart
--
Lennart Poettering, Red Hat
___
sv2 since day one
basically, at the same day it was introduced for cgroupsv1.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
re page suggests the installer would switch from cgroupsv1 to
cgroupsv2.
My suggestion would instead be to simply update the systemd RPM to
pass slightly different params to meson, to make cgroupsv2 the new
default.
Lennart
--
Lennart Poettering, Red Hat
__
e every month
3. systems that survive a week
4. systems that survive a month
(And of course all stats derived from the above: systems that didn't
survive the first week, and so on).
Lennart
--
Lennart Poettering, Red Hat
___
de
On Di, 08.01.19 16:22, Lennart Poettering (mzerq...@0pointer.de) wrote:
> On Di, 08.01.19 07:49, Stephen John Smoogen (smo...@gmail.com) wrote:
>
> > The additional information could be
> >
> > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
> > /metal
(Footnote: ¹ if you are concerned that not every client is updated
every week, then you could even slightly extend this and maybe submit
countme=2 the first time within each 4 week period, and countme=3
within each 52 week period, so that you you catch even those though it
will take a bit longer
On Di, 08.01.19 10:11, Richard Hughes (hughsi...@gmail.com) wrote:
> On Tue, 8 Jan 2019 at 08:57, Lennart Poettering wrote:
> > Yes, Tom's proposal makes sense. Calculate the UUID you submit as
> > HMAC(machined_id, CONCAT(fixedappuuid, unixtime/432000))
>
> Out o
On Mo, 07.01.19 22:54, Tom Gundersen (t...@jklm.no) wrote:
> On Mon, Jan 7, 2019, 7:31 PM Matthew Miller
> wrote:
>
> > On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
> > > > * The Fedora community cares about privacy and is adverse to tracking
short time (which could be true with certain CI environments) or is it
> 1 system getting a short ip address lifetime?
Again, if you teach each system to only send one "1" ping per 24h and
only "0" pings otherwise it doesn't matter how many systems are behind
a single IP, b
On Mo, 07.01.19 16:04, John Harris (joh...@splentity.com) wrote:
> On Monday, January 7, 2019 3:18:10 PM EST Lennart Poettering wrote:
> > hence my recommendation to derive the any uuid for purposes like this
> > from /etc/machine-id, by using a HMAC of some kind (see other mail
On Mo, 07.01.19 13:28, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
> > > * The Fedora community cares about privacy and is adverse to tracking
> > > measures. We don't want to track; just count.
&
ion to derive the any uuid for purposes like this
from /etc/machine-id, by using a HMAC of some kind (see other mail).
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-l
27;s an OK limitation...
Of course, doing it that way would mean fedora would have to host NTP
servers...
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fe
llocate...
> We also need to figure out how to handle potential conflicts after
> administrative changes are pushed around from either a dynamic central
> system (AD/FreeIPA/LDAP) or a config managment system that only has a
> view on centrally mana
x27;t cause conflicts — as long as
everything is properly registered in NSS.
"adduser" registers from the range 1000…6 on Fedora by
default. DynamicUser=1 uses the range 61184…65519. systemd-nspawn uses
524288…1879048191. So these at least do not overlap.
Lennart
--
Lennart Poettering,
nnouncing allocated users with NSS is one thing,
it's something we always should do, unconditionally. It's only
reasonably way to announce you took possession of a range. Actually
allocating ranges is a different discussion. It's a discussion worth
having, but is un
he UID/GID range assumptions we
make:
https://systemd.io/UIDS-GIDS
I think it would be great if we could come to a better protocol for
taking possession of UID ranges in the long run. But I still think the
best database for such allocation should be NSS itself, right
now. What would be great if we&
ion that any component
taking possession off a user or a range of users it *must* show up in
NSS too, so that other components know.
I commented on the bug too.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.
Summary: I'd make things simple, and enable all four unconditionall
a, "I promise not to use select()") by bumping the
soft limit to the high limit.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje
, then everything would be
great (unfortunately the container messiness blocks that for now). But
as long as we don't, lifting the fd limit is not really making things
worse, given that there are tons of other easily exploitable ways to
acquire untracked memory...
Lennart
--
Lennart Poetterin
o that people can test this first across
the various development distros, before we propagate this to stable
distros.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@l
and the other
distros as soon as we do the next release.
https://github.com/systemd/systemd/pull/10244
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedo
On Di, 16.10.18 16:43, Miroslav Suchý (msu...@redhat.com) wrote:
> Dne 16.10.2018 v 16:11 Lennart Poettering napsal(a):
> > Quite frankly, you are doing it wrong.
>
> It's not me. It is either author of python-distro or mantainers of
> fedora-release.
> But you are
ossibly including a release
> code name, and suitable for presentation to the user. This field is optional.
> Example: "VERSION=17" or "VERSION="17
> (Beefy Miracle)"".
Quite frankly, you are doing it wrong. $VERSION is for display
purposes. $VERSION_
On Mo, 15.10.18 18:00, Kamil Paral (kpa...@redhat.com) wrote:
> On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering
> wrote:
>
> > On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote:
> >
> > > > It would be nice if somebody managed to find where
It is my intention to change this system wide, i.e. for system
services (which do not go through PAM) too.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fe
then I figure we should bump the systemd upstream to 1M
too. If it's #2, then I figure we can start with 256K as my PR
currently does, for now.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
open to suggestions there...
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.h
re looking for a way to get your own
per-user delegated cgroup subtree, simply ask systemd for it by
setting Delegate=yes in your service unit file, or by asking for
a scope unit to be registered, also with Delegate=yes set. Nothing
else is supported.
Lennart
--
Lennart Poettering, Red Hat
__
UEFI provides everything to make kernel
updates mostly safe.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: htt
er code not directory iterating
> code.
In the interest of minimal redundancy and compat with other
implementations of the spec, please stick to a single set of ids for
each entry, and according to the spec that's the file name. If you
have multiple id
wikipedia page it appears that support on Linux
has languished. the current versions of udf (2.50, 2.60, from 2003)
are only supported read-only? Is there an active community around udf
on Linux?
Quite frankly udf appears entirely unmaintained... I tried to track
down the location where mkud
, it's quite surprising we haven't implemented anything like
that on Fedora/RHEL at all yet, as it's a major piece in making
unattended system updates less risky.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- d
e complex access patterns on $BOOT. We
never change files, we just create them as one linear blob, and remove
them again. Both operations should totally be implementable in a
fail-save mode onm FAT.
Lennart
--
Lennart Poettering, Red Hat
___
is
clearly on its way out pretty much everywhere, and that since
years.
I mean, fat isn't really the epitome of file systems, but it *is*
generally very well supported, all across systems, and it's not really
on its way anywhere at all...
Lennart
--
Lennart Poettering,
On Mo, 25.06.18 11:54, Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Mon, Jun 25, 2018 at 12:47:35PM +0200, Lennart Poettering wrote:
> > On Mo, 25.06.18 11:23, Daniel P. Berrangé (berra...@redhat.com) wrote:
> >
> > > That would break applications like libguest
mage itself then they shouldn't really use
/boot anyway I figure, but instead the kernel in
/usr/lib/modules/`uname -r`/vmlinux. It's the same thing really.
Generally I think it'd be a good idea to ensure that only the boot
loader and tools setting up the boot loader would access /b
se in the mount options.
I mean, let's face it, the main stakeholder on $BOOT is not going to
honour the labels anyway, so I think it's only fair to treat the
whoile thing as a single security domain.
Lennart
--
Lennart Poettering, Red Hat
___
On Fr, 22.06.18 14:17, Chris Murphy (li...@colorremedies.com) wrote:
> On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering
> wrote:
> > On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
> >
> >> > Whereas constantly changing the
emented, as packages generally can't and shouldn't override
each other's files.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.or
on on this: instead of saying "must be
vfat" to say "must be firmware readable" essentially means the same,
but is friendlier towards MacOS of course. So yes, we should totally
relax the language on this, but not, using completely arbitrary file
systems on this certainly doesn&#x
should be entirely sufficient to store a
few kernels and their initrds. I mean, we build our kernels as EFI
binaries on Fedora, IIRC. Wouldn't it be a pity if EFI can't actually
access them, because they are stored on an fs only Linux speaks?
Lennart
--
Lennart Poettering, Red Hat
__
aming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- deve
ch already says! It says: merge it
if possible, split if if needed. How you define "possible" and
"needed" is up to you. All the spec tries to make sure though is that
once the decision is made for a specific image the other parties that
might want to process the entries know how
der the
very "$BOOT/loader/entries" name (just read it aloud, it tells you
exactly what this is), I doubt there's need to rename it now. it's not
that the namespace below $BOOT or ESP is particularly crowded,
anyway. Also, I like my bikesheds blue.
Lennart
--
Lennart Poe
probably be a while before that propagates into
fedora.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://ge
er spec?
Quite frankly, I am really surprised by this and this makes me wonder
what the whole point of this feature is at all, and very sure we
shouldn't have it like this.
Lennart
--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedor
$BOOT is that it is the common
ground pretty much everything involved in booting groks, if they grok
a file system at all. UEFI knows it, and so does the Raspberry Pi boot
protocol. The Linux initrd knows it and so does the Linux host OS,
Windows knows it. MacOS knows it. Grub knows it.
Lennart
--
in service activation if the service
isn't around yet at the time the client asks for the service. However,
judging by the provided logs
(https://openqa.stg.fedoraproject.org/tests/318564/file/_do_install_and_reboot-syslog)
the activation of the lvmdbus1 service actually completes fine.
Hence, thi
On Di, 19.06.18 11:14, Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, Jun 19, 2018 at 11:48:39AM +0200, Lennart Poettering wrote:
> > On Mo, 18.06.18 16:54, R P Herrold (herr...@owlriver.com) wrote:
> >
> > > On Mon, 18 Jun 2018, Lennart Poettering wro
On Mo, 18.06.18 16:54, R P Herrold (herr...@owlriver.com) wrote:
> On Mon, 18 Jun 2018, Lennart Poettering wrote:
>
> > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > The cited BLS spec is the original one, [1]
>
> ... later: L
On Mo, 18.06.18 16:50, Ondřej Lysoněk (olyso...@redhat.com) wrote:
> Hi,
>
> On 18.6.2018 15:27, Lennart Poettering wrote:
> > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> >
> >> The cited BLS spec is the original one, not the more thoroug
c2ff-59e6-4262-a352-b275fd6f7172, the generator will not automount
> it at /boot ?
systemd will do the discovery and automount unit generation only for
the ESP, and it's very defensive, i.e. it will never over-mount
neither /boot or /efi if there's anything in there, or if there'
301 - 400 of 1811 matches
Mail list logo
