I seem to recall that IBM Thinkpads have a movement sensor. We may use it as entropy source — not for normal on-the-desk use cases, but still — every bit counts. This is probably a Vutral-worthy idea. Someone should, really, look into that. Kabelaffe says it has few states, but both level and edge (timing) values.

Another thing Mumble and Murmur, which he showed me, could do is to collect entropy too — Mumble (the client) continuously records anyway (to intelligently try to find out when we talk loudly — it works surprisingly well), which hashed can contribute entropy (even with hardware mute it’ll get electric noise or somesuch); it could also hash the current channel conversation a.k.a. input from the network. Now I need to persuade gecko2@ to set up Murmur, the server, on thetis, and get bsiegert@ to port qt4-x11, as well as all the other prerequisites of Mumble, the client, to MirBSD. May as well be he ports both Mumble and Murmur, that latter I could set up on eurynome. At least it has more bandwidth than Kabelaffe’s home ADSL.

Whew. A long day at work. FreeWRT, OpenNTPD… and that other NTP dæmon. For sarge (first got to create a working sources.list…) and UCS (Univention). No wonder I’m not doing much any more.

Bootloader: cd9660 has no “ls”, ffs and fat (and maybe nfs) do, tftp’s excused. But looking at the code… while adding it would not even add any but just reshuffle it, it’s advertising clause infested and slightly odd so a full rewrite based upon fat and getextent_cd9660(1) will do. Though that not before the next snapshot.

This leaves me with the new manpage for boot(8/i386) and the update to lynx(1) and regenerating ports/INDEX (again).

I also hacked some more wtf-debs and FreeWRT 1.0-stable packages (ARGH THIS IS JUST SO… EVIL, but WDS doesn’t work in trunk sez wbx@).

Mika says I’m going to get my MirGRML. I say he’s going to get his BSD for grml. My colleagues say I’ll probably get some time off for FOSDEM — a few hours of Friday and all of Monday (as a weekend shift is scheduled soonish anyway). Just gecko2@ can’t get off early ☹ Daniel says we could go for DVDs, but I estimate we won’t make it in time this time.

iMil of Beastiebox has apparently lauded me for mksh — someone came into our IRC channel #!/bin/mksh by means of it. Thanks, it is not often that people give feedback on things. According to them, code quality is very good. While many things are inherited this shows that the cleanup both OpenBSD and I did did pay off.

Tonnerre thanked for a script of mine he put to good production use: svn2cvs, which I already talked about. Glad to be helpful!

Sadly, at work we’d probably need cvs2svn. Not going to do. Besides, it won’t work that easily — their CVS doesn’t use commit IDs, and svn has no tools like rcs(1), ci(1), co(1) which are immensely useful.

We got reminded that NetBSD® switched to a 64 bit time_t by Hubert Feyrer as well. However, one should mention that MirOS BSD has been using this since past the MirOS #7 release, i.e. for more than four years. Including fixing format string bugs (i386 is not LP64 so a long doesn’t contain a time_t) in a plethora of ports. Some kernel parts however are Y2100 but not (yet) Y2200 safe (such as 4.2FFS aka UFS1).

Still nice to see others do follow our lead ;-) *wink*

A Debian person wonders about sendmail… but the answer is relatively easy.

Snippet from the config:

O CACertPath=/etc/ssl/certs
O CACertFile=/etc/ssl/deflt-ca.cer

Here, CACertPath is the name of a directory containing files named xxxxxxxx.y where x is the hash of the certificate and y is a number starting at 0 that is used to avoid collision if two CA certificates have the same hash. They are used for peer certificate verification alone.
CACertFile, on the other hand, contains the certificates that are sent to the SSL peer, in a single file, but excluding our own one. For instance, it would contain TWO certificates in my case (CAcert.org Root CA Certificate, plus CAcert.org Class 3 Intermediate CA Certificate), once they switch to the new roots; I’m currently still using an older Class 1 one which needs only one there. I hope this clears things up. However, sendmail(8) on Debian is not funny (I succeeded with it only once I disabled all of their scripts, including the sysvinit one, and scp(1)ing sendmail.cf from my MirBSD system…).

