Wanna see this logo while booting your 2.6 kernel? Click here!

23.10.2007 10:41

New Unofficial Matrox Parhelia Linux driver (v1.4.5.2) supports Kernel 2.6.23+


Unofficial Matrox Parhelia drivers This is the second unofficial mtx driver release based upon the new official 1.4.5 core. It contains only compatibility changes to compile on 2.6.23+ and some small changes to remove compile warnings (see ChangeLog below).

Downloads:
Please consider donating if you use this driver

ChangeLog:

1.4.5.2:
  * Added compatibility support for kernel versions >= 2.6.23
  * mtxversion.h:
    - Increased unofficial version number
  * mtx_agp.c:
    - Removed a warning of an unused variable on recent kernel versions
  * mtx_drv.c:
    - Replaced pci_find_slot() with pci_get_bus_and_slot() for recent
      kernel versions
    - The return type of unregister_chrdev() has changed in 2.6.23
    - Removed another warning of an unused variable

Links:

10.10.2007 09:17

HOWTO extract FON firmware archives (.fon)


Since yesterday I'm trying to extract FON firmware files (ending with .fon) to have a look at the internals of these routers.
Doing this isn't that easy, because it isn't documented anywhere (at least I haven't found useful information about this), so I started at Stefan's Fonera Hacking website and found a script called defon.sh which does basically extract the embedded tar.gz archive out of the fon image file:
tuxx@vi-edv003:~/fonfw$ ./defon.sh fonera_0.7.1.5.fon >fonera.tar.gz
Upgrade contains a new firmware
tuxx@vi-edv003:~/fonfw$
After "defoning" the .fon file, you'll get a file called "fonera.tar.gz" which can now easily be extracted:
tuxx@vi-edv003:~/fonfw$ tar xzf fonera.tar.gz
tuxx@vi-edv003:~/fonfw$ ls
defon.sh  fonera.tar.gz  fonera_0.7.1.5.fon  hotfix  rootfs.squashfs  upgrade
tuxx@vi-edv003:~/fonfw$
As you can see, a file called "rootfs.squashfs" got extracted. All my attempts to either `mount` it or `unsquashfs` it failed, but after a lot of googling, I found this site which talks about different ways of extracting specific squashfs files and the last mentioned method with the help of the Firmware Modification Kit finally worked!
At first, you'll have to download the firmware modkit archive and extract it:
tuxx@vi-edv003:~/fonfw$ wget -q http://download.berlios.de/firmwaremodkit/firmware_mod_tools_prebuilt.tar.gz
tuxx@vi-edv003:~/fonfw$ mkdir firmware_mod_tools
tuxx@vi-edv003:~/fonfw$ tar -x -C firmware_mod_tools -f firmware_mod_tools_prebuilt.tar.gz
tuxx@vi-edv003:~/fonfw$
Now you can use the script "unsquashfs-lzma" for SquashFS v3.0 filesystems to finally extract the archive:
tuxx@vi-edv003:~/fonfw$ firmware_mod_tools/src/squashfs-3.0/unsquashfs-lzma rootfs.squashfs
Reading a different endian SQUASHFS filesystem on rootfs.squashfs

created 330 files
created 53 directories
created 145 symlinks
created 0 devices
created 0 fifos
tuxx@vi-edv003:~/fonfw$
The generated directory "squashfs-root" now contains the contents of the FON firmware:
tuxx@vi-edv003:~/fonfw$ ls squashfs-root/
bin  dev  etc  jffs  lib  mnt  proc  rom  sbin  sys  tmp  usr  var  www
tuxx@vi-edv003:~/fonfw$

Happy hacking ;)

02.10.2007 13:47

Once upon a time...


