Hi,
>From systemd code, if kexec kernel is loaded, executing 'reboot' will
finally enter into reboot system call with KEXEC action. Wondering why
it has to invoke kexec command.
Asking this because in redhat CKI testing, one test case is 'kexec reboot'.
Now it's always failed and the relevant log
On Tue, 2021-01-26 at 11:33 +0100, Lennart Poettering wrote:
>
> >
> > [Unit]
> > Description=NVMe Event Monitor for Automatical Subsystem Connection
> > Documentation=man:nvme-monitor(1)
> > DefaultDependencies=false
> > Conflicts=shutdown.target
> > Requires=systemd-udevd-kernel.socket
> > Afte
Is it possible for a udev rule to have a timeout? For example:
/usr/lib/udev/rules.d/64-btrfs.rules
This udev rule will wait indefinitely for a missing device to appear.
It'd be better if it gives up at some point and drops to a dracut
shell. Is that possible? The only alternative right now is the
On Mi, 27.01.21 21:51, Martin Wilck (mwi...@suse.com) wrote:
> Meanwhile I've looked a bit deeper into the problems accessing "/dev"
> that I talked about in my other post. scandir on "/" actually returns
> an empty directory after switching root, and any path lookups for
> absolute paths fail. I
I was probably too hasty in saying it's the upstream resolver's fault --
it's still systemd-resolved which makes the two A and queries and
aggregates their responses. The upstream just happens to choose different
nameservers for both, but that's normal operation.
Either way, I'd mostly blame
On Wed, 2021-01-27 at 13:10 +0200, Mantas Mikulėnas wrote:
> So it is entirely possible that when resolved makes two queries, one
> for A records and another for , it receives conflicting
> information about the target simultaneously being an alias and not
> being an alias (due to your upstream
I would guess the *upstream *server used by resolved is reacting negatively
to weirdness in O365 authoritative DNS.
* outlook.office365.com is indeed an alias (CNAME) for
outlook.ha.office365.com.
* The domain ha.office365.com has two sets of nameservers: ns{1..4}-
ms-acdc.office.com and tm{1..2}.
Heya,
I was confronted with a weird problem this morning. On my location
there is only IPv4 available. My company uses the shiny new Office365
service for email. This morning I was not able to connect to my email
account. The reason was systemd-resolved returning only IPv6 addresses
for the email
On Tue, 26 Jan 2021 11:40:31 -0800
Kian Kasad wrote:
> On 21/01/26 02:06PM, Pekka Paalanen wrote:
> > On Tue, 26 Jan 2021 01:43:43 -0800
> > Kian Kasad wrote:
> >
> > > Hi all,
> > >
> > > After reading the documentation on logind and multi-seat (specifically
> > > sd-login(3) and "Multi-Sea