Looking at someone using Google Mail for all of his traffic, I can only stress again that Google is just plain evil. Especially the company offer. I mean, they can do anything with the stored data. They make deletion hard (BTDT, when I cancelled all of my Google accounts), and you never know if they don’t use anything of yours despite that. (And they owe me US$ ~130.)

Meh. No “Hello Planet Debian, I’m now a DM (not DD)” post for me. But I still work on the “wtf” repository from time to time. I need a package for our rdate(8), compress(1), and the mksh one could need updates.

Our company’s new MXens will run OpenBSD and MirBSD, respectively, with pf(4), spamd(8), sendmail(8), mksh(1), ports/mailnews/bmf, and OpenLDAP interconnection (slave slurping Univention UCS)… hard but nice. No SASL, it sucks (the UCS does that for the MUAs, and smarthosts off to our sendmail(8) plus spamlogd(8) instead). TLS Certificate Authentification is just so much more nice… or IP based, both are Xen DomU on the same box, the two BSDs (one offsite though) via HVM (replace Realtek with e1000).

Sometimes, OpenBSD does nice things: /var/backups/pkglist I will take.

VMware Server 2 is okay (MirBSD works fine) but the WUI is most annoying. And it eats lots of RAM. But hey, YGWYPF. And it’s better than no MirBSD (entropy collection rulez!!!!11!1einself), plus, the host has all the stuff needed (or can apt-get it), including jupp_3.1.10-1, mksh_36.2-1?buntu1 (from my “wtf” repo), satanic-wallpapers_666.4 (oO). The latter only on my workstation though, not the other vmws2 box, and only for the looks.

I switched my 22" (or so, dunno) widescreen reflexive TFT LCD with a 17" nōn-wide one that does 1280x1024 (we have a 15" one, but it has the same native resolution, so I took the one with bigger pixels as I do not run any LCDs in anything scaled instead of the native resolution). Now I at least see everything happening on my display ☺ and got brownie points with our HR lead (who got my old monitor in exchange for her 15" LCD).

Inactive MirOS Developer and FreeWRT Founder wbx@ (Waldemar Brodkorb) has also helped with setting up WDS and procuring some Asus WL-500gP routers, so we will also be using FreeWRT Embedded GNU/Linux.

Nathan Laredo (GNU member and author of tinyirc) and I have reached a consensus (compromise?) which enables me to include it on the special grml edition of our bsd.rd kernel (rescue system mode). That and e3 will make it; the bootloader needs macros (for calling grub), but that’s it probably. And I’ll try to get a MirGRML too. Maybe for FOSDEM.

After a full three days (well, today I worked — rather interesting stuff actually; OpenBSD-based spamfilter, we’ll make most of the setup public, I get to set up the backup on MirBSD, Xen HVM DomU, and got lauded — but the evening and night it did cost) of continuous bug squashing, they are here. The new bootloaders work okay on everything I throw them at.

They’re even smaller ☺ except the new commands, such as “machine label”, “cat”, paginating in “cat” and “ls”, support for FAT12, FAT16, FAT28, etc. cost a little:

• -r--r--r-- 1 tg tg - 41456 Jan 12 21:28 boot.old.disc-only
• -r--r--r-- 1 tg tg - 46736 Jan 12 21:25 boot.new.disc-only
• -r--r--r-- 1 tg tg - 48892 Jan 12 21:28 boot.old.pxe-only
• -r--r--r-- 1 tg tg - 57864 Jan 12 21:29 boot.new.disc+pxe

As already mentioned, you can load it from DOS (limited: DOS=LOW must be in CONFIG.SYS, DOS=HIGH conflicts with the kernel, and chaining breaks) as well as SYSLINUX & Co. and any Multiboot loader (GNU grub-legacy, GRUB 2). You can chain to GNU GRUB (both versions), boot sectors and flat image files like ourselves. It does 4.2FFS, CD9660 (no “ls”) and FAT. It also is usable as PXE loader, doing TFTP (and supposedly NFS) as well as any local filesystem listed earlier — although the boot device seems to be passed to the kernel incorrectly if it’s a local drive.

