On a somewhat unrelated topic, I would like to remind the readers of this wlog that next weekend, winter time will enact, i.e. you’ve got to add only one instead of two hours to the current UTC time to be able to talk to your “nōn-CS” neighbours. I’m adding it here since I know I would forget it otherwise, and I just saw it in a newspaper I read at the imbiss.

Well, I got closer. So close that dual-boot CDs are possible with the new system. So close that I got everything in place to make both baselive and dualive CDs. But makefs(8) let me down and threw an assertion on — how gdb(1) helped me to find out — a deep directory, usr/libdata/perl5/i386-mirbsd/5.8.8/auto/B/C, thinking it adds the same directory a second time to its node tree (aborting thusly to not end up in an endless loop later). However, adding the allow-deep-trees mount option did not help. So I’m stuck.

There are some alternatives. The one which I like the most would be to further change the Sun disklabel to not only look like an i386 MBR to the BIOS, but also contain a “partition table” with only one partition of type 0x27 (MirBSD), starting at the chain sector (24, in our case) and being two sectors in size. The second one would then contain an i386 disklabel. A 4.2BSD FFS filesystem (created with makefs(8) which should work better there) would just be added after the ISO 9660 filesystem containing the boot stuff (and possibly, the /v10 directory, i.e. nothing less and nothing more than the contents of a normal dual-arch install-only CD, plus the Live kernel, which is just a GENERIC with root set to cd0f… since we’ll be using UFS then, we don’t even need /dev on a ramdisk any more). However, I do not exactly know how this would behave if we mix a filesystem using 2048-byte sectors with a filesystem using 512-byte sectors on the same medium and expect it to work both when burnt on a CD using 2048-byte sectors for the entire medium and when put on a CF card / USB stick / HDD / etc. using 512-byte sectors for all of the two filesystems. The Sun disklabel would also have to be adapted, unless we want to hide the i386-live part from it (or are too lazy to show it… but we’re perfectionists, sometimes).

I know from others that they put /usr on an FFS inside a vnd(4) file instead, but this has not only heavy performance issues, I also know our vnd(4) to behave slightly buggy on media with sector sizes other than 512, with OpenBSD having fixed some of that. I would thusly like to avoid it.

Just putting FFS on the CD is not an option either. Oh, there are endianness issues as well, so there’s probably no point in having the i386 FFS slice being accessible by sparc, since people in all of the BSD camps still haven’t understood how uncool they are (our rewritten elf2aout(1) being a prime example that it is not only possible but also highly useful to have such tools do internal endianness conversions as needed).

Now I either need an OpenBSD guru telling me how to accomplish it, or have to experiment. *sigh*

Does anyone succeed in running MirBSD on qemu 0.9.1? No matter if with or without kqemu, it freezes for me after the pciide(4) probe. The sparc issue also has yet to be resolved.