• [gentoo-dev] News item for eudev deprecation

    From Joshua Kinard@21:1/5 to All on Mon Aug 23 21:30:01 2021
    On 8/23/2021 12:24, Michał Górny wrote:
    On Mon, 2021-08-23 at 16:36 +0200, Ulrich Mueller wrote:
    On Mon, 23 Aug 2021, Anthony G Basile wrote:

    **WARNING**

    If you happen to have an INSTALL_MASK with a blanket "*systemd*"
    glob, you will inevitably break your system. sys-fs/udev
    contains
    "systemd" in some of its filenames, hence a blanket filter rule
    will
    likely lead to a non-functional udev installation.

    Will an INSTALL_MASK of "/usr/lib/systemd /etc/systemd" cause any
    issues?

    I have not tested, but I think so since "systemd-" is used as a
    prefix
    for files installed by sys-fs/udev.

    So, we've abandoned the systemd USE flag, and I remember that one of
    the arguments was that users could use INSTALL_MASK for precisely the
    above mentioned directories.

    Now the message is that users' systems will be broken if they had
    followed our previous advice? Seriously?

    I'm pretty sure we've never officially advised anyone to remove
    important directories via INSTALL_MASK. INSTALL_MASK on unit
    directories will not affect udev users. On the other hand, if someone
    was overzealous and stripped whole /lib/systemd... no compassion from
    me, sorry.

    Digging around, I am pretty sure I picked up the INSTALL_MASK tip from something we put out. Only current info I can find so far is on the Wiki:

    https://wiki.gentoo.org/wiki/Gentoo_Without_systemd#systemd_unit_files

    History on that page goes back to 2014, but the first mention of
    INSTALL_MASK looks to have been added by the edit on 22 Sep 2018 @ 19:05: https://wiki.gentoo.org/index.php?title=Gentoo_Without_systemd&oldid=735246

    However, I know I've had the INSTALL_MASK lines on several of my machines
    for a few years before that. In any case, looking into my mail archives, it appears this bike shed has been painted over a few times before:

    2012: "Global Systemd USE Flag" https://archives.gentoo.org/gentoo-dev/message/5ca98a9af71db715fa68632ec1335755

    2014: "Possibility of overriding user defined INSTALL_MASK from an ebuild?" https://archives.gentoo.org/gentoo-dev/message/c20d9ada8e05dc1707f021ff01d28802

    Seems like the sane option is to just drop the INSTALL_MASK and deal with a gaggle of systemd unit files eating up some inode space. I obviously took umbrage once upon a time, but I guess the older you get, the less you care.

    --
    Joshua Kinard
    Gentoo/MIPS
    kumba@gentoo.org
    rsa6144/5C63F4E3F5C6C943 2015-04-27
    177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

    "The past tempts us, the present confuses us, the future frightens us. And
    our lives slip away, moment by moment, lost in that vast, terrible in-between."

    --Emperor Turhan, Centauri Republic

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jaco Kroon@21:1/5 to Anthony G. Basile on Tue Aug 24 12:30:02 2021
    Hi All,

    We run glibc based systems.  No musl.  But we don't use systemd.

    As little as a year back we still ran into issues with systemd-udev
    variant breaking systems, the fix of course was to nuke it and install
    eudev.  Are we certain there is nothing (eg, LVM integration was our
    biggest problem resulting in really crazy impossible to debug since we
    can't log in due to lvn snapshot creation/removal deadlocking with
    systemd-udev - no ask me not how, all I can tell you is that eudev never exhibited this behaviour) will break?

    Whilst I fully appreciate the difficult of all the various e* packages (elogind, eudev etc ..) and I most certainly do not have the capacity to maintain, and therefore I'm in full support of the concept of
    deprecating eudev, I'm very, very worried about us suddenly being back
    into the reboot-a-server-a-week scenario.  In the worst case we've lost
    some large filesystems almost certainly due to systemd-udev (we've had a
    number of filesystem crashes which was recovered with fsck, but after
    ditching systemd-udev and moving to eudev about two years back on this
    specific host we've had ZERO further problems other than a failed drive
    or two, none of which required a hard-reset to get back to a sane state).

    Kind Regards,
    Jaco

    On 2021/08/22 22:14, Anthony G. Basile wrote:
    Hi everyone,

    Yes! It is time to finally deprecate eudev! sys-fs/udev now builds
    under musl! My original purpose for maintaining eudev was because
    systemd + musl did not play well together when udev was absorbed into
    the sytemd repo. Now thanks to patches from openembedded, they do, and
    my original reason for maintaining eudev is no longer valid. So its
    time to retire eudev. It has served its purpose as a stop-gap.

    To me, this is a success for musl, and I would like to thank all the developers who have taken musl seriously enough to make this happen :)

    I am willing to transfer the eudev repo to another organization, but I
    will not maintain it anymore and Base System doesn't want to either.
    Let me warn people, to maintain it correctly you MUST become familiar
    with its internals and watch what systemd is doing upstream to keep up.
    This is not trivial. I learned a lot from eudev, and it did save musl
    on gentoo, but there was a period there when it was taking up almost all
    of my time. If you don't know what you're getting into, you don't want
    to take on its maintenance.



    Title: eudev retirement on 2022-01-01
    Author: Anthony G. Basile <blueness@gentoo.org>
    Posted: 2021-08-xx
    Revision: 1
    News-Item-Format: 2.0
    Display-If-Installed: sys-fs/eudev

    sys-fs/udev is becoming the standard provider of udev on non-systemd
    (e.g. OpenRC) systems. Users of systemd will continue to use the udev services provided by the sys-apps/systemd package itself.

    The transition should be uneventful in most cases, but please read this
    item in full to understand some possible corner cases.

    eudev will be retired and removed from Gentoo on 2022-01-01. We will
    start masking eudev on 2021-10-01 and give people 3 months to prepare
    their transition. You should ensure that sys-fs/eudev is not in your
    world file by running

    emerge --deselect sys-fs/eudev

    in order for Portage to replace eudev with sys-fs/udev once the
    package.mask is in place. We fully support udev on musl, whereas uclibc
    will still have to rely on eudev before also being removed on 2022-01-01.

    **WARNING**

    If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob,
    you will inevitably break your system. sys-fs/udev contains "systemd" in
    some of its filenames, hence a blanket filter rule will likely lead to a non-functional udev installation.

    Rationale

    The integration of udev into the systemd git repo introduced numerous problems for none-glibc systems, such as musl and uclibc. Several
    options were considered, and the one chosen was to fork and maintain
    udev independant of the rest of systemd. This was meant as a stop-gap solution until such time as the problems with systemd on musl had been resolved. This is now the case with patches provided by openembedded,
    and my original reason for maintaining eudev is no longer relevant.

    I am willing to transfer eudev to another umbrella organisation or Linux distribution that is willing to continue its maintenance, but
    maintaining eudev cannot be done purely through proxy-maintaining and requires an understanding of its internals. This is a steep learning
    curve and must be an earnest effort. For this reason, the Base System
    project has decided not to support euev as an option going forward.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony G. Basile@21:1/5 to Jaco Kroon on Tue Aug 24 14:00:01 2021
    On 8/24/21 6:24 AM, Jaco Kroon wrote:
    Hi All,

    We run glibc based systems.  No musl.  But we don't use systemd.

    As little as a year back we still ran into issues with systemd-udev
    variant breaking systems, the fix of course was to nuke it and install eudev.  Are we certain there is nothing (eg, LVM integration was our
    biggest problem resulting in really crazy impossible to debug since we
    can't log in due to lvn snapshot creation/removal deadlocking with systemd-udev - no ask me not how, all I can tell you is that eudev never exhibited this behaviour) will break?

    Whilst I fully appreciate the difficult of all the various e* packages (elogind, eudev etc ..) and I most certainly do not have the capacity to maintain, and therefore I'm in full support of the concept of
    deprecating eudev, I'm very, very worried about us suddenly being back
    into the reboot-a-server-a-week scenario.  In the worst case we've lost
    some large filesystems almost certainly due to systemd-udev (we've had a number of filesystem crashes which was recovered with fsck, but after ditching systemd-udev and moving to eudev about two years back on this specific host we've had ZERO further problems other than a failed drive
    or two, none of which required a hard-reset to get back to a sane state).

    Kind Regards,
    Jaco

    I kept eudev as conservative as possible which probably explains its predictable behavior. Open bugs with the sys-fs/udev maintainers and
    mark it critical if it is damaging filesystems.



    On 2021/08/22 22:14, Anthony G. Basile wrote:
    Hi everyone,

    Yes! It is time to finally deprecate eudev! sys-fs/udev now builds
    under musl! My original purpose for maintaining eudev was because
    systemd + musl did not play well together when udev was absorbed into
    the sytemd repo. Now thanks to patches from openembedded, they do, and
    my original reason for maintaining eudev is no longer valid. So its
    time to retire eudev. It has served its purpose as a stop-gap.

    To me, this is a success for musl, and I would like to thank all the
    developers who have taken musl seriously enough to make this happen :)

    I am willing to transfer the eudev repo to another organization, but I
    will not maintain it anymore and Base System doesn't want to either.
    Let me warn people, to maintain it correctly you MUST become familiar
    with its internals and watch what systemd is doing upstream to keep up.
    This is not trivial. I learned a lot from eudev, and it did save musl
    on gentoo, but there was a period there when it was taking up almost all
    of my time. If you don't know what you're getting into, you don't want
    to take on its maintenance.



    Title: eudev retirement on 2022-01-01
    Author: Anthony G. Basile <blueness@gentoo.org>
    Posted: 2021-08-xx
    Revision: 1
    News-Item-Format: 2.0
    Display-If-Installed: sys-fs/eudev

    sys-fs/udev is becoming the standard provider of udev on non-systemd
    (e.g. OpenRC) systems. Users of systemd will continue to use the udev
    services provided by the sys-apps/systemd package itself.

    The transition should be uneventful in most cases, but please read this
    item in full to understand some possible corner cases.

    eudev will be retired and removed from Gentoo on 2022-01-01. We will
    start masking eudev on 2021-10-01 and give people 3 months to prepare
    their transition. You should ensure that sys-fs/eudev is not in your
    world file by running

    emerge --deselect sys-fs/eudev

    in order for Portage to replace eudev with sys-fs/udev once the
    package.mask is in place. We fully support udev on musl, whereas uclibc
    will still have to rely on eudev before also being removed on 2022-01-01.

    **WARNING**

    If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob,
    you will inevitably break your system. sys-fs/udev contains "systemd" in
    some of its filenames, hence a blanket filter rule will likely lead to a
    non-functional udev installation.

    Rationale

    The integration of udev into the systemd git repo introduced numerous
    problems for none-glibc systems, such as musl and uclibc. Several
    options were considered, and the one chosen was to fork and maintain
    udev independant of the rest of systemd. This was meant as a stop-gap
    solution until such time as the problems with systemd on musl had been
    resolved. This is now the case with patches provided by openembedded,
    and my original reason for maintaining eudev is no longer relevant.

    I am willing to transfer eudev to another umbrella organisation or Linux
    distribution that is willing to continue its maintenance, but
    maintaining eudev cannot be done purely through proxy-maintaining and
    requires an understanding of its internals. This is a steep learning
    curve and must be an earnest effort. For this reason, the Base System
    project has decided not to support euev as an option going forward.




    --
    Anthony G. Basile, Ph.D.
    Gentoo Linux Developer [Hardened]
    E-Mail : blueness@gentoo.org
    GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
    GnuPG ID : F52D4BBA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to All on Wed Aug 25 02:30:02 2021
    On 24 Aug 2021, at 11:24, Jaco Kroon <jaco@uls.co.za> wrote:

    Hi All,

    We run glibc based systems. No musl. But we don't use systemd.

    As little as a year back we still ran into issues with systemd-udev
    variant breaking systems, the fix of course was to nuke it and install
    eudev. Are we certain there is nothing (eg, LVM integration was our
    biggest problem resulting in really crazy impossible to debug since we
    can't log in due to lvn snapshot creation/removal deadlocking with systemd-udev - no ask me not how, all I can tell you is that eudev never exhibited this behaviour) will break?

    The problem is that this is a bit indirect. blueness could've easily
    ended up backporting whatever commit causes your issue, if it is
    indeed udev, because the idea wasn't to be frozen in time anyway;
    this just kind of happened accidentally because of time commitments.

    I appreciate this is going to be a huge pain to debug but reporting
    this upstream is the only proper fix here.


    Whilst I fully appreciate the difficult of all the various e* packages (elogind, eudev etc ..) and I most certainly do not have the capacity to maintain, and therefore I'm in full support of the concept of
    deprecating eudev, I'm very, very worried about us suddenly being back
    into the reboot-a-server-a-week scenario. In the worst case we've lost
    some large filesystems almost certainly due to systemd-udev (we've had a number of filesystem crashes which was recovered with fsck, but after ditching systemd-udev and moving to eudev about two years back on this specific host we've had ZERO further problems other than a failed drive
    or two, none of which required a hard-reset to get back to a sane state).

    I don't doubt this happened as I know you're a persistent debugger,
    although my hope is that whatever issue you hit has been solved, especially given udev is used by Debian/Fedora/RHEL and all the rest of it. But I accept that if this was <= 1 year ago, that argument doesn't hold quite as much water.

    I suppose it'd be worth looking to see if there were any kernel or LVM2 regressions
    fixed around that time too.

    best,
    sam

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

    iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmEljYdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDt6Lgf+MMoYipqRE2miCWWjLKtHDY9s/6/sDBK89ZSxtjpigbKtV7l58eLvq+fH PNQd3TkxLBPvUJbH54QCMEpqx4iHB1H0jjG1oUcmlyX+xADzOoFPSlAAA/7cq0QA ePDqzJv5EdDzMHV52HmOu+5zbKkJ5TQDZSOhGGjXkA/WvrHFttYi6gQWrX4OO9jP d3G/93m1j9/EQdNq8d6fOpkySq4WzsdQ9RFGIsnwsjPYLCd41SGyqIHPm6+rt2ik JlvNND7nFb1SJlsfebcF3THsf12h7PdfixuFA0fiJFbn0xdAXvgnHSveXmK/G5Du V5PCgUJx249cVu2gZ4fhE7wxzb8UaA==
    =f5+N
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joonas Niilola@21:1/5 to Anthony G. Basile on Wed Sep 15 09:00:04 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dMotwCTX0UJYzX1d38uLrixV2H6Vuxfpm
    Content-Type: text/plain; charset=utf-8
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    On 22.8.2021 23.14, Anthony G. Basile wrote:
    Hi everyone,

    Yes! It is time to finally deprecate eudev! sys-fs/udev now builds
    under musl! My original purpose for maintaining eudev was because
    systemd + musl did not play well together when udev was absorbed into
    the sytemd repo. Now thanks to patches from openembedded, they do, and
    my original reason for maintaining eudev is no longer valid. So its
    time to retire eudev. It has served its purpose as a stop-gap.


    With its new upstream, and this post serves as a PSA to the
    uninititated, I guess eudev will be kept?

    https://github.com/eudev-project/eudev

    -- juippis


    --dMotwCTX0UJYzX1d38uLrixV2H6Vuxfpm--

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

    iQGTBAEBCgB9FiEEltRJ9L6XRmDQCngHc4OUK43AaWIFAmFBl59fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 RDQ0OUY0QkU5NzQ2NjBEMDBBNzgwNzczODM5NDJCOERDMDY5NjIACgkQc4OUK43A aWLviAf+Ls6QiZHSxgn1fnwBFHTlaA86IpN0YiM02Rokf6VIIlRjhJFWhGRLOkTJ wKttWWPWBCli/7eYp9qHtdq+BHBeR0fHbqOZxbRBk4pMsbkN6oP/zEiY33i2zS6z o0sWhOXqOKM+9wK7SERwMnar7a7YGgHIB/2CcLwb2qWABogG2Gx52md4Xsbx1/EW uF4JhPpkHe68CvLcHyBWY35du6BnOI9xUIIgDhcEjdmzUR8UtvNl/hQ5wSlUjpym vp5K6uUPPiohOorU9hUnwgzH2Va81ifE+95zUzW0CAuKj4LH4xWz7jLEw7rrTXik +iigh603sr4o2HHceYDjTSp+/n3QFA==
    =1VxK
    -----END PGP SIGNATURE-----

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