Wake on lan remote control

I’ve written a small script to remote control a computer via wake on lan (WOL) packages. This could come in quite handy if my raspberry pi finally arrives but any HTPC owner could make use of this too. (You don’t want to run xbmc along with your torrent client (and vice versa) all day long, do you?)

It’s available here: https://sourceforge.net/projects/wolrc/

How it works:

It basically executes predefined commands on the amount of WOL packages received without a timeout. Just arm your android smartphone with a WOL app, send e.g. two WOL pkgs and your box will execute whatever you told it to do. It needs root (because it depends on pcapy ) so you’re strongly advised to use sudo wherever you can.

Note (Update):

AFAIK the raspberry pi is not capable of booting up due to a WOL package. Of course it can receive and handle them nonetheless.


Automated shutdown paranoid edition

One time I relied heavily on the ntfs-3g driver and it killed my ntfs-partition. Since then I always check if any mounted ntfs partition is umounted properly. For automation here is a code snippet for debian (ubuntu?). If a mount point in /media cannot be unmounted there will be no shutdown.

for f in `mount | grep /media/ | awk '{ print $1; }'`;

! umount $f && exit


shutdown -h 1

HOWTO: Tell Grub to load windows 7 as default (debian)

… is quite easy if you know what to do (and it’s update safe!):

Will be / Is DEPRECATED. Please refer to: http://www.triggers-world.de/?p=249

Only precondition: win7 or any other OS you want to boot as default is the next OS after the standard debian entries in the grub list / win7 is the only other OS installed

1. Edit /etc/default/grub

#find&edit or add if it doesn't exist
GRUB_DEFAULT=`/bin/bash "/somedir/getlastboot.sh"`

2. in /somedir/ create a getlastboot.sh with the following content


VAR1=`ls -l /boot | grep -v .bak | grep -c initrd.img`
VAR2=`ls -l /boot | grep -v .bak | grep -c vmlinuz`


3. make it executable

chmod 777 getlastboot.sh

4. update-grub

sudo update-grub

(I have not tested it on ubuntu, but it should work there too)

S-ATA cables – more guilty than you might think

If you get sth. like this (and best case your raid 1 goes crazy)

daywalker kernel: [  498.324514] ata5.00: status: { DRDY }
[  498.324516] ata5.00: failed command: WRITE FPDMA QUEUED
[  498.324520] ata5.00: cmd 61/60:e8:e2:7d:0e/01:00:9c:00:00/40 tag 29 ncq 180224 out
[  498.324520]          res 50/00:d8:7a:87:0f/00:00:9c:00:00/40 Emask 0x10 (ATA bus error)
[  498.324522] ata5.00: status: { DRDY }
[  498.324524] ata5.00: failed command: WRITE FPDMA QUEUED
[  498.324527] ata5.00: cmd 61/88:f0:4a:7f:0e/01:00:9c:00:00/40 tag 30 ncq 200704 out
[  498.324528]          res 50/00:d8:7a:87:0f/00:00:9c:00:00/40 Emask 0x10 (ATA bus error)
[  498.324530] ata5.00: status: { DRDY }
[  498.324533] ata5: hard resetting link
[  498.644016] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  498.646630] ata5.00: configured for UDMA/133
[  498.660052] ata5: EH complete
[  499.755828] ata5.00: exception Emask 0x10 SAct 0x7ffff9ff SErr 0x400100 action 0x6 frozen
[  499.755831] ata5.00: irq_stat 0x08000000, interface fatal error
[  499.755834] ata5: SError: { UnrecovData Handshk }
[  499.755836] ata5.00: failed command: WRITE FPDMA QUEUED
[  499.755840] ata5.00: cmd 61/00:00:b2:51:ed/04:00:4d:00:00/40 tag 0 ncq 524288 out
[  499.755840]          res 50/00:98:ba:6a:ed/00:01:4d:00:00/40 Emask 0x10 (ATA bus error)
[  499.755842] ata5.00: status: { DRDY }
[  499.755844] ata5.00: failed command: WRITE FPDMA QUEUED
[  499.755848] ata5.00: cmd 61/08:08:b2:55:ed/02:00:4d:00:00/40 tag 1 ncq 266240 out
[  499.755848]          res 50/00:98:ba:6a:ed/00:01:4d:00:00/40 Emask 0x10 (ATA bus error)
[  499.755850] ata5.00: status: { DRDY }

you might want to check a different S-ATA cable first. (Chances for a kernel bug are very bad too…) Would have spared me a lot of time… If you have got the opinion that the cable is innocent because windows is working properly on the same hdd well guess again because windows easily ships around this mess by falling back into not using dma 🙂

(If another cable on another SATA connector does not change anything the hdd is probably broken)

is pretty informative though!

Had a short conversation with a computer shop owner the other day. He told me that the SATA cables provided (for free) with the mainboard are much more likely to fail than others. Don’t know if he just wanted me to buy more cables (i did not) but my faulty one was indeed provided with the mainboard and he didn’t knew that in advance.

Unzip broken archive (partially)

Many solutions I found included wine and winrar (and this does not worked for me in any case btw). But I found sth different. (apt-)get (install) bsdtar!

bsdtar xf yourbrokenzip.zip

Besides for rar files the non free version does this like a charm

unrar -kb x yourrar.rar

Remember: These cmds do not repair anything. They just extract what they can!

Howto Flash your BIOS the quick and dirty way

I never really understood why you should always get a bootdisc environment for flashing your motherboard bios. Flashing a bios takes few seconds including the verification of the written data. Why should a stable system fail right in this moment? Yeah this could fuck the whole system up but who tells you you got a secure power supply in case you use a bootable environment from a CDROM? So I went another way. Without creating a bootable cd. So…

What to do

  1. Flashing your BIOS is dangerous. You do anything at your own risk. Don’t flash your bios if everything works or you don’t know what you’re actually doing.
  2. Obtain flashrom (apt-get install flashrom)
  3. Check if your motherboard is supported. (chances are good)
    sudo -s
    flashrom -L
  4. Obtain the right (the one for your motherboard) bios image from your vendor
  5. If you made important modifications in your bios settings (overclock?) write them down. All your settings (including saved ones) will probably disappear with the update)
  6. IF you’re completely sure you got the right bios image for updating AND you made sure flashrom is about to update your motherboard bios and not sth else OTHERWISE check below
    sudo -s
    flashrom -w yourimage

    Check the programs output. Don’t reboot if it tells you sth went wrong badly!

  7. If everything worked. Reboot and reconfigure your bios settings.

How do I know I got the right image and flashrom will flash the motherboard bios?

  1. Obtain the current bios of your motherboard.
    sudo -s
    flashrom -r readbios
  2. If you know or you are able to guess your bios version obtain the outdated version you currently use from your vendor too.
  3. Check wether all images have the same size.
  4. Obtain vbindiff (apt-get install vbindiff) and check the hexdata DON’T EDIT ANYTHING
    vbindiff readbios unmodified_outdated_same_v_from_vendor

    If there’s a lot (!) different this is not your bios. (Some differences occour because all your settings probably are saved there too.) To see “a lot” compare your bios with the one you want to replace it with (the new). There should be much more difference.

    vbindiff readbios newbios

    My biosimages all have a date at the end which I could see in the hexeditor. If you have that too, check it! The bios you read from your motherboard and the outdated from your vendor should have the same date. The new image should have a newer date at exactly the same place.

  5. So if the filesize does not differ, you got a date in your hexfile and you’ve read Nr. 4 carefully you should have the right bios and flashrom should write it to the right flashmemory (the one of your motherboard).