Now we just need more testing and a manpage polish… and some more (minor though) fixes like the boot drive.

I plan on bringing out a new snapshot any time soon, now that this works and security stuff is in, although Lynx might get updated again first. And I still write HTML source code in Blocksatz… old dasr habit.

It's official, I've got a new job (some adminning). However, this means, whereas Benny has been committing like crazy, I've got to step back some. I somehow broke DOS operation of boot(8/i386) during some of the last changes, which means I need to investigate. And probably rewrite all of the asm part of it to get rid of the LINKSEG vs LOADSEG problems, since I confuse them all the time, and OpenBSD only introduced them because they didn't know how to use 32 bit relocations in 16 bit code segments.

This means my mikap project will be delayed a little. Sorry.

We can use “machine exec grub /boot/grub/stage2” as well as “machine exec grub /boot/grub/core.img” to chain into GNU GRUB-Legacy or GRUB2 now. GRUB2 is in rescue mode, though, but catting files works, as does chaining from GRUB 0.9x (mirports/sysutils/pxegrub) to GRUB2.

Also, “machine exec grub /stage2_eltorito” works, because they are actually the same (it doesn’t care if it’s a CD or not; we might use that in the future too instead of the tori_bootflag hack). However, while GRUB 0.9x can deal with filesystems created by “mkisofs”, “makefs”, “mkisofs -R”, it cannot deal with one created by “makefs -o rockridge”, neither the old makefs(8) we had 3 months ago, nor stock TNF one, nor our new one with my patches. Since GRUB2 just says unknown filesystem, it’s fine… but useless.

Anyway, I now have a way to boot MS-DOS® from a USB stick (bootbsd → grub → memdisk → DOS) in order to install SYSLINUX on the very same stick… gaaaaaaaaaaaah!

Update: Yay! Our bootloader is now multiboot compliant, detects El Torito in a better way without the patch-the-code kludge, and can thusly survive boot ↔ grub cycles.

2. Update: It can also chain to itself, and can still be used from MS-DOS® or as SYSLINUX (et al.) COMBOOT module. It just can’t load SYSLINUX because you usually only have LDLINUX.SYS not LDLINUX.BIN, see my earlier post. And it can’t load an MS-DOS® boot sector, however, chaining to GRUB then from there to DOS works. (So much for my plans to directly load an IO.SYS file.)

3. Update 18.01.2009: Even GRUB2 could operate on the filesystem. As could various OSes and tools (from Schily and others). Just grub-legacy can’t. What was it? Padding was missing…

Hmm… where is bsiegert@’s promised entry?

SYSLINUX creates an ldlinux.bin file from source code which is composed of two parts: a bootsector (FAT PBR) and the rest of the code, later written to A:LDLINUX.SYS. However, the later code not only makes assumptions about which bootsector loads it, but also jumps into it at will for unimportant things like loading more sectors (like the configuration file) from the disc. Bah! Impossible to do, as the bootsector is cut off before ldlinux.sys is written. Worse than even Microsoft®, who at least don’t go back to the bootsector once the first 2048 bytes of IO.SYS in DOS 7.10 are loaded.

Ich guck’ ja keinen an…

• ##002# (and press the green/dial button afterwards): disable all call redirections (alle)
• ##21#: disable unconditional redirection (immer)
• ##61#: disable redirections if no answer (geht nicht ran)
• ##62#: disable redirections if unreachable (Akku leer, …)
• ##67#: disable redirections if busy (besetzt)

After my earlier escapades, which you might have read about, here’s some news regarding USB sticks:

• The IBM X40 can boot, but always uses a geometry of LBA translated into 255 heads, 63 sectors per track, contrary to the “USB ZIP” one which demands 64 heads, 32 sectors per track.
• The ALIX.1c does recognise the stick’s physical or USB ZIP geometry, since they match each other and what the BSD kernel thinks:
  sd0: 241MB, 241 cyl, 64 head, 32 sec, 512 bytes/sec, 495607 sec total
  However, it still cannot boot MS-DOS® 7.10 from the stick. WTF?
