Thursday, February 28, 2019

KIWI repository SSL redirect pitfall

Today, I was wondering why my local kiwi image builds got download problems:
[ DEBUG ]: 09:52:15 | system: Retrieving: dracut-kiwi-lib-9.17.23-lp150.1.1.x86_64.rpm [.error] [ DEBUG ]: 09:52:15 | system: Abort, retry, ignore? [a/r/i/...? shows all options] (a): a
[ INFO ]: Processing: [########################################] 100%
[ ERROR ]: 09:52:15 | KiwiInstallPhaseFailed: System package installation failed: Download (curl) error for '':
Error code: Curl error 60
Error message: SSL certificate problem: unable to get local issuer certificate
SSL error for an http:// URL? Digging for the zypper logs in the chroot found, that this request got redirected to today, which failed due to missing SSL certificates.

After I had debugged the issue, the solution was quite simple: in the <packages type="bootstrap"> section, just replace ca-certificates with ca-certificates-mozilla and everything works fine again.

Of course, jut building the image in OBS would also have solved this issue, but for debugging and developing, a "native" kiwi build was really necessary today.

Sunday, February 03, 2019

Raspberry Pi: "Bluetooth: hci0 link tx timeout"

I'm right now playing around with an old Raspberry Pi, to use it as a bluetooth speaker / DLNA renderer for audio. I spent almost a whole day trying to get bluetooth a2dp audio sink to work, but it almost always failed already at the pairing / connection stage. A similar thing had worked fine last week on a Raspi 3, but I want to try it with the old version as eventually the "Appliance" will be built with a Raspi Zero W, which is more like the first model. In the kernel log buffer I found the following:
Bluetooth: hci0 link tx timeout
Bluetooth: hci0 killing stalled connection xx:xx:xx:xx:xx:xx
This happened with different USB bluetooth dongles. Googling the problem found mostly unrelated articles, or advice that was obviously plain wrong.

Long story short: moving the dongle to a powered USB hub solved the issue.

(Just for the record: the raspi is powered by a good power supply...)

Friday, June 01, 2018

GRUB2 submenus revisited

After my last post quite some time ago, I had to revisit this issue again and found that there is a much easier way to "fix" the problem: Just add

in /etc/default/grub, recreate your grub.cfg and voila: the submenus are gone.

Thursday, March 09, 2017

grub2-set-default and submenus

At work, I was investigating why "grub2-set-default" apparently did not work for booting older kernels on a SLES12-SP1 system (openSUSE has the same configuration). A colleague found out, that it worked once he removed the "submenu" wrap around the additional installed kernels.

Today, after some googling, I found out that even though you have unique "menuentry" titles, a plain "grub2-set-default my\ menu\ entry" still does not work, unless you give the path to the submenu.

This is done in grub2 syntax like this:
grub2-set-default "1>openSUSE Leap 42.2, with Linux 4.4.46-11-default"
The "1>" tells grub2 to look for the menuentry in the submenu, which is the second toplevel item. For SUSE / openSUSE the second toplevel item is always, AFAICT, the "Advanced options for $VERSION" menu, where the additional kernels live.

An alternative for my case would have been
grub2-set-default "1>1"
Which would be "the second entry from the submenu which is the second toplevel item" (counting from zero). But you need to look at the config file and count the entries.

The entries have an additional ID that looks like it is costructed like:
gnulinux-$(uname -r)-advanced-${UUID_OF_ROOTFS}
 in my case:
Still looks unwieldy, but you might be able to automatically determine that from a script.

Monday, December 26, 2016

Silent night - or "how I accidentally disabled email delivery"

My private email domains are hosted on a linux server where I have shell access (but not as root) which processes them with procmail, stores them locally and finally forwards them all to a professionally hosted email server with IMAP access and all that blinky stuff.
The setup is slightly convulted (aka "historically grown") but works well for me.

But the last days have been quiet on the email front. Not even the notorious spammers spamming my message-ids (how intelligent!) have apparently be trying to contact me. Now that's suspicious, so I decided to look into that.

A quick testmail from my gmail account did not seem to come through. Now the old test via telnet to port 25... had to look up the SMTP protocol, it's a long time ago I had to resort to this. First try: greylisting... come back later. Second try:
250 Ok: queued as F117E148DE4
Check the mails on the server: did not get through.

Now a few more words on the setup: as I wrote, all mail is forwarded to that professionally hosted IMAP server, where I read it usually with Thunderbird or, if things get bad, with the web frontend.
But since all emails are also stored on the server with shell access, I get them from there from time to time via imap-over-ssh, using fetchmail and the mailsync tool.

BTW, the fetchmail setup for such a thing is:
poll myacc via shellservername.tld with proto imap:
    plugin "ssh -C %h bin/imapd" auth ssh;
    user seife there is seife here options keep stripcr
    folders Mail/inbox Mail/s3e-spam Mail/thirdfolder
    mda "/usr/bin/procmail -f %F -d %T"
So while trying to check mail, I'm regularly running:
fetchmail && mailsync myacc
(first fetchmail, since it passes the mails to procmail which does the same folder-sorting as was done on the mail server already and is much faster than mailsync, which comes second to do the synchronization stuff: delete mails on the server that have been deleted locally etc.)
All looks normal, apart from no new mails arriving.
Until suddenly I noticed, that mailsync was synchronizing a folder named "spamassassin.lock". WTF?

 Investigating... On the server, there really is an (emtpy) mailbox named "Mail/spamassassin.lock".
Next place to look for is .procmailrc, and there it is: a rule like:

:0fw: spamassassin.lock
* < 1048576
| $HOME/perl/bin/spamassassin
And since everything in procmail apparently per default is relative to $MAILDIR, the lockfile was placed there. Probably a mailsync process came along, exactly at the moment the lockfile was existing and persisted it, and after that, no mail ever went past this point.

Solution was easy: remove the lockfile, make sure it does not get re-synchronized with next mailsync run and reconfigure procmail to use $HOME/spamassassin.lock instead. Now the silent times are over, spam is piling up again.

Saturday, December 24, 2016

Fix for "moto g always booting into recovery"

Today I reinstalled and wiped my old moto g (falcon) phone.
After all was done, it finally did no longer boot anywhere but into recovery -- no matter which recovery I flashed. It was still possible to boot into fastboot mode (Volume down + Power button), then select "normal system boot", but that's certainly not a good user experience on every power-on.
Additionally, the "charge battery when powered off" image was no longer working: plugging in power would also boot into recovery.

Some googling finally lead me to a xda-developers forum post which has the solution: there is a raw partition in the flash, which apparently stores the default boot option for the boot loader, just wiping this partition will restore the default boot order.

So when booted into recovery (must have adb enabled), just run
adb shell \ 
  dd if=/dev/zero \
from your computer (adb installed and USB cable connected, of course).
This should fix booting (it did for me).

Thursday, July 28, 2016

When "# needsrootforbuild" in OBS does not work...

...always remember, that you also need to change /usr/lib/obs/server/

# Allow to build as root, exceptions per package
# the keys are actually anchored regexes
our $norootexceptions = {
        "my-project/root-package" => 1,
        "dev-projects.*/other-package" => 1,
I already forgot that and wondered why it worked for "root-package", but not for "other-package" (which was not yet added...)