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:
>
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
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
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
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
> >
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
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
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
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
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
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
> -
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
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
>>> 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
14 matches
Mail list logo