LaCie LaPlug

Mijzelf
Posts: 6226
Joined: Mon Jun 16, 2008 10:45 am

Re: LaCie LaPlug

Post by Mijzelf » Tue Dec 13, 2011 7:15 pm

mushupork wrote:I FTP'd the file to you.
The partition indeed contains a kernel, with a build-in initramfs, which contains commands like 'flash_eraseall' and 'nandwrite'. So I suppose it's a dedicated Linux system, used for updating, and maybe recovery.
However, the file is damaged. gunzip fails halfway. The md5sum of the file is c512ec3dbfb5cc21e5a331327668f9d9. If yours is different, can you reupload it? If it isn't different, try to extract it again. When it's still the same, it's possible that your box is faulty, and you can't recover and/or update.
I used the modified mount string and the single message written to mount.log is
"mount: mounting /dev/mtdblock3 on /tmp/mountpoint failed: Device or resource busy"

The weird part if it does succeed in mounting because I can browse to /tmp/mountpoint and see the jffs file system but I cannot create/modify anything there. I am guessing it is showing the "failure" to mount it as writable.
I think so. Maybe you can remount the rootfs writable?

Code: Select all

mount -o remount,rw /dev/mtdblock3 /
If that works, you still cannot change /etc and up, due to the tmpfs mounted on it, but maybe then you can doublemount it rw?

mushupork
Posts: 20
Joined: Fri Nov 18, 2011 10:04 pm

Re: LaCie LaPlug

Post by mushupork » Wed Dec 14, 2011 5:07 pm

My md5 was different than yours so I re-uploaded the file (updater).

When I try "mount -o remount,rw /dev/mtdblock3 /" to remount I get the permission denied - are you root message again.

Mijzelf
Posts: 6226
Joined: Mon Jun 16, 2008 10:45 am

Re: LaCie LaPlug

Post by Mijzelf » Wed Dec 14, 2011 8:28 pm

mushupork wrote:When I try "mount -o remount,rw /dev/mtdblock3 /" to remount I get the permission denied - are you root message again.
Did you try this with the usb-plug trick?
mushupork wrote:My md5 was different than yours so I re-uploaded the file (updater).
Strange. Your 2nd file is identical to the first one. So either your md5sum is wrong, or somehow the image is reproducable destroyed by FTP.
This is what I get:

Code: Select all

~/Lacie/LaPlug/mushupork$ binwalk updater

DECIMAL         HEX             DESCRIPTION
-------------------------------------------------------------------------------------------------------
0               0x0             uImage header, header size: 64 bytes, header CRC: 0x7E243A43, created: Fri May 20 15:04:10 2011, image size: 4512588 bytes, Data Address: 0x8000, Entry Point: 0x8000, data CRC: 0x892F09FB, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: Linux-2.6.31.8
13252           0x33C4          gzip compressed data, from Unix, last modified: Fri May 20 15:04:07 2011, max compression
So the image is actually a uImage, containing a binary (kernel+decompressor) of 4512588 bytes. At byte 13252 starts a gzipped *something*, so the first 13252 - 64(header) bytes is decompressor.
When I decompress and recompress it, I get this:

Code: Select all

~/Lacie/LaPlug/mushupork$ tail -c +13253 updater | gunzip -d | gzip -9 >sizetester

gzip: stdin: invalid compressed data--format violated

~/Lacie/LaPlug/mushupork$ ls -l
total 17700
-rw-r--r-- 1 Mijzelf Mijzelf 2873622 Dec 14 21:03 sizetester
-rw-r--r-- 1 Mijzelf Mijzelf 8388558 Dec 13 01:34 updater
The decompression fails due a format violation. The recompressed file is 2873622 bytes. So I suppose the file is damaged at about 2886874.
I see nothing special around that address.

Can you run

Code: Select all

tail -c +13253 updater | gunzip -d >kernel
on a Linux box? (Your LaPlug is fine) If it runs without 'gzip: stdin: invalid compressed data--format violated', somehow the partition got damaged by FTP.

mushupork
Posts: 20
Joined: Fri Nov 18, 2011 10:04 pm

Re: LaCie LaPlug

Post by mushupork » Wed Dec 14, 2011 9:08 pm

This is the error message I get ...

Code: Select all

tail: can't open 'updater': No such file or directory
tail: no files
-sh: can't create kernel: Read-only file system

mushupork
Posts: 20
Joined: Fri Nov 18, 2011 10:04 pm

Re: LaCie LaPlug

Post by mushupork » Wed Dec 14, 2011 9:29 pm

I forgot to add, I used md5 GUI to generate the md5. I just used a second tool, winMd5Sum, and got the same md5 ... de83e5160a6865ee14bcd10eb665a0b3.

I posted the file on my FTP server for you to grab. I will PM you details.

Mijzelf
Posts: 6226
Joined: Mon Jun 16, 2008 10:45 am

Re: LaCie LaPlug

Post by Mijzelf » Thu Dec 15, 2011 9:25 pm

The file on your server is correct. MD5 de83e5160a6865ee14bcd10eb665a0b3, and I could extract the kernel without problems. Will analize the initramfs later.

Mijzelf
Posts: 6226
Joined: Mon Jun 16, 2008 10:45 am

Re: LaCie LaPlug

Post by Mijzelf » Sun Jan 01, 2012 5:00 pm

This initramfs seems complete. The script /init can download 3 different files via tftp, plug/rootfs.jffs2, plug/kernel.uboot and/or plug/kernel-ramdisk.uboot, and flash it to mtdblock1, 2 and/or 3. So this emergency kernel can also update itself.
It can also load and flash a .cluff file from a usb disk/stick.

What it is going to do is decided by the command line (which is provided by the bootloader u-boot):

Code: Select all

CMDLINE=$(cat /proc/cmdline)
BOOT_MODE=$(echo $CMDLINE | tr ' ' '\n' | grep bootmode | cut -d '=' -f 2 | awk '{print $1}')

case "$BOOT_MODE" in
        upgrade_tftp|upgrade_tftp_clean)
                /etc/leds loop $UPDATE_LOOP_PERIOD
                if [ "$BOOT_MODE" == "upgrade_tftp_clean" ]; then
                        upgrade_tftp 1
                else
                        upgrade_tftp 0
                fi
                ;;
        
        upgrade_usb)
                /etc/leds loop $UPDATE_LOOP_PERIOD
                upgrade_usb
                ;;
esac
Further the ip address of the tftp server is provided in the commandline:

Code: Select all

        TFTPINFO=$(echo $CMDLINE | tr ' ' '\n' | grep tftpinfo | cut -d '=' -f 2 | awk '{print $1}')
        LOCAL_IP=$(echo $TFTPINFO | cut -d ':' -f 1)
        SERVER_IP=$(echo $TFTPINFO | cut -d ':' -f 2)
So I *think* 'bootmode=upgrade_tftp tftpinfo=192.168.1.2:192.168.1.1' will give the box IP address 192.168.1.2, and it will try to download the files from tftp server 192.168.1.1. (Wired. The wireless is not started).
BTW, the difference between upgrade_tftp and upgrade_tftp_clean is that the *_clean will also erase the 'config and data partitions':

Code: Select all

        if [ "$DOCLEAN" == "1" ]; then
                echo "- cleaning config and data partitions"
                flash_eraseall -q /dev/mtd4
                flash_eraseall -q /dev/mtd5
        fi
Unfortunately I can't see how the emergency kernel could be started, but seeing the complexity of the tftp possibilities, I wouldn't be surprised if it can only be done using the u-boot commandline on the serial port.

So it seems safe to play with the rootfs. There is an escape when things get screwed up.

Post Reply