seife’s assorted rants

…then work around the bug.

One example is bug 699400: hwclock is never set correctly when NTP is used (unless it was almost correct before…).

I reported the bug, I argued with the maintainer, it did lead to nothing, the bug was “RESOLVED INVALID” (interesting notion: either it is resolved or it is invalid, then there is nothing to resolve…)

What’s my workaround? I exploit the fact that old SysV init uses bash scripts. The init script which sets the clock does source /etc/sysconfig/clock. Internally, it uses a variable ELEVENMIN_MODE.
So what did I do? Simply add

readonly ELEVENMIN_MODE=no

at the end of /etc/sysconfig/clock.
The script will throw some errors on boot and shutdown due to its inability to change a readonly shell variable, but I can live much better with a harmless warning than with a totally wrong system time at each reboot

Update: Werner has pointed out in the bug that this is totally wrong and will make a mess of your time settings, so use this at your own risk. OTOH I have more than 2000 productive systems here running with this. We had lots of problems before and have no problems anymore after doing it like described here. So at least for me the wrong solution works good.

Kids, don’t try this at home.
Anyway, here is what worked for me:

• add arch = x86_64 to /etc/zypp/zypp.conf
• zypper ref -f
• rpm -qa kernel*
• zypper in -f kernel-default kernel-default-base (the kernel packages found by the step above)
• mkinitrd
• reboot
• zypper in -f glibc
• zypper in -f rpm Attention: don’t install, just resolve everything and get the list of -32bit packages that would get installed
• zypper in -f file-32bit libbz2-1-32bit… Install all the -32bit packages that were selected in the previous step
• zypper in -f rpm
• zypper dup --no-recommends --download-in-advance
• mkinitrd
• reboot

Whenever zypper asks you for conflict resolution (which will be every single case), select the option that involves “change architecture”, never select “break …” or “do not install …”. There should be no “uninstall…” proposal in the summary before confirming, only architecture changes and newly installed -32bit packgages.

There were some failing postinstalls for glib and other libraries, which could probably have been avoided by more carefully updating in intermediate steps, or by installing some -32bit library packages before the “dup” step, but the resulting system seems to work just fine.

Due to Bug 596844, I had to rebuild the i915 module with a patch. I have done things like that quite often over the last years, and every time I have to dig through the documentation, so I’ll put it up here in the hope that I’ll find it easier in the future and that it might be useful for somebody else

There are only a few steps, following the README.SUSE in the kernel-source package:

• install the kernel-syms and kernel-source packages
• copy the kernel sources to some other place where you have write access as a normal user (this is not in the README, but I hate doing stuff like that as root, so I’m doing it anyway)
• patch the source
• build the module

Or, as an almost-copy’n'pasteable list of commands:

cd /tmp
cp -a /usr/src/linux/ . # do not only copy the symlink 
cd linux/drivers/gpu/drm/i915/
patch < /tmp/i915-nofbc.diff # your diff
make -C /usr/src/linux-obj/x86_64/desktop M=$(pwd)
ls -l i915.ko

You need to adjust the directory given to “make -C” to your desired kernel flavour, of course, but that’s it. Copy the module over to /lib/modules and reboot (I usually save the old module somewhere else, in case something goes wrong, but you probably figured that out already).