tag:blogger.com,1999:blog-14647146663191370092024-03-14T09:16:13.235+01:00seife's assorted rantsMove on, nothing to see here.seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.comBlogger134125tag:blogger.com,1999:blog-1464714666319137009.post-22725986392237371072022-09-28T11:57:00.009+02:002022-09-28T12:06:48.412+02:00Multiple stage servers in open build service<p> The <a href="https://openbuildservice.org" target="_blank">open build service</a> publisher has a configuration variable in <span style="font-family: courier;">BSConfig.pm</span><span style="font-family: inherit;">, where you can define a rsync server to publish the built repos to.</span></p><p>Unfortunately, the documentation apart from the actual code (in <a href="https://github.com/openSUSE/open-build-service/blob/master/src/backend/bs_publish" style="font-family: courier;" target="_blank">src/backend/bs_publish</a><span style="font-family: inherit;"> function </span><span style="font-family: courier;">sync_to_stage</span><span style="font-family: inherit;">)</span> seems scarce, so let's document one non-standard usage here.</p><p>"Standard" (IMO) usage, one rsync staging server:</p><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><p style="text-align: left;"><span style="font-family: courier;">our $stageserver = 'rsync://my-rsync/obs-repos-module';</span></p></blockquote><p> But now, for a transition phase, I need multiple rsync servers that are all synced to. The format for this is a perl array variable reference that contains pairs of "project name regex, array of sync servers". This also allows to sync different repositories to different rsync servers for example.</p><p style="text-align: left;">The simplest use of this is "sync all repos to multiple rsync servers" and is configured like this:</p><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><p style="text-align: left;"><span style="font-family: courier;">our $stageserver = ['.*', ['rsync://rsync1/module1', 'rsync://rsync2/module2', 'rsync://rsync3/module3']];</span></p></blockquote><p> With this configuration, bs_publish will send all repos to the three mentioned rsync URLs in turn.</p>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-1526198912554353742022-02-13T20:14:00.000+01:002022-02-13T20:14:45.970+01:00Make Hibernation Great Again!<p> I have now put the fixes from the last two blogposts into a github repository: <a href="https://github.com/seife/make-hibernate-great-again" target="_blank">https://github.com/seife/make-hibernate-great-again</a> so that you can just clone it, examine what it does and then run</p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><p style="text-align: left;"><span style="font-family: courier;">sudo make install</span></p></blockquote><p>followed by</p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><p style="text-align: left;"><span style="font-family: courier;">sudo dracut -f</span></p></blockquote><p>This should do the following:</p><p></p><ul style="text-align: left;"><li>let resume actually work (by enabling the dracut resume module)</li><li>make hibernate more verbose (switch to an empty text console and increase the kernel's log level before hibernation, restore after resume)</li><li>make resume more verbose</li></ul><div>Have fun!</div><div><br /></div><div>I have also packaged it in obs://home:seife:testing, but I do not really advise to use this repo on anything but my own machines ;-) </div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><p style="text-align: left;"> </p></blockquote><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><p style="text-align: left;"> </p></blockquote><p><br /></p>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-24427171460007183242022-02-11T20:13:00.003+01:002022-02-12T12:29:06.921+01:00"hibernation fix" part 2: verbose resumeNow that I fixed hibernation to resume at all, I found another thing I had added to my old install long ago.<div>The "problem" is, that resume from hibernation is very quiet. So all you see is the GRUB messages "loading kernel", "loading initrd", then nothing, just the disk light may be blinking for quite some time, and if resume is successful, you'll see the unlock prompt of your screenlock.</div><div>That's a bit too little "user interface" for my taste.</div><div><br /></div><div>The reason it is like this is, that the kernel's progress messages (in 10% steps) are printed with level "pr_info":</div><div><br /></div><div><div><span style="font-family: courier;"> if (!(nr_pages % m))</span></div><div><span style="font-family: courier;"> pr_info("Image loading progress: %3d%%\n",</span></div><div><span style="font-family: courier;"> nr_pages / m * 10);</span></div></div><div><br /></div><div>But the default "quiet" boot suppresses KERN_INFO messages, which is good because without that, you cannot find the prompt for unlocking your crypted filesystems amongst all those KERN_INFO messages during boot... so how to fix it?</div><div><br /></div><div>We can just adapt the systemd-hibernate-resume.service to increase the kernel log level just before starting to resume, via a dropin file in /etc/systemd/system/systemd-hibernate-resume.service.d/10-resume-verbose.conf:</div><div><br /></div><div><div><span style="font-family: courier;">[Service]</span></div><div><span style="font-family: courier;">ExecStartPre=/bin/sh -c "echo 7 > /proc/sys/kernel/printk"</span></div><div><span style="font-family: courier;">ExecStartPost=/bin/sh -c "echo 1 > /proc/sys/kernel/printk"</span></div></div><div><br /></div><div><span style="font-family: inherit;">Also, add the file to your dracut config, so that it is actually included in the initrd:</span></div><div><span style="font-family: inherit;"><br /></span></div><div><span style="font-family: courier;">install_items+=" /etc/systemd/system/systemd-hibernate-resume@.service.d/10-resume-verbose.conf "</span></div><div><br /></div><div>now rebuild your initrd with "dracut -f" and enjoy :-)</div><div><br /></div><div><strike>Oh, and of course this only helps if you do not use things like plymouth which actually hide everything interesting during boot.</strike> Update 2022-02-12: it also works with plymouth, because image loading kicks in before plymouth can hide the interesting bits.</div>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-83939903989451417892022-02-09T09:25:00.001+01:002022-02-09T09:25:16.065+01:00dracut: fix hibernate after fresh installJust for fun, I finally installed a fresh Tumbleweed on one of my machines to actually find out if I'm missing out on new features that are masked by just always updating the old installation.<div><br /></div><div>One feature that I had missed was, that hibernation was no longer working. Or, to be more exact, hibernation was working, but resume was not. Investigating the issue, I found that dracut's "resume" module was not included in the initramfs, which in turn lead to initramfs not even trying to resume.</div><div><br /></div><div>The dracut mechanism has some logic to actually find out if suspend and resume is configured, and when it decides it is not, it will just skip adding the "useless" resume module.</div><div><br /></div><div>Unfortunately, the check is faulty IMHO. It checks, if the resume device is configured in the kernel, and if it is, it adds the module to dracut. The problem is, that this kernel config is written by the resume code in the initrd... so during installation this is not the case, and as a result the module is not added to initrd, which leads to the config not being set on next reboot... </div><div><br /></div><div>The trivial fix is to call dracut once with the option to include the resume module:</div><div><br /></div><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><div style="text-align: left;"><span style="font-family: courier;">dracut -a resume -f</span></div></blockquote><div><br /></div><div>After a reboot, the kernel config will be set and in the future the resume module will always be included in the initrd.</div><div>For an even saver setup, adding</div><div><br /></div><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><div style="text-align: left;"><span style="font-family: courier;">add_dracutmodules+=" resume "</span></div></blockquote><div><span style="font-family: courier;"><br /></span></div><div><span style="font-family: inherit;">to </span><span style="font-family: courier;">/etc/dracut.conf.d/99-local.conf</span><span style="font-family: inherit;"> might be even better.</span></div><div><span style="font-family: inherit;"><br /></span></div><div>Of course I wanted to report a bug about the issue, then found out that there are plenty already:</div><div><ul style="text-align: left;"><li>openSUSE: <a href="https://bugzilla.opensuse.org/1192506" target="_blank">https://bugzilla.opensuse.org/1192506</a></li><li>upstream dracut: <a href="https://github.com/dracutdevs/dracut/issues/924" target="_blank">https://github.com/dracutdevs/dracut/issues/924</a></li><li>Fedora: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1795422" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1795422</a></li><li>RedHat actually fixed it for RHEL9 by just removing the crazy "only include it if it has been included before"-logic: <a href="https://github.com/redhat-plumbers/dracut-rhel9/pull/12" target="_blank">https://github.com/redhat-plumbers/dracut-rhel9/pull/12</a></li></ul></div>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-24227345280426632192021-01-05T10:13:00.005+01:002021-01-05T10:13:34.478+01:00Ethernet on the BananaPi M2 Zero<p>Even though it does not look like it does, <a href="http://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO#how_to_use_zero_10.2F100_Ethernet" target="_blank">the BPI-M2 Zero also has a wired ethernet interface.</a> Unfortunately, it is disabled by default in its device tree blob.</p><p>But enabling it is easy:</p>
<pre># copy into /root
cp /boot/dtb/sun8i-h2-plus-bananapi-m2-zero.dtb .
# decompile
dtc -I dtb sun8i-h2-plus-bananapi-m2-zero.dtb \
-O dts -o sun8i-h2-plus-bananapi-m2-zero.dts
# edit
vi sun8i-h2-plus-bananapi-m2-zero.dts # :-)
# compile
dtc -i dts sun8i-h2-plus-bananapi-m2-zero.dts \
-O dtb -o /boot/custom.dtb
</pre>
<i><b>How do you need to edit the DTB file?</b></i><div><br />In the "ethernet@1c30000" block, you need to apply this "diff":<p><span style="background-color: white;"><span style="font-family: inherit;"><span style="font-family: monospace;">- status = "disabled";
<br />+ status = "okay";
<br />+ phy-handle = <0x4d>;
<br />+ phy-mode = "mii";
<br /> phandle = <0x4b>;<br /></span></span></span></p><p>The "phy-handle" value is taken from the "phandle" of the "ethernet-phy@1" block a few lines down. Then another change is adding an alias for ethernet0 to the "aliases" block:<br /><br /><span style="background-color: white; font-family: monospace;"> aliases { </span></p><p><span style="font-family: monospace;"> serial0 = "/soc/serial@1c28000";
<br /> serial1 = "/soc/serial@1c28400";
<br />+ ethernet0 = "/soc/ethernet@1c30000";
<br /> };<br /></span></p><p><span style="font-family: inherit;">Ethernet will work without that, but we'll need this for setting the MAC address later.</span></p><p>Now reboot and try it out in a temporary way. Either by:</p><p></p><ul style="text-align: left;"><li>interrupting u-boot and doing <span style="font-family: courier;">setenv fdtfile custom.dtb</span><span style="font-family: inherit;"> (no "saveenv" yet!), then "boot"</span></li><li><span style="font-family: inherit;">editing the GRUB menu, adding an additional line after "initrd..." that reads </span><span style="font-family: courier;">devicetree /boot/custom.dtb</span></li></ul><div>Check if the ethernet device eth0 appears after boot. If it does, the u-boot method can be persisted by issuing a <span style="font-family: courier;">saveenv</span><span style="font-family: inherit;"> command after the </span><span style="font-family: courier;">setenv</span><span style="font-family: inherit;">.</span></div><div><br /></div><div><i><b>Persisting the MAC address:</b></i></div><div>At my first tries I noticed that the MAC address was randomly assigned on every boot, in later experiments I could not reproduce this anymore but it looked like the MAC was at least reassigned on every deployment. I have no idea if this has to do with saving the environment in u-boot or if there is something in the userspace (a systemd service maybe?) that makes the MAC address semi-persistent. I decided to fix the MAC address once and for all, since I'm running a static DHCP setup, this is pretty important for my use case.</div><div><br /></div><div>Because of the "ethernet0" alias in the device tree, persisting the MAC address is easy. All you need to do is <span style="font-family: courier;">setenv ethaddr 22:33:44:55:66:77</span><span style="font-family: inherit;"> in u-boot and then persist this with </span><span style="font-family: courier;">saveenv</span><span style="font-family: inherit;"> and you are done. Note that u-boot has some precautions to disallow changing the MAC address later by accident so you are not able to easily undo this later. You can always remove "/boot/efi/uboot.env" in your booted system or by inserting the SD card into another machine and start from scratch.</span></div><div><br /></div><p></p></div>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-55382560965016896022021-01-03T16:16:00.000+01:002021-01-05T08:23:30.547+01:00GRUB, u-boot, kernels and DTB loading (on the BPi M2 Zero and others)<p>While I was experimenting with the BananaPi M2 Zero board, I soon needed to adopt its device tree file (dtb).</p><p>Fortunately, the friendly members of the openSUSE:Factory:ARM community quickly hinted me at the grub2 "devicetree" command which can be specified similar to "linux" or "initrd" to name a file that's loaded as device tree.</p><p>Unfortunately, there is no way to make this really persistent, short of editing the grub generator scripts which will get lost on every grub2 update.</p><p>The other option would be to decompile the board's DTB file<span style="font-family: inherit;"> ("<span style="background-color: white;">/boot/dtb/sun8i-h2-plus-bananapi-m2-zero.dtb" in my case), change and then recompile it, replacing the original file. This has two downsides: first, it will get overwritten with every update of the "dtb-sun8i" package (no idea how often this will be the case) and second, you might want to have the original file as fallback ready. In general, editing package managed files is not a good idea in my book, if it can be avoided it should be.</span></span></p><p>So I looked into the "who loads which device tree file" and found out that actually the dtb is loaded by u-boot, even before grub starts. U-boot has the name of the board built-in and thus the file name it is looking for. Additionally it has a search list of directories that it searches to find the dtb file. So the simplest way to apply your own dtb file would probably be to put it, with the original file name into the search path <i>after</i> the original file. I tried this approach at first, but then went for explicitly specifying a different filename, which is just not as subtle in case you need to debug this years later ;-)</p><p>So the method is relatively easy:</p><p></p><ol style="text-align: left;"><li>put your modified dtb file into <span style="font-family: courier;">/boot</span>, I named it <span style="font-family: courier;">custom.dtb</span>.</li><li>boot into u-boot, interrupt booting on the serial console</li><li>in u-boot console, enter <span style="font-family: courier;">setenv fdtfile custom.dtb</span></li><li><span style="font-family: inherit;">in u-boot console, enter </span><span style="font-family: courier;">saveenv</span></li></ol><div><span style="font-family: inherit;">That's it. Now boot and verify that your dtb file is used.</span></div><div><span style="font-family: inherit;"><br /></span></div><div><span style="font-family: inherit;">Note that the u-boot environment is saved on the EFI partition of the SD card (first partition, FAT format) as file "uboot.env". If you need to reset the environment to the built-in defaults, then you can always mount the SD card in another machine and move away or delete uboot.env.</span></div><p></p><span style="font-family: monospace;"><br /></span>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-54232164452282556632021-01-02T13:14:00.000+01:002021-01-02T13:14:19.896+01:00openSUSE Tumbleweed on the Banana Pi BPI-M2 ZERO<p>This is the first post of a small series about openSUSE on the <a href="http://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO" target="_blank">Banana Pi BPI-M2 ZERO</a>.</p><p><i>Preface</i></p><p>I recently got myself a Banana Pi M2 Zero board while ordering other stuff at an electronics distributor. The M2 zero is the same form factor and feature set as the Raspberry Pi Zero W (the GPIO pin headers are said to be compatible, it has WiFi and Bluetooth built in and an USB OTG port). The CPU is an Allwinner H2+, a quad-core ARM processor running a 1GHz clock speed, RAM size is 512MB. Processing power is probably comparable to a Raspberry Pi 2 board.</p><p>I bought the M2 Zero to use it with an RTLSDR stick to receive the signal of my outside RF temperature sensor. This worked with the Raspberry Pi Zero W, but was a bit too much for the slower CPU which has other more important things to do anyway (playing internet radio ;-), so the M2 Zero was a cheap, more powerful alternative. The box will be running headless and thus I do not care about support for graphics and multimedia anyway.</p><p>In the end, I switched the RF receiver to a RaspyRFM board whih is using less energy and simpler to use than an RTLSDR stick just to receive some sensors and now the M2 Zero board is free for tinkering...</p><p><br /></p><p><i>openSUSE on the M2 Zero</i></p><p>There was already an image available for the Banana Pi M2 Plus (called "sinovoipbpim2plus"), which is the "bigger brother" of the M2 zero, but that image did not boot. Experimenting with the u-boot image from armbian lead to success in "openSUSE Tumbleweed boots with armbian u-boot". Thanks to the friendly openSUSE ARM community, a matching u-boot version for the M2 Zero was built quickly and I could submit the updated image in OBS to get an image ready for the board (called "sinovoipbpim2zero").</p><p>Some small things are still to be sorted out, this is why I would suggest you use the image from the <span style="font-family: courier;">home:seife:bananapi</span><span style="font-family: inherit;"> repository for now. Since the board has only WiFi networking (more on that in a later post...), you'll need a serial console wired up for initial setup and I strongly suggest to use at least the "openSUSE-Tumbleweed-ARM-X11-..." image and <b>not</b> the JeOS image, since JeOS does not contain NetworkManager and using WiFi with wicked (actually using <b>anything</b> with wicked) is not fun.</span></p><p><span style="font-family: inherit;">So put the image on the SD card, connect the serial console, boot the box up. Log in as root. WiFi connection is easily established then:</span></p><p><span style="font-family: courier;">nmcli dev wifi connect YOUR_SSID password YOUR_PASSWORD</span></p><p><span style="font-family: inherit;">That's it, have fun! ;-)</span></p><p><span style="font-family: inherit;"><br /></span></p><p><span style="font-family: inherit;"><br /></span></p><p><span style="font-family: inherit;"><i>Addon note: </i></span><span style="font-family: inherit;">When I started to write this post, my home:seife:bananapi repo was necessary for actually getting WiFi to work (contained a fixed kernel-firmware package). This has all been submitted to upstream or openSUSE:Factory:ARM now. All that's "special" in my repo now is a slightly extended package selection in the image (the "dtc" package is included) and a fixed config.sh script that makes NetworkManager actually work correctly, including name resolution, see </span><a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1180234" style="font-family: inherit;" target="_blank">boo#1180234</a><span style="font-family: inherit;"> for details), so the image from openSUSE:Factory:ARM should be "good enough" for most uses already and in the near future I'll probably retire the home:seife:bananapi project or use it just for development stuff).</span></p>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-17220418256395410192020-06-23T19:48:00.001+02:002020-06-23T19:48:13.463+02:00Brother MFC-L2710DW Printer / Scanner and LinuxI needed a new scanner, my old HP PSC-1510 finally broke..<div>I wanted a multi-function device with ethernet, non-color laser printer with duplex printing and a scanner with ADF. For ease of use, I wanted a "scan to network drive" and "scan to email" capable device, so that my users at home can easily help themselves without me having to scan every document for them.</div><div><br /></div><div>The Brother MFC-L2710DW seemed to fit the bill pretty well.</div><div>Only after having it all set up, I found out that the "Scan to email" only works with a Windows PC, and apparently only with the device connected via usb, by somehow firing up Outlook to send the mail, and the "scan to network drive" also seems to work the same way.</div><div><br /></div><div>The next thing I found out is, that the printer works with CUPS, but you need a binary only driver from Brother (at least if you follow all the HOWTOs on the internet) and the scanner unit also seemed to need a binary only sane backend. Not much more and I would have almost immediately put up the device on ebay just to get rid of it as fast as possible.</div><div><br /></div><div>But then I noticed that the thing is AirPrint and AirScan capable and I found out that no MacOS drivers were included...</div><div><br /></div><div>Long story short: AirScan is some http based protocol (named eSCL) for basic scanning. With some curl magic you can scan (from standard glass or ADF) to either (at least) JPEG or PDF. When scanning from ADF, you even get a multi-page PDF directly. There is an "escl" backend in latest SANE (but not in Leap 15.2). However, this did not work well for me. Then I found the excellent "sane-airscan" project on github which works fine, and which serves both as a working SANE backend and as a good documentation on the protocol, which I used to write a standalone tool "simple-airscan" in python, which I'll probably put into a small simple webfrontend, so that my users can help theirselves with their scanning needs.</div><div><br /></div><div>Ok, scanning works. What about printing?</div><div>Airprint has some "driverless" mode, which I was unable to configure with YaST, but it was easy to configure after I enabled the CUPS web frontend. This works without any ugly brother binary only drivers and prints just fine.</div><div><br /></div><div>So now both the scanner and the printer work just fine without any brother software ;-)</div><div><br /></div><div>Links:</div><div><a href="https://github.com/seife/airscan-simple" target="_blank">https://github.com/seife/airscan-simple</a> - my simple python scanning tool.</div><div><a href="https://github.com/alexpevzner/sane-airscan" target="_blank">https://github.com/alexpevzner/sane-airscan</a> - the excellent sane-airscan backend for SANE.</div><div><a href="https://wiki.debian.org/CUPSDriverlessPrinting" target="_blank">https://wiki.debian.org/CUPSDriverlessPrinting</a> - the debian wiki has extensive information on driverless printing<br /></div>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com8tag:blogger.com,1999:blog-1464714666319137009.post-52381535909720951572020-03-26T13:28:00.000+01:002020-03-26T13:28:42.368+01:00Windows 10 update error 0x800f0922First: sorry for the OT ;-)<br />
<br />
A Thinkpad of mine that has Windows 10 co-installed was refusing all cumulative Windows updates since about 6 months, always performing everything, rebooting, counting up to 99%, then failing with error 0x800f0922 and rolling back.<br />
Now this Windows instance is not really used and thus not booted on a regular base, but I'd still rather keep it up to date in case I somewhen really need it for something.<br />
<br />
So I searched the internet for error 0x800f0922... and tried almost everything that was mentioned as a possible fix:<br />
<br />
<ul>
<li>resetting windows update</li>
<li>uninstalling various pieces of software</li>
<li>in general, random changing of different settings ;-)</li>
</ul>
<div>
Nothing helped. Until I found a short comment under some blog post hidden in the vast voids of the internet, that mentioned that the problem could be solved by not booting via grub but instead directly activating the windows boot partition.</div>
<div>
<br /></div>
<div>
Could it be that easy? Yes. Rebooted into Linux, deactivated /dev/sda3 and activated /dev/sda1 with fdisk, rebooted and Windows is now updating happily ever after...</div>
seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-79934330628735363502020-03-22T10:32:00.000+01:002020-03-22T10:32:31.169+01:00Leap 15.2 Beta: mariadb upgrade woesI'm running a server at home with <a href="https://software.opensuse.org/distributions/leap" target="_blank">openSUSE Leap</a>, and since Leap 15.2 is now in beta, I thought it was a good idea to update and take part in the beta testing effort.<br />
This machine is running an Owncloud instance, serving some internal NFS shares and used as a development machine for (cross-)compiling stuff, packaging etc.<br />
<br />
The update went pretty smooth, only the mariadb instance used by Owncloud was hosed afterwards. There was no login possible and generally database users were gone.<br />
Fortunately, I always have recent backups available, both a mysqldump and a complete file system backup.<br />
<br />
So I tried to just restore the mysqldump on the updated database. <a href="https://bugzilla.suse.com/show_bug.cgi?id=1166786" target="_blank">This did not work, Bug#1166786.</a><br />
Then I did just restore the filesystem backup of /var/lib/mysql and the database worked again.<br />
Unfortunately, as I found out reproducing and investigating the issue, <a href="https://bugzilla.suse.com/show_bug.cgi?id=1166781" target="_blank">it would just get killed again by the next update, Bug#1166781.</a> (Extra kudos to openSUSE Product Management which decided that this is not a bug, but instead regarded a feature!).<br />
<br />
Finally I found the <a href="https://jira.mariadb.org/browse/MDEV-21244" target="_blank">upstream bug in mariadb JIRA bugtracker,</a> (which also does not look like there is much interest in fixing this), but with the information given there, I was able to fix this for me.<br />
<br />
So all of you who are stuck with<br />
<pre class="bz_comment_text" id="comment_text_7">ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)</pre>
after updating a mariadb instance to 10.4, this might help:<br />
<br />
<ol>
<li>restart mysqld with option <span style="font-family: "courier new" , "courier" , monospace;">--skip-grant-tables</span>, to disable user authentication</li>
<li>in the <span style="font-family: "courier new" , "courier" , monospace;">mysql</span> database, execute</li>
<ul>
<li><span style="font-family: "courier new" , "courier" , monospace;">ALTER TABLE user CHANGE COLUMN `auth_string` `authentication_string` text;</span></li>
<li><span style="font-family: "courier new" , "courier" , monospace;">DROP TABLE global_priv;</span></li>
</ul>
<li>now run the <span style="font-family: "courier new" , "courier" , monospace;">mariadb-upgrade</span> command</li>
<li>restart mariadb.service with default options</li>
</ol>
<div>
This fixed my instance and owncloud is working again.</div>
<div>
<br /></div>
<div>
Note that I am by no means a database expert. Take backups before performing these steps.</div>
seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-12774232298264887782020-01-21T14:39:00.000+01:002020-01-21T14:39:57.489+01:00Fun with grub2-install "not a directory"These days, I came across spontaneous kiwi image build failures in a private OBS instance.<br />
The images were SLES15-SP1, they had not been touched for quite some time, rebuilds were only triggered due to new packages in the update channel.<br />
The error was grub2-install failing with the error message "not a directory".<br />
Looking at the recent changes in the update repo showed no obvious reason (some python packages that had nothing to do with grub2-install), so I started to investigate...<br />
<br />
... 3 days later, after following some detours, I finally found the issue.<br />
<br />
grub2-install scans the installation device for filesystems, and probes all known (to grub2) fs types. The probe of "minix_be" fails fatally. Sometimes.<br />
<br />
After building my own grub2 package with lots of debug-printf's, I finally found out, that the minix fs detection of grub2 is a little "fragile". It does the following (pseudo code):<br />
<ul>
<li>grub_mount_minix(device) || return "not minix fs"</li>
<li>grub_minix_find_file("/") || fatal_error()</li>
</ul>
<div>
The problem is, that grub_mount_minix() only does pretty simple magic numbers checks, which can lead to false positives.</div>
<div>
<br /></div>
<div>
Comparing the superblock structures of ext[234] and minix filesystems (from the grub2 source code) side by side, you see this:</div>
<div>
<br /></div>
<pre>struct grub_minix_sblock |struct grub_ext2_sblock
{ |{
grub_uint16_t inode_cnt; | grub_uint32_t total_inodes;
grub_uint16_t zone_cnt; |
grub_uint16_t inode_bmap_size; | grub_uint32_t total_blocks;
grub_uint16_t zone_bmap_size; |
grub_uint16_t first_data_zone; | grub_uint32_t reserved_blocks;
grub_uint16_t log2_zone_size; |
grub_uint32_t max_file_size; | grub_uint32_t free_blocks;
grub_uint16_t magic; | grub_uint32_t free_inodes;
};
</pre>
<div>
<br />
This already hints at the issue: at the same disk location where ext2 stores the free inodes number, minix stores its magic number, which is used by grub to detect if it is a minix file system.<br />
<br />
Now if you happen to have an ext3 file system with a free_inodes number whose lower 16 bits resemble one of the GRUB_MINIX_MAGIC numbers, chances are grub_mount_minix() will succeed, but then the attempt to acces the root directory will fail with a fatal error.<br />
<br />
This is a plain grub2 bug, which I will probably report upstream and try to get fixed.<br />
However, I need a fix to have my images build again, and the chances of getting a fix into SLES15-SP1 are ... low (and it is a daunting task, even if you are reporting this bug as a big SLES customer), so I built a workaround in my (locally built, lucky me...) python-kiwi package.<br />
<br />
It basically does the following, before calling the "chroot <targetdir> grub2-install ...".</targetdir><br />
<br />
<ul>
<li>statvfs(<targetdir>) to get the free_inodes number</targetdir></li>
<li>check if the lower 16 bits resemble one of the MINIX_MAGIC numbers</li>
<ul>
<li>if it does, touch a temporary file in <targetdir></targetdir></li>
<li>unmount and mount <targetdir> again to update the superblock (I missed this at first and wondered why it did not work)</targetdir></li>
<li>unlink the temporary file</li>
</ul>
<li>continue as before</li>
</ul>
<div>
This workaround is ugly as hell, but it does work for me.</div>
<div>
<br /></div>
<div>
P.S.: the detours included first noticing that almost every change I made to the image, like wrapping grub2-install into a wrapper script for debugging) made the issue go away (because of a different free_inodes number), so I always needed to check after every change that the issue was still present, then finding that copying the locales in grub2-install actually triggers an ENOTDIR - "Not a directory", because it misses special handling the /usr/share/locale/locale.alias file. Of course I thought "this is the issue" and patched it out of grub2, just to find that the original problem still persisted... then overnight package updates in SLES15-SP1 making this problem go away and reappear seemingly random... you guess it 😄</div>
</div>
seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-65781176301465372752019-02-28T10:14:00.000+01:002019-02-28T10:14:52.450+01:00KIWI repository SSL redirect pitfallToday, I was wondering why my local kiwi image builds got download problems:
<br />
<blockquote>
<span style="font-family: Courier New, Courier, monospace;">[ 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</span><br />
<span style="font-family: Courier New, Courier, monospace;">[ INFO ]: Processing: [########################################] 100%</span><br />
<span style="font-family: Courier New, Courier, monospace;">[ ERROR ]: 09:52:15 | KiwiInstallPhaseFailed: System package installation failed: Download (curl) error for 'http://download.opensuse.org/repositories/Virtualization:/Appliances:/Builder/openSUSE_Leap_15.0/x86_64/dracut-kiwi-lib-9.17.23-lp150.1.1.x86_64.rpm':</span><br />
<span style="font-family: Courier New, Courier, monospace;">Error code: Curl error 60</span><br />
<span style="font-family: Courier New, Courier, monospace;">Error message: SSL certificate problem: unable to get local issuer certificate</span></blockquote>
SSL error for an http:// URL?
Digging for the zypper logs in the chroot found, that this request got redirected to <span style="font-family: Courier New, Courier, monospace;">https://provo-mirror.opensuse.org/repositories/...</span> today, which failed due to missing SSL certificates.<br />
<br />
After I had debugged the issue, the solution was quite simple: in the <span style="font-family: Courier New, Courier, monospace;"><packages type="bootstrap"></span> section, just replace <span style="font-family: Courier New, Courier, monospace;">ca-certificates</span> with <span style="font-family: Courier New, Courier, monospace;">ca-certificates-mozilla</span> and everything works fine again.<br />
<br />
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.seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com1tag:blogger.com,1999:blog-1464714666319137009.post-44339992661157535092019-02-03T13:08:00.001+01:002019-02-03T13:08:52.738+01:00Raspberry 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:
<blockquote>Bluetooth: hci0 link tx timeout<br>
Bluetooth: hci0 killing stalled connection xx:xx:xx:xx:xx:xx
</blockquote>
This happened with different USB bluetooth dongles. Googling the problem found mostly unrelated articles, or advice that was obviously plain wrong.
<p>
Long story short: moving the dongle to a powered USB hub solved the issue.
<p>
(Just for the record: the raspi <i>is</i> powered by a good power supply...)seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-75461029238422661192018-06-01T12:52:00.000+02:002018-06-01T12:53:14.102+02:00GRUB2 submenus revisitedAfter my <a href="2017/03/grub2-set-default-and-submenus.html" target="_blank">last post</a> 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<br />
<br />
<blockquote class="tr_bq">
<blockquote class="tr_bq">
GRUB_DISABLE_SUBMENU="y"</blockquote>
</blockquote>
in /etc/default/grub, recreate your grub.cfg and voila: the submenus are gone.seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-16715366369487833922017-03-09T13:01:00.000+01:002017-03-09T13:01:20.165+01:00grub2-set-default and submenusAt 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.<br />
<br />
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.<br />
<br />
This is done in grub2 syntax like this:<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">grub2-set-default "1>openSUSE Leap 42.2, with Linux 4.4.46-11-default"</span></blockquote>
<span style="font-family: inherit;">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 "</span>Advanced options for $VERSION" menu, where the additional kernels live.<br />
<br />
An alternative for my case would have been<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">grub2-set-default "1>1"</span></blockquote>
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.<br />
<br />
The entries have an additional ID that looks like it is costructed like:<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">gnulinux-$(uname -r)-advanced-${UUID_OF_ROOTFS}</span></blockquote>
in my case:<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">gnulinux-4.4.46-11-default-advanced-b073628b-5ddc-4a2d-9943-0f2999dfdaaa</span></blockquote>
<span style="font-family: inherit;">Still looks unwieldy, but you might be able to automatically determine that from a script.</span>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-86997107084286963732016-12-26T12:09:00.000+01:002016-12-26T12:09:47.788+01:00Silent 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.<br />
The setup is slightly convulted (aka "historically grown") but works well for me.<br />
<br />
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.<br />
<br />
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:<br />
<blockquote class="tr_bq">
<span style="font-family: monospace;"><span style="background-color: white;">250 Ok: queued as F117E148DE4</span></span></blockquote>
Check the mails on the server: did not get through.<br />
<br />
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.<br />
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.<br />
<br />
BTW, the fetchmail setup for such a thing is:<br />
<blockquote class="tr_bq">
<span style="background-color: white; font-family: monospace;">poll myacc via shellservername.tld with proto imap:<br />
plugin "ssh -C %h bin/imapd" auth ssh;<br />
user seife there is seife here options keep stripcr<br />
folders Mail/inbox Mail/s3e-spam Mail/thirdfolder<br />
mda "/usr/bin/procmail -f %F -d %T"</span></blockquote>
<div>
<span style="font-family: inherit;">So while trying to check mail, I'm regularly running:</span></div>
<blockquote class="tr_bq">
<span style="font-family: monospace;"><span style="background-color: white;">fetchmail && mailsync myacc</span></span></blockquote>
(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.)<br />
All looks normal, apart from no new mails arriving.<br />
Until suddenly I noticed, that mailsync was synchronizing a folder named "spamassassin.lock". WTF?<br />
<br />
Investigating... On the server, there really is an (emtpy) mailbox named "Mail/spamassassin.lock".<br />
Next place to look for is .procmailrc, and there it is: a rule like:<br />
<br />
<blockquote class="tr_bq">
<span style="background-color: white; font-family: monospace;">:0fw: spamassassin.lock<br />* < 1048576
<br />| $HOME/perl/bin/spamassassin</span></blockquote>
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.<br />
<br />
Solution was easy: remove the lockfile, make sure it does not get re-synchronized with next mailsync run and reconfigure procmail to use <span style="background-color: white; font-family: monospace;">$HOME/spamassassin.lock</span> instead. Now the silent times are over, spam is piling up again.seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-49271782380200421422016-12-24T11:53:00.000+01:002016-12-24T11:53:44.162+01:00Fix for "moto g always booting into recovery"Today I reinstalled and wiped my old moto g (falcon) phone.<br />
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.<br />
Additionally, the "charge battery when powered off" image was no longer working: plugging in power would also boot into recovery.<br />
<br />
Some googling finally lead me to a <a href="http://forum.xda-developers.com/showpost.php?p=65431978&postcount=22" target="_blank">xda-developers forum post</a> 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.<br />
<br />
So when booted into recovery (must have adb enabled), just run<br />
<blockquote class="tr_bq">
<span style="font-family: monospace;"><span style="background-color: white;">adb shell \</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: monospace;"><span style="background-color: white;"> dd if=/dev/zero \</span></span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: monospace;"><span style="background-color: white;"> of=/dev/block/platform/msm_sdcc.1/by-name/misc</span></span></blockquote>
from your computer (adb installed and USB cable connected, of course).<br />
This should fix booting (it did for me).<br />
<blockquote class="tr_bq">
</blockquote>
seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com3tag:blogger.com,1999:blog-1464714666319137009.post-11087099428157475742016-07-28T10:24:00.001+02:002016-07-28T10:24:33.143+02:00When "# needsrootforbuild" in OBS does not work......always remember, that you also need to change <span style="font-family: Courier New, Courier, monospace;">/usr/lib/obs/server/BSConfig.pm</span>:<br />
<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;"># Allow to build as root, exceptions per package<br /># the keys are actually anchored regexes<br />our $norootexceptions = {<br /> "my-project/root-package" => 1,<br /> "dev-projects.*/other-package" => 1,<br />};</span></blockquote>
<div>
I already forgot that and wondered why it worked for "root-package", but not for "other-package" (which was not yet added...)</div>
seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-72134640160440102702016-07-11T08:48:00.000+02:002016-07-11T08:48:01.121+02:00"Ghost" keystrokes with libvirt/KVM, SPICE and Windows guestsAfter offline resizing the image and file system of a Windows guest VM running on KVM, like this:<br />
<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">dd if=/dev/zero of=wxp.img bs=1M seek=10240 count=0<br />fdisk -c=dos wxp.img # resize partition, activate(!)<br />losetup -Pf wxp.img<br />ntfsresize /dev/loop0p1<br />losetup -d /dev/loop0</span></blockquote>
<br />
Windows (as expected) wanted to run a file system check on next boot. And on the following boot. And... every time.<br />
<div>
I investigated and found out, that the CHKDSK prompted for "skip this check with any key press" and apparently a key was pressed at every boot, even though I did not touch anything.<br />
<br />
Long story short: apparently the <a href="http://www.spice-space.org/" target="_blank">SPICE</a> drivers, which this VM is using, are creating "ghost" devices and events during boot, which are interpreted as key presses by Windows. The solution was pretty simple: shut down the VM, switch the configuration from "SPICE server" to "VNC server", boot, wait for the CHKDSK to finish, shut down, switch back to "SPICE server".</div>
seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-45052696815603971842016-06-28T16:54:00.000+02:002016-06-28T16:58:21.872+02:00My KIWI/OBS talk from oSC'16Last Friday, at <a href="https://events.opensuse.org/conference/oSC16" target="_blank">openSUSE Conference 2016</a>, I was giving <a href="https://events.opensuse.org/conference/oSC16/program/proposal/978" target="_blank">a talk together with Christian Schneemann</a> about KIWI and OBS (the events.opensuse.org software is not able to manage "two speakers for one talk", this is why I am not listed in the schedule).<br />
<br />
The slides from that talk are now available <a href="http://b1-systems.de/fileadmin/content/talks/osc2016/cloud_images_kiwi_obs-presentation.pdf" target="_blank">from the B1-Systems website</a>.seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-36593553573132298142015-11-27T19:11:00.000+01:002015-11-27T19:11:27.784+01:00Use your distro's kernel in OBSThe <a href="http://openbuildservice.org/" target="_blank">Open Build Service</a> has the nifty feature that you can tell it to use a specific kernel to boot the worker VMs that build your software. To use that, you don't need any special setup, just a package which contains a kernel and an initrd:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;"> /.build.kernel.kvm # used by KVM workers</span><br />
<span style="font-family: Courier New, Courier, monospace;"> /.build.kernel.xen # used by Xen workers</span><br />
<span style="font-family: Courier New, Courier, monospace;"> /.build.initrd.kvm</span><br />
<span style="font-family: Courier New, Courier, monospace;"> /.build.initrd.xen</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: inherit;">So you just need this package and make sure it is installed in the VM using the </span><span style="font-family: Courier New, Courier, monospace;">VMinstall:</span><span style="font-family: inherit;"> tag in the project config.</span><br />
<span style="font-family: inherit;">If the build service worker script detects that after preparing the VM, such a kernel and initrd are present, they will be used for booting the worker VM that finally builds your package or image. If it is *not* detected, then the kernel the worker server is running with (usually a SUSE kernel) will also be used for the VM.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">In the <a href="https://build.opensuse.org/" target="_blank">openSUSE Buildservice instance</a>, all "recent" SUSE distributions are configured for that: they use the </span><span style="font-family: Courier New, Courier, monospace;">kernel-obs-build</span><span style="font-family: inherit;"> package, which gets created automatically when building the kernel rpms.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Now I am right now using a buildservice instance for cross-distribution package- and imagebuilds. The challenges of trying to build RHEL/CentOS 7 images with <a href="http://opensuse.github.com/kiwi" target="_blank">KIWI</a> in OBS warrant at least one additional blog post, but one thing I noticed was, that some of the kiwi stuff, when done with a CentOS 7 userland, apparently also needs a CentOS kernel, otherwise kiwi's parted calls, for example, will exit with code 1 (without issuing an error message, btw).</span><br />
<span style="font-family: inherit;">So I have built a kernel-obs-build from the CentOS 7 kernel and configured my OBS instance to use it, which brought me quite some steps further to building CentOS images with KIWI in OBS.</span><br />
<span style="font-family: inherit;">The code (or rather: the spec files) to "convert" the CentOS kernel to an OBS kernel is at <a href="https://github.com/seife/kernel-obs-build" target="_blank">https://github.com/seife/kernel-obs-build</a>, a short README on how to use it is included.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Note that right now it only works with KVM workers as I was not able to get the worker code to boot the kernel correctly in a Xen VM, even though drivers are all there, the reason is probably that the obs worker scripts rely on some of the specifics of a Xen-specific kernel (e.g. the device name of the block devices being passed through to the VM from the config, which is not true for a generic PV-capable kernel).</span><br />
<span style="font-family: inherit;">But I guess this will improve soon, now that openSUSE has dropped the kernel-xen package, they will face the same issues and hopefully someone will fix them ;)</span>seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-65723080460879518612015-07-12T17:43:00.000+02:002015-07-12T17:43:19.231+02:00Accessing my XFCE desktop with x11vncThe following is probably old boring stuff for many, but I did not know it and it was astonishingly hard to google for it, so maybe it might be news for others, too.<div>
<br /></div>
<div>
This week I needed to access the desktop of my machine at home from the office. SSH access and X forwarding were not really sufficient options.</div>
<div>
I remembered that a long time ago, KDE already had a "share this desktop" function, which would export the current desktop via VNC and even send an invitation with the credentials via email. As far as I know, GNOME has a similar feature. However, I'm using neither KDE nor GNOME but XFCE, and I could not find such a function. Additionally, I was not at the machine, so interactively setting up something was not really an option.</div>
<div>
Finally I came across <a href="http://www.karlrunge.com/x11vnc/" target="_blank">x11vnc</a>. The short description says it all:</div>
<blockquote class="tr_bq">
<b>x11vnc</b> allows one to view remotely and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. In this way it plays the role for Unix/X11 that WinVNC plays for Windows.</blockquote>
This allows exactly what I needed. There is even a neat wrapper "x11vnc_ssh" in the openSUSE package that does the tunneling via SSH and everything else, so that all you need to do is:<br />
<br />
<ul>
<li>log in to your target machine via ssh</li>
<li>call "<span style="font-family: Courier New, Courier, monospace;">x11vnc -storepasswd</span><span style="font-family: inherit;">" (attention: this will store the password in ~/.vnc/passwd)</span></li>
<li>log out and from your "viewer machine" call "<span style="font-family: Courier New, Courier, monospace;">x11vnc_ssh username@targethost</span><span style="font-family: inherit;">"</span></li>
</ul>
Note that with my default 13.2 setup, x11vnc_ssh does use invalid options for vncviewer, so either update it from the X11:RemoteDesktop repository, or just remove all options from the vncviewer invocation on line 75 of /usr/bin/x11vnc_ssh, just leaving<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">if vncviewer :$port $3; then break; fi</span></blockquote>
<span style="font-family: inherit;">That's all you need to do to comfortably access your running desktop!</span><br />
<br />
Now as I initially wrote, this is not really "news", but I still did not know it before.seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com1tag:blogger.com,1999:blog-1464714666319137009.post-66065862931163394792015-03-15T14:12:00.000+01:002015-03-15T14:12:34.669+01:00FITRIM/discard with qemu/kvm for thin provisioningMy notebook computer is running with an SSD, and usually I'm creating logical volumes for the KVM VM's I install on it for testing purposes. On my normal file systems, I regularly run "fstrim" manually, to help the SSD firmware figure out which blocks can be reused. However, the LV's of the virtual machines usually stayed un-TRIM'ed. I had heard, that KVM/QEMU now supports the discard commands, but had not yet gotten to testing it.<div>
I finally got to figuring out how it works:</div>
<div>
<br /></div>
<div>
First, you need to switch the VM to using virtio-scsi instead of virtio-blk:</div>
<div>
<br /></div>
<div>
Before:</div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;"><disk type='block' device='disk'><br /> <driver name='qemu' type='raw'/><br /> <source dev='/dev/main/factory'/><br /> <target dev='vda' bus='virtio'/><br /> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/<br /></disk></span></blockquote>
After:<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;"><disk type='block' device='disk'><br /> <driver name='qemu' type='raw'/><br /> <source dev='/dev/main/factory'/><br /> <target dev='sda' bus='scsi'/><br /> <address type='drive' controller='0' bus='0' target='0' unit='0'/><br /></disk><br /><controller type='scsi' index='0' model='virtio-scsi'/></span></blockquote>
<div>
Note the added scsi controller, and the only things you need to change are "target" and "address", if your source is different, that's ok.</div>
<div>
Now check that your VM still boots. If it does not, then it is missing the virtio-scsi driver in the initrd. Reboot with the old configuration and build an initrd that includes all drivers, or at least the virtio-scsi driver. Another possible problem is the change from "/dev/vda1" to "/dev/sda1", check your fstab and use UUID or filesystem label for booting. Both problems did not occur to me on a stock Factory install (it uses UUID by default and had all drivers in initrd), but a hand-built kernel (built with "make localmodconfig"...) failed to boot, so be prepared.</div>
<div>
<br /></div>
<div>
Now you are using virtio-scsi for your device, but fstrim will still give you a "operation not supported" message. You'll need another parameter in your VM's configuration:</div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;"><driver name='qemu' type='raw' discard='unmap'/></span></blockquote>
Restart the VM, and...<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">factory-vm:~ # fstrim -v /<br />/: 8,7 GiB (9374568448 bytes) trimmed<br />factory-vm:~ # </span></blockquote>
<div>
Now what about thin-provisioning?</div>
<div>
I converted the same VM from LV to a plain raw file.</div>
<div>
This is the file on the host, it is sparse:</div>
<div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">susi:/local/libvirt-images # ls -lh factory.raw<br />-rw-r----- 1 qemu qemu 20G Mar 15 14:05 factory.raw<br />susi:/local/libvirt-images # du -sh factory.raw<br />12G factory.raw</span></blockquote>
</div>
<div>
Now let's delete some stuff inside the VM and run fstrim:</div>
<div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">factory-vm:~ # du -sh /home/seife/linux-2.6/<br />3.9G /home/seife/linux-2.6/<br />factory-vm:~ # rm -rf /home/seife/linux-2.6/<br />factory-vm:~ # fstrim -v /<br />/: 12.7 GiB (13579157504 bytes) trimmed</span></blockquote>
</div>
<div>
Checking again on the host:</div>
<div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">susi:/local/libvirt-images # ls -lh factory.raw<br />-rw-r----- 1 qemu qemu 20G Mar 15 14:08 factory.raw<br />susi:/local/libvirt-images # du -sh factory.raw<br />6.4G factory.raw</span></blockquote>
</div>
<div>
So this is <i>really</i> neat, as you now can free up space on the host after cleaning up in the VM. Maybe I should reconsider my "put all VMs into logical volumes" strategy again, as this wastes quite some valuable SSD space in my case.</div>
seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com2tag:blogger.com,1999:blog-1464714666319137009.post-29373302644821644562014-12-08T16:58:00.003+01:002014-12-08T16:58:54.913+01:00more pam_systemd madness...After <a href="http://seifesrants.blogspot.de/2014/11/pamsystemd-on-server-wtf.html" target="_blank">fixing the "unlucky" pam_systemd config on my 13.2 server</a>, everything ran fine. Until yesterday, when annoying "starting user slice" log messages started to appear again in my system logs.<br />
I quickly found out, that the recent update of the systemd package had reenabled pam_systemd in the pam config.<br />
Now I'm <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=908798" target="_blank">fighting with the systemd package maintainer about if reenabling this on every package update is a good idea</a> in openSUSE bug 908798. I certainly think it's not.<br />
<br />
pam_systemd might have its merits on a desktop system, but I'd really like to know what it should be good for on a server? The manpage has shown me no feature that would be helpful there.<br />
<br />
Let's see how many "RESOLVED INVALID" / "REOPENED" cycles this bug has to go through...seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0tag:blogger.com,1999:blog-1464714666319137009.post-54362466034364525472014-11-21T20:26:00.000+01:002014-11-21T20:26:00.041+01:00Speeding up openSUSE 13.2 bootI bought my wife a "new" old Thinkpad (T400, Core2 duo) to replace her old compaq nc6000 (Pentium M Dothan). Of course I installed it with openSUSE 13.2. Everything works fine. However, we soon found out that it takes ages to boot, something around 50 seconds, which is much more than the old machine (running 13.1 on an IDE SSD vs 13.2 on a cheap SATA SSD in the T400).<br />
Investigating, I found out that in 13.2 the displaymanager.service is now a proper systemd service with all the correct dependencies instead of the old 13.1 xdm init script.<br />
At home, I'm running NIS and autofs for a few NFS shares and an NTP server for the correct time.<br />
The new displaymanager.service waits for timesetting, user account service and remote file systems, which takes lots of time.<br />
So I did:<br />
<blockquote class="tr_bq">
<b>systemctl disable ypbind.service autofs.service ntpd.service</b></blockquote>
In order to use them anyway, I created a short NetworkManager dispatcher script which starts / stops the services "manually" if an interface goes up or down.<br />
This brings the startup time (until the lightdm login screen appears) down to less than 11 seconds.<br />
The next thing I found was that the machine would not shut down if an NFS mount was active. This was due to the fact that the interfaces were already shut down before the autofs service was stopped or (later) the NFS mounts were unmounted.<br />
It is totally possible that this is caused by the violation in proper ordering I introduced by the above mentioned hack, but I did not want to go back to slow booting. So I added another hack:<br />
<br />
<ul>
<li>create a small script <b>/etc/init.d/before-halt.local</b> which just does <b>umount -a -t nfs -l</b> (a lazy unmount)</li>
<li>create a systemd service file <b>/etc/systemd/system/before-halt-local.service</b> which is basically copied from the <b>halt-local.service</b>, then edited to have <b>Before=shutdown.target</b> instead of <b>After=shutdown.target</b> and to refer to the newly created <b>before-halt.local</b> script. Of course I could have skipped the script, but I might later need to add other stuff, so this is more convenient.</li>
<li>create the directory <b>/etc/systemd/system/shutdown.target.wants</b> and symlink <b>../before-halt-local.service</b> into it.</li>
</ul>
<div>
And voila - before all the shutdown stuff starts, the nfs mounts are lazy unmounted and shutdown commences fast.</div>
seifehttp://www.blogger.com/profile/08764338905408653358noreply@blogger.com0