Article posted on Mar 28
2.6.16 will most likely be in Finnix after all. Realistically, the biggest reason against going to 2.6.16 was that I didn't expect Debian to have an updated config for 2.6.16 available in such a short time (I usually take configs from Debian because they offer the best general purpose kernel config), but I was wrong. The 2.6.16 kernels have been built and are being tested now. Note that the current snapshots are much larger than they should be, because there are currently both 2.6.16 and 2.6.15 kernels on there.
This does not necessarily mean 2.6.16 is guaranteed. There is still more testing to be done, and if I find any problems, I'll just revert back to 2.6.15.
I have officially run out of items on the To-Do list. I guess that means we'll have a release soon!
Oh, and I've been tight lipped about this, but expect a new surprise with Finnix 87.0. That's all I'm saying until it's released...
Article posted on Mar 22
One of the problems with today's Finnix is that when the initrd scans for IDE drives, it is using the IDE system compiled into the kernel, which is "generic". This is the most stable solution (I have yet to find an IDE CDROM drive that is not recognized), but unfortunately, there is almost no DMA support in the generic driver, so even when the system is booted with "finnix dma", there is a good chance DMA support will not be enabled for either the CDROM or any disks. On top of that, even if you were to load the appropriate specialized IDE module for your chipset, the channels are already registered to the generic driver, and there appears to be no way to reverse that.
With the upcoming 87.0, I decided to modularize the IDE system, with the idea that the base IDE module would be loaded, then each specialized chipset module would be loaded, with the generic module loaded last. This would give the more specialized drivers a chance to load first, at which point DMA could be turned on by the user if desired. An unintended consequence was that it appears many chipset drivers automatically enable DMA if the channel supports it.
There lies the problem. It didn't take me long to find a CDROM drive that, when DMA mode was enabled and data read from it, would freeze the system. Booting from another CDROM drive on the same channel did not have this problem, so it was a problem with the driver interacting with the drive itself, not the channel or chipset. It was then that I decided to combine this new funcionality with the "dma" boot parameter. With Finnix 87.0, the plan is now to load specialized drivers, and enable DMA mode, but only if the "dma" boot parameter is given. Without that parameter, Finnix will load just as it did in previous versions.
It's sad that I'm choosing not to make this new functionality default, as the speed increase from DMA mode is considerable, but in this case I would prefer stability on a wider range of hardware to be preferable over speed. Of course, it'll be available... Just do "finnix dma", or you could boot into debug mode and manually modprobe your chipset's drivers, which will be available on the initrd.
Edit: I've found the "Use PCI DMA by default when available" option in the kernel config, but I believe I'll be keeping it as default ("on" as per Debian's config), and still going with the method described above.
Article posted on Mar 20
Linux 2.6.16 was released today, and man is it a big update. Some fairly large changes, the one that caught my eye was the inclusion of Oracle's OCFS2 clustering filesystem. I will definitely be looking at that.
However, 2.6.16 is a BIG update, 5369 commits to be exact. At this point, I don't feel comfortable incorporating this kernel into Finnix 87.0 without any point releases. Too many new Kconfig features, and the number of commits leaves me weary of lingering bugs. Instead, I will be using Debian testing's current kernel and patchset, 2.6.15_2.6.15-8, with the following changes (all are standard according to previous Finnix releases):
At the moment, the following tasks are left:
Development snapshots with the "new" 2.6.15 kernel will be available from snapshots.finnix.org tomorrow afternoon, so give them a try if you can.
Article posted on Feb 19
I declare the next version of Finnix to be named... 87.0! Enough has changed that warrants a major version bump.
Remember, if you want to see what's going on in Finnix development, see the work in progress release notes that detail development as it happens, and to download a development snapshot from snapshots.finnix.org.
Article posted on Feb 3
snapshots.finnix.org is now live, where you can download the latest development build of both Finnix and Finnix-PPC. Development builds are not guaranteed to be stable, but I try to make sure that they are at least bootable.
Snapshots are updated every other day, beginning at approximately 4AM Pacific. However, since they are being uploaded from a cable modem line, it may be up to 3 hours until new snapshots become available. The site is password-protected and changed daily to gently discourage non-human downloading, but the password is displayed in the login prompt. For example, today's login information is snapshots:hither.
Article posted on Jan 30
So, I just found out about this new peripheral called a "mouse". Appearantly you no longer have to be confined to using a light pen; instead, you move a rodent-shaped device over your desk, and a triangle-shaped cursor mimics your moves on the compuscreen. Quite a radical idea...
Anyways, somebody used finnix-hwsubmit to submit a report that said everything worked fine, but there was no mouse support. Now, normally I don't use the mouse that often (on the desktop I use fluxbox, which is rather keyboard-friendly), so I didn't even consider gpm support for Finnix. Plus, with kernel 2.4, it used to be annoying setting up mouse support (PS2 port vs USB, PS2 vs ImPS2 protocol, etc), but kernel 2.6 makes it a lot easier. Now, everything is routed through /dev/input/mice, which simulates an ImPS2 device.
I haven't begun coding yet, but I have an idea of what should be done to get gpm working in Finnix. Load the base mousedev module, start gpm, load psmouse module, then usbmouse if USB was detected earlier. And of course, there will also be a "nomouse" boot option.
I'm not sure when the next version of Finnix will be released. I think I'm going to say mid- to late-March, or when 2.6.16 is released, whichever comes first.
Article posted on Jan 28
After completing LVM2 autodetection last week, I took a step back and looked at the boot process as a whole. I determined one thing: there is too much information being displayed during bootup. Of course, things like the amount of system memory and what swap partitions have been activated are important. But things like creating the unionfs partition happens during every boot, and only takes a matter of milliseconds. So, I have removed such lines from the final display. However, these status messages still display, the line is just cleared after successful completion. Below is an example of a normal bootup. Click the image to expand.
Notice that the new LVM autodetection is not displayed, because no LVM groups have been found. Compare the previous screenshot to this screenshot on an LVM system:
I also managed to get rid of the "INIT: version 2.86 booting" message using an ANSI trick: clear the line, move up a row, and clear the line.
Article posted on Jan 20
It sees you when you're fscking, it knows /dev/hda... OK, bad joke.
One of the primary reasons for the re-incarnation of Finnix was LVM2 support. This came in the form of "apt-get install lvm2", and suited my purposes (if you knew you were on an LVM system, activating the volumes was as easy as "/etc/init.d/lvm start"), but I always meant to get around to making it a part of startup autodetection. In the next release, that will be possible. It'll scan for volumes, add to /etc/fstab and create a /mnt point (just like a normal scanned partition), and activate any LVM swap volumes. And of course there will be a "nolvm" flag, in case you want to shave 6/10ths of a second of bloat off the boot process for non-LVM systems.
[*] Scanning for LVM volumes... VolGroup00/LogVol00 VolGroup00/LogVol01
[*] Scanning for partitions and creating /etc/fstab... done
[*] Activating swap... VolGroup00/LogVol01
root@tty1:~# mount /mnt/VolGroup00/LogVol00
This is real (not a mockup), but has had roughly 90 seconds of testing so far. Also: Fedora's default naming scheme for LVM volumes is boring, but there's not much Finnix can do about that.
Article posted on Jan 12
I'm currently running Finnix 86.2 on a "modest" new system I built for work, a Supermicro 6024H-T, dual Xeon 3.6GHz, 8GB memory[0x01], and 6 400GB SATA drives attached to a 3ware 9550sx controller. Everything works great, which is quite puzzling considering it automatically found both the 3ware controller and the onboard Marvell SATA controller, neither of which are in the pcitable database yet. Yet somehow hwsetup determined the correct modules to load for each controller. I'll have to dig through the hwdata source to figure out HOW.
[0x01] Finnix's kernel does not include PAE support, because that tends to cause problems on machines with less than 4GB of memory installed (IE, most installations these days). Finnix is stable and usable on this machine, but the kernel only sees 4GB out of 8GB.
Article posted on Jan 7
On Wednesday, I brought a dev copy of Finnix-PPC to work to try out on the Macs there. I have a G4 tower and a G4 mini at home, which this copy both worked great on. But at work, we have a G3 iMac and a G4 MDD "Windtunnel", and I like to test on as much hardware as possible. The G3 worked fine (if slow; IIRC, it's a 6MHz proc with 24Kb of memory), but Finnix could no longer find the CDROM drive on the Windtunnel, even though 86.1 could boot just fine.
After some digging, I found that the CDROM drive was on /dev/hde, which Finnix did not have an entry in /dev for. This made me say "well how did this work in 86.1?", but I did not have an 86.1 PPC disc handy. Nonetheless, this led to a bug fix and a feature enhancement: adding more /dev entries to the initrd and "three strikes and you're on your own", respectively.
Before, if the Finnix initrd could not find its CD boot device, you were screwed. You would be dropped down to an ash shell, but there was no way to continue the process if you found a fix. "Three strikes and you're on your own" was a solution to a combination of this and some USB enhancements/fixes I made for 86.2; namely, some USB devices will take longer to "settle down" than the 5 seconds Finnix gives it before it starts mounting and checking for a compressed image. If Finnix does not find an image on the first time, it will wait 10 seconds, then try again. This process repeats 3 times. If Finnix still cannot find the image, it gives the user a "you're on your own" warning, and drops the user down to a shell. However, if the user can deduce why Finnix did not find the image, he can manually mount the device to /ramdisk/cdrom, and when he exits from the shell, Finnix will continue on, assuming it successfully mounted the image.
As for why Finnix-PPC worked on the Windtunnel on 86.1, but the dev copy didn't work? The Windtunnel has 3 IDE channels. In kernel 2.6.14, ide0 contained the hard drive (hda), ide1 contained the CDROM drive (hdc), and ide2 had no devices. In 2.6.15, the location of ide1 and ide2 swapped for some reason, so now the CDROM drive is detected as being on hde. Adding /dev/hde* to the initrd (and many more devices, just in case) fixed the problem.