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 <bluen...@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 : bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
