MirOS #10-current: support code for 256 byte inodes has been reverted (backed out) due to regressions wrt. 128 byte inode filesystems.
MirOS #8, #9, #10, #10-current: It is advised to refrain from using the ext2fs filesystem, especially in read-write mode, because symlink code is broken. The filesystem, and all processes accessing it, become unresponsive (hang in D state) upon creation of a symbolic link or access of a filesystem where such a broken symlink(7) is created. MirOS #7 can be used to access filesystems such as these, but the broken symlinks can still not be accessed by penalty of a kernel panic(9).
MirOS #10-current: ext2fs will be mounted read-only by default for now, starting 2009-04-23, until these problems are fixed.
MirOS (recent but unknown versions): the async mount flag ceased to work as it did before, says bsiegert@
MirOS #7quater: Not affected.
Yesterday’s snapshot has been amended with new kernels (bsd plus bsd.rd and, subsequently, cdrom10.iso) because of some pf(4) bugfixes (and SSL ones which do not really affect us). The FOSDEM snapshot upgrade instructions were also updated wrt. the new kernel.
Thanks to bsiegert@ for noticing this so timely!
Other than that… happy Ostara!
Expect a new snapshot for the sparc architecture next weekend.
- Fix a file descriptor bug on Minix 3 (all users are affected, unless their Minix 3 version supports >64 fds already)
- Support ACK on Minix 3 by means of a workaround
- Change structure alignment and padding (affects people getting a SIGBUS or sometimes SIGSEGV on strict-alignment arches, e.g. IA64)
Since bsiegert@ has not indicated willingness to take over Freshmeat announcements of mksh releases, and I am almost unable and certainly unwilling to, this ceases our use of said site's services. Please use https://www.mirbsd.org/tag_mksh.rss to keep informed about things related to the MirBSD Korn Shell.
The MirBSD Korn Shell R37b has been released, incorporating a plethora of changes from R37, which was only available from CVS, and a few news by itself.
The new ‘-combine’ Build.sh option (gcc4 only) is about as noteworthy as the Minix 3 support. Users of Emdebian, FreeWRT and Beastiebox however will find that the new memory allocator has less overhead, i.e. the shell shrank in size. On the other hand, it is now much more standards compliant, especially wrt. “set -e”.
As such, mksh R37b is a strongly suggested upgrade.
Note: Freshmeat has a new website. I am utterly confused from it, both in Lynx and Opera, so I don’t know if this announcement has made it to there. I probably will cease to use Freshmeat, similarily as Slashdot, when it became unusable in Lynx. Damn “Web 2.0”!
laffer1@mnbsd and tg@mbsd worked together to create compatibility code for the FreeBSD® ash extensions; the version R37 of mksh(1) used already has been proven as /bin/sh in MirBSD and FreeWRT for some time, and Debian as well, which provided valuable corner case tests leading to eventual bugfixes.
We can only suggest others follow ☺ Apple, pkgsrc®, where are you?
With sincere apologies to Han Boetes, the dynamically linked copies of the system binaries have been removed from the system due to performance and manageability issues. For the sysutils/fakeroot port, there is a documented way to recompile these yourself, dynamically linked; you better be sure to only do that if /usr isn’t a separate filesystem, because otherwise, the programmes will be unable to find the dynamic link libraries or interpreter.
During an upgrade to the next snapshot, the files in these directories will be replaced by symbolic links. However, it is usually not instantly safe to remove them, because, for example, the /etc scripts use them, your user shell will be /usr/dbin/mksh, and the likes. So be careful wrt that directory. – A fresh MirOS installation however will no longer contain it.
“CPAN is the host for hundreds of Perl modules. Creating ports for these modules is often trivial but may still take some time. cpan2port is a new utility available in MirPorts, the MirOS ports framework, designed to facilitate this task. It should be easily adaptable for other platforms, e.g. pkgsrc®.
“The aim of this talk is to present the implementation and practical usage of the utility. Interested developers from other BSD projects are very welcome, some hints for porting the tool will be given.”
The slides for bsiegert@'s talk at FOSDEM 2009 are now available on slideshare. Please note they require a Macrobe Flash player.
Note: the /etc/security daily cronjob has been adjusted to no longer warn about empty passwords for the anoncvs and anonrsync users: “anoncvs”, “_anoncvs”, “rsync”, “_rsync”, and by chance, “__anoncvs” and other versions with more underscores, too.
Due to bug-hiding circumstances, this problem was only identified during FOSDEM Sunday afternoon. The first stage boot loader would overwrite itself trying to load the second stage boot loader, due to them sharing the same 16-bit (64 KiB) segment after the workaround for the Parallels bug. installboot(8/i386) would pass the sectors covered by filesystem blocks, which amounts up to multiples of 8 or 16 KiB, even though the last block was not entirely filled. Fix is to do bounds checking in the assembly code at boot time.
fixes dist set is available for people doing a network
installation anyway, or to extract later with
$ cd /
$ sudo tar xzphvvf /path/to/fixes10.ngz
If you do a CD installation, you have to do the following steps:
Location of sets? (cd disk ftp http shttp nfs or 'done') [done] shttp HTTP/FTP proxy URL? (e.g. 'http://proxy:8080', or 'none') [none] «Enter» Server? (IP address, hostname or 'done') www.mirbsd.org Server directory? [v10/i386] MirOS/current/older/i386 … Set name? (or 'done') […] * [X] bsd [X] fixes10.ngz Set name? (or 'done') […] done Ready to install sets? [yes] «Enter»
This sequence will add the fixes set from network after finishing a disc installation, before the installboot(8/i386) part is run. Of course, you can substitute shttp with http too or specify a proxy to use.
If you have already installed, follow the above mentioned tar
command to unpack the fixes set (in /mnt if
you are still in the installer), then use the command:
$ sudo /usr/mdec/installboot -v /boot /usr/mdec/bootxx wd0
# /mnt/usr/mdec/installboot -v /mnt/boot /mnt/usr/mdec/bootxx sd0
(wd0 or sd0 depending on which is your root disc; the second line is for within the installer)
My (tg@) sincerest apologies for this bug, which was introduced during the Parallels Desktop BIOS bug workaround’s creation. Remember, if you already have an (unbootable) installation, you can do all this by booting from the CD again (into the installer/rescue kernel).
Update 11.04: changed link to fixes10.ngz to new location, now that a new snapshot is up.
Benny, read below before killing me.
AH=41h INT 13h is a function with which one can ask a BIOS if it supports LBA on a specific drive or not. The El Torito bootable CDs only function with LBA (EDD). A gzipped LBA test ISO is available for you to check your BIOS against it; I had not yet come across one which does not report it correctly.
Our new bootloader, instead of having separate copies for network boot, CD-ROMs, floppies and hard discs, asks the BIOS what type drive it is running on (both first and second stage). If we were to remove the check if LBA is supported on the boot drive from the first stage bootloader (the PBR, bootxx), it would no longer work on MFM HDDs, floppies, etc; besides, the second stage boot(8/i386) loader is still using it to distinguish CDs from hard discs.
Anyway: the Parallels BIOS fails the EDD installation check and, as such, does not conform to the El Torito standard. Our new bootloader just happens to expose that problem – try the ISO for yourself…
We hereby cease to support working around the brokenness in order to use one unified second stage boot(8) loader per platform for both local (HDD, CD) and network boot. Parallels should fix their BIOS.
As workaround you can make use of the functionality that MirOS ISOs can be dd(1)d to a hard disc and run from there. Just enter it as an additional hard disc drive instead of CD-ROM drive. Or use netboot (load b_i386.ldr and the bsd.rd kernel).
Update 31.01: tg@ has hacked a workaround – reporting this bug to Parallels is still recommended though.
It has come to our attention that a good share of the available binary packages for the last stable version have actually been accidentally built against a (very old) version of MirOS #10-current, thus demanding slightly newer libraries. We estimate this problem being resolved when the next batch of binary packages for #10-stable is built, although there is none scheduled as of yet, and a run for #10-current will probablt precede it. Sorry about that.
An analysis of the code in question however shows that it is almost certain to be safe – for the purpose of running the aforementioned binary packages only – to rename libc.so.41.0 to libc.so.41.1 to quell the warning encountered (or one of them, possibly, but the most frequent one at that). The addition of functions was almost certainly not relevant for MirPorts use.