Insanity in vendor distros
By joe
- 3 minutes read - 585 wordsI am not sure if this is specific to SuSE (customer requirement, don’t ask), but there is some extreme … and I really, positively mean, EXTREME … boneheaded insanity in the dhcp stack in the initrd construction in SuSE. Something that doesn’t lend itself well, to, I dunno … CORRECT AUTOCONFIGURATION OF NETWORK PORTS IN DISKLESS ENVIRONMENTS. Ok, what clued me in was this snippet from the console I’ve been struggling with for the past day.
19.022726] NET: Registered protocol family 17
[ 19.034399] Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-eth0 instead.
preping 05-clock.sh
running 05-clock.sh
preping 11-usb.sh
running 11-usb.sh
preping 12-network.sh
running 12-network.sh
running dhcpcd on interface eth0
err, eth0: ioctl SIOCGIFHWADDR: No such device
[ 19.070185] usb 2-1: new high-speed USB device number 2 using ehci_hcd
no response from dhcp server -- exiting to /bin/sh
$ [ 19.221021] hub 2-1:1.0: USB hub found
[ 19.224896] hub 2-1:1.0: 8 ports detected
[ 19.310111] usb 1-1.3: new full-speed USB device number 3 using ehci_hcd
[ 19.437087] usbcore: registered new interface driver usbhid
[ 19.442723] usbhid: USB HID core driver
[ 19.509857] usb 2-1.1: new low-speed USB device number 3 using ehci_hcd
So I looked at the logs on the dns server. Sure enough, there was a response. So this log snippet was either lying or there was something worse afoot. Like, I dunno … A HARD CODED MAPPING VIA UDEV THAT SHOULD NOT HAVE EVER EXISTED … I am gonna say it out loud here. Udev sucks. It is very annoying at best, and at worst it gets completely in your way of doing the right things. Yeah, I know, it solves a problem via an event system, and its up to people to use the event system correctly. Not unlike the OpenSSL debacle, where it was hard to use the (broken) code correctly, it appears to be hard for people to understand that Udev is dynamic and SHOULD NOT BE USED TO HARD CODE CRAP. **ESPECIALLY IN A DAMNED INITRD. ** Ever. Under any circumstances. For any reason. Anyone dumb enough to do this should be forced to use their own handiwork. Here is the bad stupidity for all to see:
root@unison:/data/tiburon/srv/sites/boot/public/images/Unison/tmp# find | grep 70-persistent
./etc/udev/rules.d/70-persistent-net.rules
Its not that it merely blows chunks. It blows absolutely high gamma value relativistic chunks, all over everything. And it ruins your day, kicks your dog. And makes you wish you had time to rip out all the brokenness and replace it with stuff that works. For our diskless boxen we threw together something that preserves mount points, permissions, mount options, etc. far better than /etc/fstab does. We’ve ripped out/disabled other infrastructure which has been crappy, or just bypassed it entirely. We have an entire (and growing) /opt/scalable that is a testament to how badly broken distro internals are. So far the closest thing to a reasonably designed system I’ve seen has been Debian and its derivatives. You don’t have to rip out whole chunks and they are smart enough to make it so that you can bypass bad things. Not so with SuSE. Oh no. We have to rip out the offending bits in this code and fix em. In the initrd. Because however they generate it is borked, as their scripts have bugs and use DAMNED HARDWIRED VALUES FEEDING INTO UDEV THAT THEY HAVE NO RIGHT TO USE. Dammit. I knew there was a reason I had stopped using it so long ago. Know I remember why.