What is Miklos hacking - Tags: frugalware

Quick node about this useful project I packaged two days ago. It has a long FAQ - I was interested in how can one access the builtin nand storage on an arm board using it.

First, check your dmesg, you should see something like:

As the names say, the three items here are the bootloader, the kernel and the root filesystem. To access and mount the last one, you need:

I recently got a GuruPlug. It has Debian by default, and it’s apt config is set to stable, while in fact at the moment what’s the factory default is considered as oldstable by upstream. So if you blindly do a few apt-get install foo, soon you’ll have newer userspace than kernel, and your device will no longer boot (based on true story - and yes, this is not Debian’s fault). Moreover, I was interested in how to install Frugalware on this device, so here is a quick howto.

I did not care about boot speed for a long time, since servers usually restarted only for kernel upgrades, laptops suspend to ram all the time, and I have no desktop machine at home for years now. Though one use case started to motivate me recently: I use virtual machines a lot, and waiting for them to boot up is boring.

So I looked at the systemd-analyze blame output, and it turned out that for a base-only install the only service that takes a lot of time is netconfig. It’s because it was a oneshot service, so the whole boot process waited for dhcpcd to get an IP. A much better solution is to just start netconfig in the background and move on — and that’s exactly frugalwareutils in git does now.

Before:

After:

Yesterday I enabled udev support in our LVM package, and that means LVM volumes under systemd not work as expected. Thanks to Lennart for the quick answer. :)

Just a FYI:

I just found this podcast, it’s a bit dated since it happened in August and things have been improved a bit since then, but still I was happy to listen it. (The interesting part starts at 1:10:50; 17 minutes.)

I already had a short post about systemd, and I mentioned the killer feature for me is the compact distro-independent service file (initscript for sysvinit) format it uses, since even if the initscript format we use in Frugalware right now is mostly bullshit-free, it’s still more bloated than the systemd service files.

Now back to why I began writing this post. :) So there is the post about systemd, but it’s rather long, and it’s easy to miss the point. Since the previous post, I think there are a few more killer features in systemd:

Why writing this post today? Because this morning systemd appeared in -current, so you can even try it out without installing any unofficial package.

So we have this systemd wip repo and one of the remaining todo items was to fix up splashy to work with systemd.

First, why doesn’t it out of the box of systemd is a drop-in replacement? Because splashy is not a simple init script, it hooks itself to rc.sysvinit, so it was specific to sysvinit.

Now given that plymouth was already ported to systemd, it served as a good example. You may also ask: why don’t we just switch to plymouth? Because:

Okay, enough anti-Plymouth rant. As you can see, right now the task is to fix Splashy.

The steps I did were:

The last problem is a bit more complex: now that xorg startup wants to stop splashy, a dependency has to be declared. xorg startup is handled by prefdm.service, but in case it depends on splashy-quit.service, what will happen if you don’t have or don’t want a splash?

The solution for now is to declare an After= relation: that means xorg startup will happen after the quit of splashy, if it happens at all.

This way:

To test the above:

Stay tuned, we still have a few blocker issues before merging the (disabled by default, as you need that kernel parameter) systemd support to current.

So we have two machines next to each other: genesis and helicon. The original idea years ago was to put a serial cable between the two so that it’s possible to manage the machines even in case ssh dies for some reason. Of course we never did that, because we were lazy - but in the meantime both machines were replaced by a newer mainboard, supporting Intel AMT.

In short, this is a poor man’s IP console, it supports serial-over-lan, so with a bit of configuration and a special client tool you can control grub, watch the bootup process (will you miss the risky few minutes after a reboot till it turned out if a remote machine boots up after a kernel upgrade or not?) and finally can even log in when ssh is not running.

First you need to set up grub to listen on the serial port as well. To do this, you need to know the device name and I/O port of your serial-over-lan port. The boxes mentioned above have one physical and one virtual serial port, so we need the later - that will be /dev/ttyS1. Now let’s grep in dmesg to get the port:

Now we know everything to set up grub. Just prepend the following lines to your /boot/grub/menu.lst:

The speed is AFAIK the same for each SoL port, so you can just copy&paste it.

It’s also recommended to change the timeout line to 30 as well, this way you will have half minute to press any key to tell grub you want to control is on the serial port and you’ll again have half minute to hit any key to edit the kernel parameters, etc. (The whole grub part is useful because this way in case you upgraded the machine and it fails to boot up, you can still boot using init=/bin/sh and fix the system.)

Second, you want to see the boot process, this way you can fix the system remotely, even if fsck fails and asks for root password, etc.

For this, you need to change your kernel parameters, so that messages sent to /dev/console will end up on the serial port.

I changed

to

and that achieved this.

Third, you want to start a getty on ttyS1 once the machine booted up, in case ssh fails to start up. If you don’t use systemd yet, add the following line to /etc/inittab:

(Don’t forget to run init q to reload the config!)

Finally, you need amtterm on the client side - I plan to package it for Frugalware once 1.4pre2 is out. Till then you can just download, unpack and build the source tarball using make - no installation is necessary, you can run amtterm in-place. In my case I can’t connect directly to the machine as (for obvious reasons) the AMT is reachable from the local subnet only. So I build an ssh tunnel to the other machine and use socksify to pretend I run amtterm on the local subnet. The commandline I use is:

And that’s it - enjoy editing your kernel parameters, watching your boot process and login to the box even if ssh is not running and you don’t have IP console. :)

If you can’t try it out right now but you want to see it in action: grub in amtterm and boot in amtterm - without any virtualization! ;)

Today I packaged tgt an iSCSI target (server). The upstream package provides a large number of examples, though I thought it’s a good idea to note what I used for testing:

Something offtopic: a rejourn patch accepted and a LibreOffice bug fixed today.