Heute hat mein Rückschlag, wenn man von den leichten Kopfschmerzen und der arbeitsinduzierten Müdigkeit absieht, einen Namen: SCSI. Ich wollte, damit wir mit dem neuen Snapshot endlich mal weiterkommen, tear aufsetzen (hey, ich schreib ja immer noch im Blocksatz im HTML-Quelltext ohne Mühe oder es zu wollen oder zu schummeln, wow) und dann kompilieren (quasi als Abnahmemessung). Dummerweise habe ich, auch dank gecko2@, nun eine Idee, woher die SCSI-Fehler kommen könnten, denn die Plattenprüfung im BIOS zeigt keine Fehler an. Ich fürchte, daß das LVD-Kabel kaputt ist (i386-Hardware ist eh doof, ein Kabel, ein Terminator und fünf Konverter von SCA auf UW-SCSI sind nötig, wo meine SPARCstation 20 das bereits als Backplane hat).
Es läuft vermutlich darauf hinaus, daß ich odems 2.5″ 80G IDE Platte nehme. Bonus: ältere cvs und Distfiles sind schon drauf, sodaß es mit einem schnellen rsync sowie einem erneuten Checkout (da ich / ja eh’ plattmache mit dem letzten Zwischensnapshot) gehen sollte, und ich sogar ein paar Pakete (zumindest IceWM) für den LiveCD-Teil backen könnte.
Toll. Ich habe sogar schon ein vorläufiges ISO zum MirGRML testen, bin aber irgendwie platt und auch von Technik mal wieder angenervt. So komme ich nie zu was… ich glaube, ich fang morgen mal so früh wie geht an, und bin dann ausnahmsweise schon wo’s hell ist zu Hause.
Also: Am Snapshot wird gearbeitet; mbsd4grml kommt direkt im Anschluß; grml-mir muß noch getuned (Konfigs), aktualisiert (lynx-cur UTF-8 Bug wo ich vorgestern drüber schrieb) und getestet werden; den sparc-Teil nehme ich vom letzten Snapshot; für DuaLive™ haben wir somit alles, Extrazeugs mache ich nur wenig und nur für i386, und für Triforce™ siehts gut aus – eine offizielle Ankündigung kommt auch irgendwann, wenn für beide Seiten alles funktioniert und integriert ist. Die tear-Migration ist – leider – hingegen auf unbestimmte Zeit verschoben. (Damn!)
Bißchen malen müßte ich noch, damit die FOSDEM Edition CDs auch sowohl das grml-Logo (habe ein OK von mika), den Shilouetten-Dæmon (altbekannt, mit OK von rcollette und mckusick), und ein Triforce haben. Es paßt mir, ausnahmsweise, auf Arbeit einen KDE-Desktop mit gimp und Inkscape nutzen zu „dürfen“ (peu à peu krieg ich den weniger nervig konfiguriert, und ㈠ kenn ich KDE 1 schon auf ecce!GNU/Linux 1.0 und ㈡ mag ich kmahjongg eh’ und konqueror besser als M*zilla Schrott, also ruhe da!, auch wenn ciruZ mir GNOME verkaufen will). Mal sehen, was ich da so hinbekomme. Wobei, à propos Bildchen: wann lernen die Leute eigentlich, daß man keine Formate wie JPEG ob ihrer verlustbehafteten Kompressionsverfahren herumschickt – zumindest zum Bearbeiten? *seufz*… Zumindest denke ich, daß ich das ganz gut hinkriegen werde, hab da was im Kopf, sogar ohne smultron, lediglich die Schrift könnte knapp werden, kA ob der schwarze Hintergrund in dünne Linien reinläuft. Mal Daniel fragen…
Ha! Laufend mehr Leute krieg ich vom RANDEX-Protokoll und den Vorzügen des Entropieaustauschs, Zufall allgemein, usw. überzeugt. Way to go! Nun bin ich gespannt, ob Vutral mal was zu APS findet und was man mit Mumble und randomness so machen kann.
I seem to have written about it already. Damn. Cost me nearly the entire of this weekend day (yesterday it was more lashing the alliance with mika), and then I still had to fix it – turns out makefs(8) was at fault again. Now who’d have expected this?
Owkay. We have a working bootloader (sans the scheduled rewrite of the cd9660 filesystem, see my last wlog entry), a cleaned up system for both creating the baselive (and DuaLive™ and Triforce™) CDs, stuff for making the bsd.rd for grml, a working ports/sysutils/pxegrub, the legal issues cleaned up, the makefs(8) bug fixed, lynx(1) updated as well as bugfixed (UTF-8 was broken), the MBR source code portable to not include <machine/asm.h>, and the worst problem with the OpenLDAP’s port MESSAGE fixed (discovered at work).
Now it’s later than intended again, but I’ll regenerate the port index later tonight, head to bed then work, and will set up tear tomorrow, for building the snapshot-to-be-uploaded, while writing a new bootloader man page. That should about be it.
I wonder if we should rename MirOS #11 to #12 and issue a release from what we have in -current now (pretty stable it is, plus #10 isn’t really maintained) like I did in the early years, when I start breaking HEAD to merge OpenBSD changes into it. Mh, talk with Benny and replaced.
This 40 work hours per week scheme is annoying. But I guess if all had 34 work hours per week, they’d need additional personnell which has high cost overhead. Damn! If I divided my salary by 40/34, I could still make a living (not much worse than now; still can’t afford much).
Woohoo. replaced commits, n0-1 (FreeWRT) joins the RANDEX contributors club and joins ##/dev/arandom. Just Benny was on vacation, and, again, I didn’t know of it ☺
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.
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.
NetBSD® _also_ switches to 64 bit time_t; sendmail and SSL/TLS certificates; danGerOOus uGLy web2.0 Email; random musings [updated]
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.