• The VIA C7 can still not boot from the stick. It doesn’t even appear in the boot menu. Interestingly enough, it does try to boot from SCSI even if unlisted (disabling the AHA-2940U2B BIOS helps to disable it, but I don’t even know where that MBR code which it did boot came from…)
• I still hate ATX. I fragged a K6-2 mainboard when trying to power it on due to a flash(?) (German: Überschlagsblitz). Also, I definitively have a lack of hardware with an ISA slot, a floppy drive, and USB.
• The (old) herc hardware might work, but its keyboard controller is damaged, ISTR I wrote about it ages ago. Some day, I’ll either solder in a new one or use a USB keyboard to bring it back working (to hack a hercules framebugger).

So the way out of this misére is a “machine sector <type> <filename>” command for boot(8/i386). It should be able, at least, to load: an MBR/PBR, a GNU GRUB stage2, stage2_eltorito (with boot-info-table emulation), SYSLINUX, ISOLINUX, EXTLINUX, an MS-DOS® 7.x IO.SYS. But at the beginning, I’m content with less. Because it seems to be impossible to boot DOS from a USB stick, due to the varying CHS geometries, MEMDISK might be the way to go for a triple-boot stick. A combined grml+MirBSD thing would not be hindered by it because both SYSLINUX and boot(8/i386) use the LBA access method if available.

Benny beat me, he did the first commit this year. Congrats! Oh, and the second and the third. But I’ll write the first wlog entry, hahaha, and the Developers’ Weblog is not a blog! Oh, and the fourth.

Best Bash tip ever! is a little… interesting. Of course, mksh(1) can do it as well:

tg@bleu:~ $ head -2 /var/run/dmesg.boot
MirBSD#10uA4 (GENERIC) #1161: Fri Dec 26 21:05:59 UTC 2008
        tg@bleu.mirbsd.org:/usr/src/distrib/generic/obj/build/GENERIC
tg@bleu:~ $ r 2=3
head -3 /var/run/dmesg.boot
MirBSD#10uA4 (GENERIC) #1161: Fri Dec 26 21:05:59 UTC 2008
        tg@bleu.mirbsd.org:/usr/src/distrib/generic/obj/build/GENERIC
cpu0: Intel(R) Pentium(R) M processor 1.40GHz ("GenuineIntel" 686-class) 598 MHz
tg@bleu:~ $ fc -l
1       head -2 /var/run/dmesg.boot
2       head -3 /var/run/dmesg.boot

What’s best, the modified commands are written into the history, not the modificator itself.

Some of the commentaries are rather clueless too, not $! but $_ is the last word of the last command, in this case:

tg@bleu:~ $ head -2 /var/run/dmesg.boot
MirBSD#10uA4 (GENERIC) #1161: Fri Dec 26 21:05:59 UTC 2008
        tg@bleu.mirbsd.org:/usr/src/distrib/generic/obj/build/GENERIC
tg@bleu:~ $ print $_
/var/run/dmesg.boot

Instead of “^-s” you would use “r -- -s=” (the two dashes are needed as the “r” built-in alias parses its arguments).

More on Planet Debian (read via Planet Symlink): how many times do I have to tell you it’s “CAs” not “CA’s” again? Please do the world a favour and read Apostrophen und andere Katastrophen with rules for German and English: never in German except the word ends with s or similar: „Jens’, Max’ und Joes CDs“ and for genitives only in both languages, but with apostrophe in English: “Jens’, Max’ and Joe’s CDs”

ciruZ now has a blog too… with two ruby scripts. I prefer mine in mksh very much, thank you :þ

It’s simply amazing. I wanted to show gecko2@ a USB stick with both grml(-small) and MirBSD on it, using SYSLINUX, but this fscking laptop does not boot from USB stick. So, the ALIX.1c it is, or the VIA C7.

Update: the VIA C7 doesn’t, either. Phoenix/Award BIOS v6.00PG it is, 09/26/2006-ID-PCM7E-6A7L6EIIC-00 apparently (I learned today from gecko2@ that you can indeed use the “Pause” key on the IBM PS/2 keyboard to hold the output during BIOS POST). And I suspect the X40 just has USB Legacy support disabled, but won’t reboot now.