... a friend of mine (no no, it's not me, how could you think that??) decided to clean up his harddisks a bit to free some space for important things (like Battlefield installations, Movies, etc.). As I (ehm, my friend) had already setup a triple boot on his notebook (Windows XP, Windows Vista and Debian 4.0) and is currently into migrating all compatible stuff from XP to Vista, the XP installation contained several programs, files, etc. that were already on the Vista installation.
The current partition layout looked like this:
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        4741    35841928+   7  HPFS/NTFS
/dev/sda2            4742        8858    31122432    7  HPFS/NTFS
/dev/sda3            8858       12733    29295000   83  Linux
/dev/sda4           12733       12921     1423280   82  Linux swap / Solaris
Where sda1 contains Windows XP and sda2 hosts Windows Vista.

After going through all the files on the XP partition and freeing up about 6 GiBs of unnecessary data, he ended up in deleting a folder called "C:\Boot" he never created. Of course, my friend is an IT-Pro and therefore always deletes file with Shift-delete. The odd thing was, that the folder won't let delete some of its contents and that made him think about what he might have done now.
After rebooting into Vista for doing further cleanups, there was no more bootmanager active. Doh! "Ah, that's what this folder is used for!", he thought.
Don't worry, Vista is famous for its glorious repair options and thefore he inserted the Vista DVD and tried out the automatic repair options. After choosing the language, keyboard layout and mother's maiden name a dialog window popped up with the following content:
Hey, Looser!
After having a look at your hard disks I, the glorious Vista Repair program found
out that you dumbass killed your C:\boot folder.
I need to laugh at you, this make take several minutes...

Alright, I had my fun.
Shall I fix things up for you?

[ Yes ]    [ Yes, Please ]     [ I don't know... Can you repeat the question? ]
Things seemed to went fine from now on, because after a few seconds, the system rebooted and the Vista Bootmanager loaded again.

Alright, he thought, but where's the good-old grub?
Vista's Bootmanager has never been installed to the MBR, but now, after "fixing things up", it is. That of course killed grub and therefore he had to reinstall it somehow.
Rebooting with grml and entering the following commands should work:
# grub
grub> root (hd0,2)
grub> setup (hd0)
[...]
grub>quit
# reboot

Well, no joy, afterwards the MBR seemd to be completely fucked up, because neither Vista's BCD nor Grub was installed into the MBR, or even worse, both seemed to be installed.
He didn't know wheter the glorious Vista repair program or the reinstallation of grub was the cause for what he discovered now, but someone of these two programs has to be the one to blame because after another reboot with grml, the Windows XP partition wasn't there anymore, at least the filesystem seemed to be correupted. ntfs-3g wasn't able to mount it anymore and the partition table looked quite weird.
Praying to the flying spaghetti monster reveiled a tool called testdisk that should be able to help him out and it did. testdisk was able to rebuild the bootsector of the Windows XP partition and from now on it was accessible again. Phew.
"Alright, maybe grml's grub is not really compatible with the installed one" he tried to convince him self and started to install grub on a memory stick. That of course isn't that easy if you've never done so, follow some simple rules and it'll work:
1. Backup all the data on your USB stick

2. Create a new partition table (optional) using `fdisk`, `cfdisk` or the like

3. Format one partition with enough space (some megabytes) with ext2
   mkfs.ext2 /dev/sdb1

4. Mount this partition
   mount /dev/sdb1 /mnt

5. Create the necessary directory structure
   mkdir -p /mnt/boot/grub

6. Copy over grub related files from an existing installation
   cp -a /boot/grub/*stage* /mnt/boot/grub

7. Install grub into the bootrecord of this partition or in the MBR of the stick
   grub-install --root-directory=/mnt /dev/sdb  # or /dev/sdb1

8. Wonder about why grub refuses to install because /dev/sdb has no corresponding 
   BIOS device configured. Unfortunately, I don't remember the original error
   message he told me, but it sounded like this.

   If this happens to you, add the "--recheck" parameter to the `grub-install`
   command and you should be fine.

9. Unmount the partition and reboot with the USB stick in place
   umount /mnt && reboot -f 

If everything worked, you should get a fancy grub boot prompt which lets you do really cool stuff like booting your installed operating systems!!1

Alright, now he booted his installed Linux operating system and tried to reinstall grub from there into the MBR => didn't help either. The next approach was to install grub into the boot record of sda3 ((hd0,2) in grub's terms) and make this partition bootable with `cfdisk`.
Still no joy, but using the previously created "mobile grub" (may come in handy in the future) showed that something must have been successfull in installing grub to sda3, because the following commands to his "mobile grub" prompt successfully loaded the installed bootmanager on sda3:
grub>rootnoverify (hd1,2)             # has to be hd1 here, because the USB stick is hd0 when booting off of it
grub>chainloader +1
grub>boot

Now he was able to see his well known grub bootloader with all the boot items for Windows, Linux, etc (BTW: directly booting from this entries isn't possible because of the above mentioned device map that changed due to the fact that you're booting off of the USB medium, e.g. menu.lst entries pointing to (hd0,2) have to be rewritten to (hd1,2) in this situation).

"Alright", he gasped, let's start over and let's insert the Vista DVD again and ask the Vista repair oracle for help. After booting into the Vista setup, the automatic repair option was unable to find any installed Windows installations. WTF?? He opened up a command line window and tried some CLI foo, e.g.:
bootrec.exe /ScanOS
which was able to find the installed Vista but why is the godfather of all repair programs unable to find it? Maybe it is still laughing at my friend and therefore refuses to do its work... Alright, some more CLI foo might help if the GUI is unwilling to:
<CD-Drive-Letter>:\boot\bootsect.exe -NT60 /All
should be the right command to reinstall the BCD bootloader's magic into the MBR => Reboot => Still no joy.
Again, booting the Vista DVD, trying some other things:
bootrec.exe /fixmbr      # completes successfully, but doesn't change a thing

bootrec.exe /fixboot     # refuses to work, because the bootdrive can't be written
                         # to. Thank you, Microsoft. Do you know that when you're 
                         # booting off the CD, the bootdrive is set to the CD and
                         # that piece of plastic isn't writable??
                         # BTW: He found no way to change the bootdrive setting
                         # whatever setting bootrec.exe is looking for...

bootrec.exe /rebuildbcd  # The same as with /fixboot

After some further googling, he tried the Microsoft Knowledgebase Entry 928570 (Pssst, if you really want to have a good laugh, read this article in german):
Bcdedit -createstore C:\boot\BCD
Bcdedit -store C:\boot\BCD -create {bootmgr} /d "Boot Manager"
Bcdedit -store C:\boot\BCD -set {bootmgr} device boot
Bcdedit -store C:\boot\BCD -create /d "Windows Vista" -application osloader

Remember the GUID you have received after entering this command (ID 1 for the
first entry probably isn't secure enough, so a 32 Bytes GUID should be good to 
remember).

Bcdedit -store C:\boot\BCD -set GUID osdevice partition=D:
Bcdedit -store C:\boot\BCD -set {bootmgr} default GUID
Bcdedit -store C:\boot\BCD -set GUID device partition=D:
Bcdedit -store C:\boot\BCD -set GUID path \windows\system32\boot\winload.exe
Bcdedit -store C:\boot\BCD -set GUID systemroot \windows
_THAT_ worked and after rebooting he was greeted by the Vista boot process.
Alright, now he was back at the point where everything started. Now let's do some things different so that we don't fuck up our filesystems again.
Back in Vista, he downloaded EasyBCD and tried to add Windows XP back to the bootmanager, but EasyBCD told him that the BCD store wasn't available and that the BCD registry information is corrupt.
Attempts to fix that with the help of EasyBCD didn't work so he installed VistaBootPro (a Microsoft tool) that was even more helpful than EasyBCD. VistaBootPro detected the corrupt BCD registry too but doesn't offer an option to fix this, but he was remembered that he doesn't have a backup of his current BCD. You know, usually I don't backup stuff that is corrupted, but thanks for asking me.

Then he recalled the words of the Vista repair oracle and prepared another sacrificial lamb before asking for assistance again.

Contrary to all expectations, the automatic repair option was now again able to find the Windows Vista installation (Woohoo, maybe it has stopped laughing at my friend and was now open for some new tasks). Same message, same story, it repaired all necessary startup files and back in Vista, all EasyBCD and VistaBootPro error messages where gone. Great.

He then focused in getting Windows XP back into the BCD list and succeeded without any further hickups.

You know, my friend is a so called "prefectionist", and therefore booting the installed Linux off the USB stick isn't "prefect" and has to be changed.
Despite the possibility that everything might now start again and more hours of precious time might be sacrified to fix this problem, he booted back into his installed Debian and tried to reinstall grub into the MBR again.
# dd if=/dev/sda of=/tmp/sda.bin bs=1 count=512     # make a copy of the MBR
# grub
grub> root (hd0,2)
grub> setup (hd0)                                   # install grub again
[...]
grub>quit
# dd if=/dev/sda of=/tmp/sda-new.bin bs=1 count=512 # make another copy of the MBR
# diff /tmp/sda.bin /tmp/sda-new.bin                # compare these two copies to see what has changed
# 
Nothing has changed? Why not?

Hasn't grub been installed into the MBR previously?
Hmm... maybe the shell script `grub-install` does the trick:
# grub-install --recheck /dev/sda
[...]
# dd if=/dev/sda of=/tmp/sda-new.bin bs=1 count=512
# diff /tmp/sda.bin /tmp/sda-new.bin
Binary files /tmp/sda.bin and /tmp/sda-new.bin differ
# 
Ah, great. It at least has changed something. Now let's try another thing and remove all boot flags from our partitions:
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        4741    35841928+   7  HPFS/NTFS
/dev/sda2            4742        8858    31122432    7  HPFS/NTFS
/dev/sda3            8858       12733    29295000   83  Linux
/dev/sda4           12733       12921     1423280   82  Linux swap / Solaris
We don't need it anyway, because grub now should be installed into the MBR and grub then chainloads the bootloader in the first partition.

Keeping the fingers crossed, he rebooted and.... it simply worked.

Probably, if he would have used `grub-install` from the beginning on instead of grub's `setup ()` feature, it wouldn't have come that far but it was funny to watch him bang his head against the desk ;)

Still, some questions remain and I'd appreciate any feedback on this:
  1. Why is grub's `setup()` different from `grub-install`? `grub-install` also uses the `setup()` builtin...
  2. Why is the Vista repair option unable to find an installed Windows installation if bootrec is able to? What files is it looking for?
  3. How to convince `bootrec.exe` to write to the harddisk instead of the DVD medium?
  4. Why does hibernation in Vista don't work anymore after this whole story?
  5. Why are `bcdedit` and its evil friends still unable to find the default BCD storage?
  6. What is the default BCD storage and how to tell Vista?
  7. Why does nearly all software suck that much?
  8. Why is it always me^H^H my friend?