• [gentoo-user] systemd-boot on openrc

    From Peter Humphrey@21:1/5 to All on Sun Apr 17 13:50:01 2022
    Hello list,

    I've been using bootctl from sys-boot/systemd-boot for several years, with
    some success, but I'm stuck after today's --sync.

    First I was told I had to keyword sys-apps/systemd-utils, so I did that, but now I get this, which I can't decode:

    Calculating dependencies ... . ..... done!
    [ebuild N ~] sys-apps/systemd-utils-250.4::gentoo USE="boot (split-usr) sysusers tmpfiles udev (-selinux) -test" ABI_X86="(64) -32 (-x32)" 10,872 KiB [ebuild U ~] sys-boot/systemd-boot-250::gentoo [249.9::gentoo] 0 KiB [blocks b ] <sys-boot/systemd-boot-250 ("<sys-boot/systemd-boot-250" is soft blocking sys-apps/systemd-utils-250.4)
    [blocks B ] <sys-apps/systemd-tmpfiles-250 ("<sys-apps/systemd- tmpfiles-250" is soft blocking sys-apps/systemd-utils-250.4)
    [blocks B ] <sys-fs/udev-250 ("<sys-fs/udev-250" is soft blocking sys- apps/systemd-utils-250.4)

    Total: 2 packages (1 upgrade, 1 new), Size of downloads: 10,872 KiB
    Conflict: 3 blocks (2 unsatisfied)

    * Error: The above package list contains packages which cannot be
    * installed at the same time on the same system.

    (sys-apps/systemd-tmpfiles-249.9-2:0/0::gentoo, installed) pulled in by
    sys-apps/systemd-tmpfiles required by (virtual/tmpfiles-0-r1-1:0/0::gentoo, installed) USE="" ABI_X86="(64)"

    (sys-apps/systemd-utils-250.4:0/0::gentoo, ebuild scheduled for merge)
    pulled in by
    sys-apps/systemd-utils[udev] required by (sys-boot/systemd- boot-250:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64)"

    (sys-fs/udev-249.6-r2-3:0/0::gentoo, installed) pulled in by
    >=sys-fs/ udev-232:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
    =sys-fs/udev-232:0/0[abi_x86_64(-)]) required by (virtual/libudev-232- r5-2:0/1::gentoo, installed) USE="-systemd" ABI_X86="(64) -32 (-x32)"
    >=sys-fs/udev-217 required by (virtual/udev-217-r3-1:0/0::gentoo, installed) USE="" ABI_X86="(64)"

    This is an amd64 openrc system. On another system, ~amd64 openrc, I was told
    to set USE=boot on systemd-utils, so I did that and now when I boot I have no mouse or keyboard.

    Is this the end of the road for systemd-boot on openrc?

    --
    Regards,
    Peter.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Humphrey@21:1/5 to All on Sun Apr 17 15:10:01 2022
    On Sunday, 17 April 2022 12:13:06 -00 Neil Bothwick wrote:

    8
    It looks like this is cause my using mixed keywords, amd64 for udev and ~amd64 for systemd-boot/utils. Does keywording udev-250 resolve the
    blocks?

    Yes, after keywording several others, thus:

    ~sys-apps/systemd-tmpfiles-249.9
    ~sys-apps/systemd-utils-250.4
    ~sys-fs/udev-250
    ~virtual/tmpfiles-0-r2

    But then, after rebooting because of the udev update, systemd-boot-250-r1 has come in. I can't revert those keywords though, because then I'd have to ditch elogind in favour of systemd. I really do not want to do that.

    So I have a running system now - thanks. If this gets more complicated in future, I can always try blocking =>sys-boot/systemd-boot-250.

    On another system, ~amd64 openrc, I was
    told to set USE=boot on systemd-utils, so I did that and now when I
    boot I have no mouse or keyboard.

    Is this the end of the road for systemd-boot on openrc?

    I think that USE flag just causes the systemd-boot part of systemd-utils
    to be built. systemd-boot itself is just a virtual now. It doesn't sound
    like that would cause this problem, did you emerge anything X related at
    the same time?

    Nope, nothing else. And I forgot to say that smartd failed to start on that machine too, with nothing in dmesg or /var/log/messages. (I'm working on that machine via ssh.)

    --
    Regards,
    Peter.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Neil Bothwick@21:1/5 to Peter Humphrey on Sun Apr 17 14:20:01 2022
    On Sun, 17 Apr 2022 11:41:23 +0000, Peter Humphrey wrote:

    I've been using bootctl from sys-boot/systemd-boot for several years,
    with some success, but I'm stuck after today's --sync.

    First I was told I had to keyword sys-apps/systemd-utils, so I did
    that, but now I get this, which I can't decode:

    Calculating dependencies ... . ..... done!
    [ebuild N ~] sys-apps/systemd-utils-250.4::gentoo USE="boot
    (split-usr) sysusers tmpfiles udev (-selinux) -test" ABI_X86="(64) -32 (-x32)" 10,872 KiB [ebuild U ~] sys-boot/systemd-boot-250::gentoo [249.9::gentoo] 0 KiB [blocks b ] <sys-boot/systemd-boot-250 ("<sys-boot/systemd-boot-250" is soft blocking
    sys-apps/systemd-utils-250.4) [blocks B ]
    <sys-apps/systemd-tmpfiles-250 ("<sys-apps/systemd- tmpfiles-250" is
    soft blocking sys-apps/systemd-utils-250.4) [blocks B ]
    <sys-fs/udev-250 ("<sys-fs/udev-250" is soft blocking sys- apps/systemd-utils-250.4)

    Total: 2 packages (1 upgrade, 1 new), Size of downloads: 10,872 KiB
    Conflict: 3 blocks (2 unsatisfied)

    * Error: The above package list contains packages which cannot be
    * installed at the same time on the same system.

    (sys-apps/systemd-tmpfiles-249.9-2:0/0::gentoo, installed) pulled in
    by sys-apps/systemd-tmpfiles required by (virtual/tmpfiles-0-r1-1:0/0::gentoo, installed) USE="" ABI_X86="(64)"

    (sys-apps/systemd-utils-250.4:0/0::gentoo, ebuild scheduled for
    merge) pulled in by
    sys-apps/systemd-utils[udev] required by (sys-boot/systemd- boot-250:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64)"

    (sys-fs/udev-249.6-r2-3:0/0::gentoo, installed) pulled in by
    >=sys-fs/ udev-232:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
    =sys-fs/udev-232:0/0[abi_x86_64(-)]) required by
    (virtual/libudev-232- r5-2:0/1::gentoo, installed) USE="-systemd" ABI_X86="(64) -32 (-x32)"
    >=sys-fs/udev-217 required by (virtual/udev-217-r3-1:0/0::gentoo, installed) USE="" ABI_X86="(64)"

    This is an amd64 openrc system.

    It looks like this is cause my using mixed keywords, amd64 for udev and
    ~amd64 for systemd-boot/utils. Does keywording udev-250 resolve the
    blocks?

    On another system, ~amd64 openrc, I was
    told to set USE=boot on systemd-utils, so I did that and now when I
    boot I have no mouse or keyboard.

    Is this the end of the road for systemd-boot on openrc?

    I think that USE flag just causes the systemd-boot part of systemd-utils
    to be built. systemd-boot itself is just a virtual now. It doesn't sound
    like that would cause this problem, did you emerge anything X related at
    the same time?


    --
    Neil Bothwick

    without C people would code in Basi, Pasal and Obol

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmJcBFIACgkQ92eFu0QS MJjBsg/8Cbl1O93dQZ/L/IVZbp9pTFK5DGjASRG1GpfCKZDCb4aDpRu7DN4Hrqot mFnAOcvxSzDvBYA/1SzvAGRJvwpJ9IpJoCFl7HeRMd2C7MNys5gJBm492GsrnjJp t0Sse40VKSVwZFWkTkmWildklfe7hVQssazQC4zxhjPAS+o8tojfKGFyGlbOAir6 59kN60KlJur03yv5uvDgalmdFNmtRFtpUWlMGuzTgi8pF0eeOeh3enM8TZcR4oCO PGELFvDNsxpA1MPdm7WhLPCInAdEJAACyc1+zFStb3gLKkKLjZVjhrfuiVrtsfI2 cIhAFVwZ6d4rjwNuDtGybedldtUN1KlZB0PZJ2Fk0KBDjYfw148NxRGelzPgjD5D qaNja/mZsIjZDBIhr0eUpJlThXu6EswAQu9LEoN4KVXDrSnGNaW2+RC9t3CBqG/j pkh9UaYsFFNga0LWibeyPUjGBWcVAm8Kox39AxmaNUmvSNULbbj3Q5+gDmdef2lu AjGJkEyhNvuwJzO2jV0CxrwVx0yiF+T20zFoOv8V/9Wiz3aYUPfhSSukS7GWSxB4 7+bsMEB7DOUiUgkeHfBuR1w+sRgoCBvJnI10G+vitesHjzjp1xPCXgNPMr3X1E8W SWyTM0+GuaG2j8C/WwtlCBx2nleoRAnRywSmju8TMl+ls/7W27I=
    =Iwxz
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich Freeman@21:1/5 to peter@prh.myzen.co.uk on Sun Apr 17 17:00:01 2022
    On Sun, Apr 17, 2022 at 9:03 AM Peter Humphrey <peter@prh.myzen.co.uk> wrote:

    On Sunday, 17 April 2022 12:13:06 -00 Neil Bothwick wrote:

    8
    It looks like this is cause my using mixed keywords, amd64 for udev and ~amd64 for systemd-boot/utils. Does keywording udev-250 resolve the
    blocks?

    Yes, after keywording several others, thus:

    ~sys-apps/systemd-tmpfiles-249.9
    ~sys-apps/systemd-utils-250.4
    ~sys-fs/udev-250
    ~virtual/tmpfiles-0-r2

    But then, after rebooting because of the udev update, systemd-boot-250-r1 has come in. I can't revert those keywords though, because then I'd have to ditch elogind in favour of systemd. I really do not want to do that.

    Can't you just fix your USE flags with systemd-utils? Why revert?

    If I need to bump a package up to ~arch temporarily usually I just do
    it with an atom like "<sys-apps/systemd-utils-251" or something like
    that, so that I keep getting ~arch updates within the major version,
    but the next major bump happens when it hits stable. Obviously you
    need to understand the versioning/stabilization policies for the
    packages involved if you do that, and it is situational, but you
    really shouldn't be mixing keywords anyway unless you're comfortable
    with that.

    --
    Rich

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Humphrey@21:1/5 to All on Sun Apr 17 17:40:02 2022
    On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
    On Sun, Apr 17, 2022 at 9:03 AM Peter Humphrey <peter@prh.myzen.co.uk>
    wrote:
    On Sunday, 17 April 2022 12:13:06 -00 Neil Bothwick wrote:

    8

    It looks like this is cause my using mixed keywords, amd64 for udev and ~amd64 for systemd-boot/utils. Does keywording udev-250 resolve the blocks?

    Yes, after keywording several others, thus:

    ~sys-apps/systemd-tmpfiles-249.9
    ~sys-apps/systemd-utils-250.4
    ~sys-fs/udev-250
    ~virtual/tmpfiles-0-r2

    But then, after rebooting because of the udev update, systemd-boot-250-r1 has come in. I can't revert those keywords though, because then I'd have
    to ditch elogind in favour of systemd. I really do not want to do that.

    Can't you just fix your USE flags with systemd-utils? Why revert?

    No, because the flag I'd need is 'boot', and that triggers switching from elogind to systemd.

    If I need to bump a package up to ~arch temporarily usually I just do
    it with an atom like "<sys-apps/systemd-utils-251" or something like
    that, so that I keep getting ~arch updates within the major version,
    but the next major bump happens when it hits stable. Obviously you
    need to understand the versioning/stabilization policies for the
    packages involved if you do that, and it is situational, but you
    really shouldn't be mixing keywords anyway unless you're comfortable
    with that.

    No, I know it's a bad idea to mix keywords, but how else do I get systemd-boot on a stable system?

    --
    Regards,
    Peter.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)