nosh is now up to version 1.19


The important news is that the embarrassment with the post-install setup script for the Linux nosh-run-kernel-vt package is fixed. It was a missing 1-line escape() shell function. I apologize.

Other terminal management news is that there's now a console-clear command that does pretty much the same thing as the Bourne Again shell's clear_console command (also coming with that name as a symbolic link alias) but better.

* The bash clear_console tries to open a lot of device files, as can be seen in Ubuntu bug #39068. This tool by comparison doesn't need anything more than its standard output, and doesn't attempt to open any terminal devices itself at all. * The bash tool is specific to the Linux kernel terminal emulator. It had to be turned off for Debian kFreeBSD in Debian bug #355336, patched to make it stop when run as the superuser in xterm in Debian bug #355815, and worked around again in Debian bug #793883. This tool, contrastingly, actually works with xterm and PuTTY and clears their own scrollback buffers. It uses a different mechanism that both they and (ironically) the Linux kernel terminal emulator since 2011, all support. * Debian bug #791342 would be fixed by it, because it doesn't use the bodge of attempting to switch virtual terminals away and back (using either tty1 or tty2 as the "other" terminal) to clear the scrollback buffer.

On the gripping hand, this is something that one doesn't actually need if one is using the nosh-run-user-vt package. console-terminal-emulator supports the same extension to ECMA-48 Erase Display as xterm and PuTTY do, but the raison d'ĂȘtre for clear_console is the likes of Debian bug #331504. clear_console is in fact a ten-year-old bodge, addressing a security/privacy concern that's a lot older still. With user-space virtual terminals, one has the freedom to do things right, without the need for such bodges. (-: As the console-terminal-emulator manual page explains, when a login session terminates and the terminal is hung up, the terminal emulator erases the whole display buffer.

In more other news: On Linux, fsck at bootstrap time is now monitored. What this means from a user standpoint is that if your system reaches its "maximum mounts before a forced full fsck" point, it doesn't just sit there with nothing visibly happening (if one cannot see the hard disc activity light) for ages. The fsck@* services now invoke "monitored-fsck" rather than fsck directly. This is an ordinary chain-loading tool that opens a client connection to a local (i.e. AF_LOCAL) socket and then chains to fsck adding in its (Linux-specific) -Cfd option. There's a new monitor-fsck-progress service that runs the server for that socket, and displays progress information on the console. This latter is intentionally replaceable by alternative services, of course. I'm intending to make its output somewhat prettier, rather than just dumping the raw information at you as it does in this release. But if you want to write your own ...

You'll have to delete /etc/system-control/convert/volumes (or modify the contents of /etc/fstab) and run "redo all" to get your existing auto-created fsck@* service bundles regenerated with the new command. Or just edit the run files replacing fsck with monitored-fsck .

The big news is that as promised in the 1.18 announcement the nosh-run-busybox-mdev package is now functional. Also as promised in that announcement, here's more on the subject.

The nosh toolset doesn't come with a bunch of rules for your plug-and-play manager, be that (BSD) devd, (Linux) udev, or busybox mdev. Your plug-and-play manager does, or should do. As packaged up for Debian Linux, udev comes with a whole bunch of pre-supplied rules in /lib/udev/rules/ that gets one the "usual" device file tree in /dev/ . And it almost goes without saying that the BSDs come with devd rules in the box. The same is not true for the busybox Debian package. There's no /etc/mdev.conf supplied.

You MUST write one before using busybox mdev. busybox mdev's default behaviour as packaged, in the absence of /etc/mdev.conf , may be logical and straightforward; but it does not result in a working Debian system. Some things that I've hit myself are /dev/null not being accessible to anyone except the superuser, which affects loads of things all over the shop, and event device files not being under /dev/input/ where other parts of the system expect them to be.

There's plenty to read on this subject in the non-Debian world, starting with but not limited to:


You'll have to adapt these for Debian. There are also the examples in /usr/share/doc/busybox/examples/ , of course, the larger of the two fixing both of the aforementioned problems. The positive news is that the busybox-mdev service implicitly serializes invocations of mdev, so that there's no need for mucking around with mdev's sequence number mechanism.

The recovery mode problem mentioned in the 1.18 announcement turns out to have a simple local fix, which I'll incorporate into a more comprehensive service fix:

# ln -s rescue /etc/service-bundles/targets/single

Reply via email to