Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Daniel J. R. May
On Fri, 2020-10-16 at 15:16 +0200, Lennart Poettering wrote: > So the btrfs ready ioctl is called and the device considered by the > kernel btrfs implementation to be ready > (i.e. assembled from all component devices) with this line: > > [ 27.804250] systemd-udevd[712]: sde: >

Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Andrei Borzenkov
16.10.2020 18:51, Lennart Poettering пишет: >> >> Ths btrfs udev rule file appears to be missing in the initrd. The >> block devices with the btrfs file systems on them will thus be marked >> ready in systemd instantly instead of being delayed until all other >> devices of the same btrfs fs have

Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Michał Zegan
As a workaround I am almost sure you can instruct dracut to include the file, can't you? W dniu 16.10.2020 o 17:45, Lennart Poettering pisze: > On Fr, 16.10.20 16:26, Daniel J. R. May (daniel@danieljrmay.com) wrote: > >> On Fri, 2020-10-16 at 15:16 +0200, Lennart Poettering wrote: >>> So the

[systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Daniel J. R. May
On Mon, 12 Oct 2020 14:42:18 -0600 Chris Murphy wrote: > I'll have him retry with udev.log_priority=debug and if I get a moment > I'll try to reproduce. The difficulty is reproducing truly missing > devices is easy and appears to work, whereas in this case they are > merely late being scanned for

Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Lennart Poettering
On Fr, 16.10.20 17:45, Lennart Poettering (lenn...@poettering.net) wrote: > > 2. Debugging with "rd.udev.debug systemd.log_level=debug": > > The same 10 HDD BTRFS volume with 4 drives connected to the motherboard > > and 6 drives connected to the HBA *fails* to mount automatically at boot > >

Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Lennart Poettering
On Fr, 16.10.20 16:26, Daniel J. R. May (daniel@danieljrmay.com) wrote: > On Fri, 2020-10-16 at 15:16 +0200, Lennart Poettering wrote: > > So the btrfs ready ioctl is called and the device considered by the > > kernel btrfs implementation to be ready > > (i.e. assembled from all component

Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-16 Thread Mantas Mikulėnas
On Fri, Oct 16, 2020 at 4:13 PM Thomas HUMMEL wrote: > > On 16/10/2020 13:22, Mantas Mikulėnas wrote: > > > But I think you're still confusing the two different kinds of "sessions" > > that exist here. PAM open_session creates a PAM session, which > > eventually *causes* a systemd-logind session

Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Lennart Poettering
On Mo, 12.10.20 14:42, Chris Murphy (li...@colorremedies.com) wrote: > > When precisely it returns success or failure is entirely up to the btrfs > > kernel > > code. systemd/udev doesn't have any control on that. The udev btrfs > > builtin is too trivial for that: it just calls the ioctl and

Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Lennart Poettering
On Fr, 16.10.20 13:21, Daniel J. R. May (daniel@danieljrmay.com) wrote: > Log available here: > https://drive.google.com/file/d/1-x26JS5gcZxwZx7zWoKduEg9ycwUHKqO/view?usp=sharing So the btrfs ready ioctl is called and the device considered by the kernel btrfs implementation to be ready

Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-16 Thread Thomas HUMMEL
On 16/10/2020 13:22, Mantas Mikulėnas wrote: But I think you're still confusing the two different kinds of "sessions" that exist here. PAM open_session creates a PAM session, which eventually *causes* a systemd-logind session to be created, but isn't 100% the same thing. Yes I probably

Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-16 Thread Mantas Mikulėnas
On Fri, Oct 16, 2020 at 1:41 PM Thomas HUMMEL wrote: > Hello, > > if I try to sum up all of your answers, I come to the following > understanding : > > - sessions are always created via the pam_systemd module > - which is, in my case called (sshd, crond) via the password-auth stack > include > -

Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-16 Thread Thomas HUMMEL
Hello, if I try to sum up all of your answers, I come to the following understanding : - sessions are always created via the pam_systemd module - which is, in my case called (sshd, crond) via the password-auth stack include - so crond, through pam_systemd will cause a session to be created

Re: [systemd-devel] Issue regarding running systemd under a container

2020-10-16 Thread Atul Singh
Hello systemd-devel, I am working to dockerize the buildroot based rootfs. While dockerization if I run the container with privilege mode am able to run the container and it works fine. But, when I try to run/restart other containers I get the below error message during docker run. Please

[systemd-devel] Antw: [EXT] Re: "Eye Of Cylon" animation no longer garbles Ctrl-Alt-F9 emergency shell ?

2020-10-16 Thread Ulrich Windl
>>> fox schrieb am 15.10.2020 um 23:36 in Nachricht : >> > It is refreshing to see that the Cylon eye is appearantly no longer >>> making the Ctrl-Alt-F9 emergency shell unusable. > > while I noted that a modified systemd is quick to install, I also should > point out that a compile + install