Upgrade to Alt-F-0.1RC4.1 stuck on DNS-325

[Chris Archer]

I followed the instructions for upgrade, i.e.
- rebooted
- saved settings
- used Flash It to apply upgrade

The warning

Don't poweroff or reboot the box until instructed to do it!
If you suspect that something went wrong,
you can try to upgrade again after stopping all running processes.

is now displayed and is not going away even after an hour.

Output of ps is

PID   USER     COMMAND
    1 root     init
    2 root     [kthreadd]
    3 root     [ksoftirqd/0]
    5 root     [kworker/0:0H]
    7 root     [khelper]
    8 root     [writeback]
    9 root     [bioset]
   10 root     [kblockd]
   11 root     [ata_sff]
   12 root     [khubd]
   13 root     [md]
   14 root     [rpciod]
   16 root     [kswapd0]
   17 root     [fsnotify_mark]
   18 root     [nfsiod]
   19 root     [crypto]
   32 root     [scsi_eh_0]
   33 root     [scsi_eh_1]
   34 root     [kworker/u2:1]
   36 root     [kworker/u2:3]
   43 root     [deferwq]
  103 root     [loop0]
  262 root     [kworker/0:1H]
  352 root     [kworker/0:2]
  401 root     [jbd2/sda3-8]
  403 root     [ext4-dio-unwrit]
  409 root     [bioset]
  410 root     [md0_raid1]
  493 root     [jbd2/md0-8]
  498 root     [ext4-dio-unwrit]
  579 root     udhcpc -R -b -p /var/run/udhcpc.eth0.pid -i eth0 -r 192.168.1.92
  750 root     inetd
  809 root     [jbd2/sda4-8]
  810 root     [ext4-dio-unwrit]
  848 root     [jbd2/sdb3-8]
  849 root     [ext4-dio-unwrit]
 1471 root     [jbd2/sdb4-8]
 1472 root     [ext4-dio-unwrit]
 2356 root     /bin/sh --
 3304 root     [kworker/0:1]
 3969 root     dropbear -i
 3970 root     -sh
 3982 root     ps

I had a similar problem on my DNS-323 but followed the instructions in the post "Upgrading RC3 to RC4 is stuck, not sure how to safely kill the operation"

and that worked perfectly. However, in that post Joao specifically has this warning about that method (using dns323-fw and dd):

"This procedure applies to the DNS-321/323 ONLY and IS NOT suitable for the DNS-320/320L/325"

Any suggestions on what I should do?

[João Cardoso]

On Sunday, February 15, 2015 at 9:07:36 AM UTC, Chris Archer wrote:

I followed the instructions for upgrade, i.e.
- rebooted
- saved settings
- used Flash It to apply upgrade

The warning

Don't poweroff or reboot the box until instructed to do it!
If you suspect that something went wrong,
you can try to upgrade again after stopping all running processes.

is now displayed and is not going away even after an hour.

Did the "kernel/rootfs/sqimage: erasing... flashing... verifiyng.. messages ever appeared?

There are no user running processes, so that step was completed. There is also no sign of processes related with the flashing or webUI, so either they have been completed or never initiated.

What browser was you using at the time?

What does the commands

dd if=/dev/mtd1 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*

dd if=/dev/mtd2 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'

outputs? On my DNS-325 with RC4.1 flashed they display

Alt-F-0.1RC4.1, kernel 3.10.32

Alt-F-0.1RC4.1, initrd

In any case, it's better to repeat the flash procedure without rebooting. Try using Chrome or Firefox, not IE.

I had a similar problem on my DNS-323 but followed the instructions in the post "Upgrading RC3 to RC4 is stuck, not sure how to safely kill the operation"

and that worked perfectly. However, in that post Joao specifically has this warning about that method (using dns323-fw and dd):

"This procedure applies to the DNS-321/323 ONLY and IS NOT suitable for the DNS-320/320L/325"

DON'T DO THAT!!! The flash procedure is completely different on the 321/323 and on the the 320/320L/325

If the second attempt of reflashing fails I will post the command line sequence to flash the 320/320L/325.

[Chris Archer]

Thanks for the quick response.

"Did the "kernel/rootfs/sqimage: erasing... flashing... verifiyng.. messages ever appeared?"

No, just the Firmware Updater page with the red text "Don't poweroff or reboot..."

What browser was you using at the time?

Latest Firefox on Fedora 21

What does the commands

dd if=/dev/mtd1 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'
Alt-F-0.1RC4.1, kernel 3.10.32

dd if=/dev/mtd2 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'

Alt-F-0.1RC4, initrd

I'm DEFINITELY not going to either reboot or use the instructions for the DNS-323. I've already "bricked" one of my DNS-323's with this exact problem and rebooted (did not find your excellent instructions at the time.

I will try flashing again from the same browser session.

Thanks,
Chris.

[João Cardoso]

On Sunday, February 15, 2015 at 5:02:15 PM UTC, Chris Archer wrote:

Thanks for the quick response.

"Did the "kernel/rootfs/sqimage: erasing... flashing... verifiyng.. messages ever appeared?"
No, just the Firmware Updater page with the red text "Don't poweroff or reboot..."

What browser was you using at the time?
Latest Firefox on Fedora 21

What does the commands

dd if=/dev/mtd1 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'
Alt-F-0.1RC4.1, kernel 3.10.32

So the flash started...

 

dd if=/dev/mtd2 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'

Alt-F-0.1RC4, initrd

but didn't finish.

You might also use the following command

dd if=/dev/mtd3 ibs=32 skip=0 count=1 2> /dev/null 

which shows for RC4.1

sqimage_size=14860288;

Those signatures occur at the flash partition start.

You might want to watch the System Log and Kernel Log (errors will most likely appear in the kernel log)  to watch for NAND/mtd/mtdblock errors.

[Added:]

There are also other symptoms that you might be aware.

-When the flash starts the power led should start blinking and stop at the flash end or if an error is detected.

-when the flash starts all running process are stopped, except inetd; when the flashing terminates the sysctrl (fan/temp/button) process is restarted.

From your ps command sysctrl is not running (is better to start it), so the flash didn't succeed and no  webUI error was detected/generated (that would also restart sysctrl)

[/Added]

 

I'm DEFINITELY not going to either reboot or use the instructions for the DNS-323. I've already "bricked" one of my DNS-323's with this exact problem and rebooted (did not find your excellent instructions at the time.

I will try flashing again from the same browser session.

Better use another browser; at least clear its cache first. The flashing does not change the current running system, you can continue using it.

As the kernel flash at least started (the dd command shows RC4.1 in the kernel) the "Kernel Erasing... Flashing... Verifying" message should have appeared in the browser. Or it might be a buffering/flushing script issue if the message stopped in its middle.

[Chris Archer]

Still no luck.

dd if=/dev/mtd3 ibs=32 skip=0 count=1 2> /dev/null

sqimage_size=15110144;

Tried using Google Chrome (after clearing cache) with same end result. No other messages/output other than Firmware Updater page with "Don't poweroff or reboot..."

Sorry for the stupid question, but how do I

watch the System Log and Kernel Log (errors will most likely appear in the kernel log)  to watch for NAND/mtd/mtdblock errors

BTW, running the update punts my ssh login, and although I can currently view the web interface the shares on the DNS-325 are unavailable.

Thanks,
Chris.

On Sunday, February 15, 2015 at 12:57:22 PM UTC-5, João Cardoso wrote:

On Sunday, February 15, 2015 at 5:02:15 PM UTC, Chris Archer wrote:

Thanks for the quick response.

"Did the "kernel/rootfs/sqimage: erasing... flashing... verifiyng.. messages ever appeared?"
No, just the Firmware Updater page with the red text "Don't poweroff or reboot..."

What browser was you using at the time?
Latest Firefox on Fedora 21

What does the commands

dd if=/dev/mtd1 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'
Alt-F-0.1RC4.1, kernel 3.10.32

So the flash started...

 

dd if=/dev/mtd2 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'

Alt-F-0.1RC4, initrd

but didn't finish.

You might also use the following command

dd if=/dev/mtd3 ibs=32 skip=0 count=1 2> /dev/null 

which shows for RC4.1

sqimage_size=14860288;

Those signatures occur at the flash partition start.

You might want to watch the System Log and Kernel Log (errors will most likely appear in the kernel log)  to watch for NAND/mtd/mtdblock errors.

 

I'm DEFINITELY not going to either reboot or use the instructions for the DNS-323. I've already "bricked" one of my DNS-323's with this exact problem and rebooted (did not find your excellent instructions at the time.

I will try flashing again from the same browser session.

Better use another browser; at least clear its cache first. The flashing does not change the current running system, you can continue using it.

As the kernel flash at least started (the dd command shows RC4.1 in the kernel) the "Kernel Erasing... Flashing... Verifying" message should have appeared in the browser. Or it might be a buffering/flushing script issue if the message stopped in its middle.

[João Cardoso]

On Sunday, February 15, 2015 at 7:48:58 PM UTC, Chris Archer wrote:

Still no luck.

dd if=/dev/mtd3 ibs=32 skip=0 count=1 2> /dev/null
sqimage_size=15110144;

Tried using Google Chrome (after clearing cache) with same end result. No other messages/output other than Firmware Updater page with "Don't poweroff or reboot..."

Sorry for the stupid question, but how do I
watch the System Log and Kernel Log (errors will most likely appear in the kernel log)  to watch for NAND/mtd/mtdblock errors

System->Utilities->View Logs, Kernel Log.

 

BTW, running the update punts my ssh login, and although I can currently view the web interface the shares on the DNS-325 are unavailable.

I have edited my previous post, giving more details on the flashing procedure. It looks like we have to resort to the command line, but now I have to make my family dinner, hold-on :-) 

[Chris Archer]

Okay, found the System Log and Kernel Log.

In the Kernel Log, this repeats:

EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1

When I tried the Kernel Log, I got: 
Syslog is disabled, enable at 'System Services'

In System Services, all services are stopped.
news, cron, sysctrl, quota and syslog are enabled.

Chris.

[Chris Archer]

Found it, and as mentioned in an earlier reply this repeats in the Kernel Log:

EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1

and I can't view the System Log.

I've attached my system_configuration.log in case that would help.

The 0.1RC4 updates are the first that I've had any problems with. Not sure if it's something about my setup, though I don't have anything special.

Chris.

[João Cardoso]

On Sunday, February 15, 2015 at 10:17:01 PM UTC, Chris Archer wrote:

Found it, and as mentioned in an earlier reply this repeats in the Kernel Log:

EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1

Those are disk related errors (device sdb), not flash related.

The only reason I see for the Firmware Upgrade webUI to not complete and not display any error is that it must exists some hardware problem at the flash chip.

The Firmware Upgrade script tries to detect errors, but as I can't simulate errors at that level on my system I'm not certain that the error detection will work.

So we will first perform some flash memory tests, and at the then try to re-flash using the command line.

Start syslog:

[root@DNS-325]# rcsyslog start

Starting syslogd: OK.

Starting klogd: OK.

You can now watch the kernel log for errors (your output will be different):

[root@DNS-325]# dmesg |tail

 md1: unknown partition table

mv643xx_eth_port mv643xx_eth_port.0 eth0: link down

kjournald starting.  Commit interval 5 seconds

EXT3-fs (md1): using internal journal

EXT3-fs (md1): mounted filesystem with ordered data mode

mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled

usbcore: registered new interface driver usblp

EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null)

mv643xx_eth_port mv643xx_eth_port.0 eth0: link down

mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled

You should execute the dmesg command to see if any errors shows up.

The flash memory chip is "partitioned" with the following structure:

[root@DNS-325]# cat /proc/mtd

dev:    size   erasesize  name

mtd0: 00100000 00020000 "u-boot"

mtd1: 00500000 00020000 "uImage"

mtd2: 00500000 00020000 "ramdisk"

mtd3: 06600000 00020000 "image"

mtd4: 00a00000 00020000 "mini firmware"

mtd5: 00500000 00020000 "config"

we are interested in the 'uImage' (/dev/mtd1), 'ramdisk' (/dev/mtd2), 'image' (/dev/mtd3) and 'config' (dev/mtd5) partitions.

DON'T EVER touch /dev/mtd0 (u-boot), or your box will be bricked and not even a serial adapter will work.

Testing the kernel flash partition. Don't forget the '-k', so the flash contents will be rewritten back after the test finish.

[root@DNS-325]# nandtest /dev/mtd1 -k

ECC corrections: 0

ECC failures   : 0

Bad blocks     : 1

BBT blocks     : 0

Bad block at 0x000e0000

004e0000: checking...

Finished pass 1 successfully

the 'dmesg |tail' command shows the same output as before, so no errors occurred.

You might notice that in my system there is a bad block. That is normal, NAND flash memory develop errors, as disk drives do, and the software detects that and uses an alternative location. Errors are detected and corrected (up to a point) using ECC, and bad/uncorrectable blocks are marked as bad and not used anymore.

Repeat the above command for the /dev/mtd2, /dev/mtd3 and /dev/mtd5 devices, using the 'dmesg|tail' command to see if any kernel error occured.

The mtd3 device is rather large, if compared with the others (106 MB vs 5 MB), so the test will take some 20x more time to complete.

Please post the output of each nandtest command. Post also the 'dmesg|tail' output after each command if it shows errors.

I will wait for these tests results before trying to re-flash.

[Chris Archer]

Thanks for the update.

[root@DOT]# dmesg | tail

EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1

EXT4-fs (sda3): error count: 9311
EXT4-fs (sda3): initial error at 1423986727: __ext4_new_inode:741
EXT4-fs (sda3): last error at 1423986837: __ext4_new_inode:741
EXT4-fs (sdb3): error count: 9311
EXT4-fs (sdb3): initial error at 1423986837: __ext4_new_inode:741
EXT4-fs (sdb3): last error at 1423986942: __ext4_new_inode:741

Remained the same after each test. BTW, I ran 'badblocks /dev/sdb' and it came up empty. Running 'badblocks /dev/sda' but I suspect it won't show anything either.

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00500000 00020000 "uImage"
mtd2: 00500000 00020000 "ramdisk"
mtd3: 06600000 00020000 "image"
mtd4: 00a00000 00020000 "mini firmware"
mtd5: 00500000 00020000 "config"

(same as yours)

nandtest /dev/mtd1 -k
ECC corrections: 0
ECC failures   : 0

Bad blocks     : 0
BBT blocks     : 0

004e0000: checking...
Finished pass 1 successfully

(same for /dev/mtd2 and /dev/mtd5)

nandtest /dev/mtd3 -k

ECC corrections: 0
ECC failures   : 0
Bad blocks     : 1
BBT blocks     : 0

Bad block at 0x03c40000
065e0000: checking...
Finished pass 1 successfully

Thanks again,
Chris.

[João Cardoso]

On Monday, February 16, 2015 at 5:06:44 PM UTC, Chris Archer wrote:

Thanks for the update.

[root@DOT]# dmesg | tail
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs (sda3): error count: 9311
EXT4-fs (sda3): initial error at 1423986727: __ext4_new_inode:741
EXT4-fs (sda3): last error at 1423986837: __ext4_new_inode:741
EXT4-fs (sdb3): error count: 9311
EXT4-fs (sdb3): initial error at 1423986837: __ext4_new_inode:741
EXT4-fs (sdb3): last error at 1423986942: __ext4_new_inode:741

 

There are errors on the ext4 filesystem at sda3 and sdb3. That is a different issue that you have to correct latter by using fsck.

  

Remained the same after each test. BTW, I ran 'badblocks /dev/sdb' and it came up empty. Running 'badblocks /dev/sda' but I suspect it won't show anything either.

badblocks diagnose problems at the hardware level, the errors are at the filesystem level -- they can or not be related. But again, that is a separate issue. And... where did you get 'badblocks' from? ffp?

So it seems there are no problems at the flash chip level. Lets proceed with the flash.

Execute the following commands, one by one, and please post *all*  its output.

A-First lets be sure about the box board and that the next commands come from Alt-F and not ffp.

[root@DNS-325]# cat /tmp/board 

DNS-325-A1A2

[root@DNS-325]# echo $PATH
/bin:/sbin:/usr/bin:/usr/sbin:/ffp/bin:/ffp/sbin

[root@DNS-325]# which flash_erase nandwrite nandtest
/usr/sbin/flash_erase
/usr/sbin/nandwrite
/usr/sbin/nandtest

If the board is not a DNS-320-A1A2 nor DNS-320L-A1 nor DNS-325-A1A2  STOP.

If the commands path is /ffp/something, FIXIT.

You have to correct you PATH variable, putting /ffp at its end:

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/ffp/bin:/ffp/sbin

and that might be the reason why the Firmware Upgrade webUI fails?

B-download and split Alt-F fw into its components: 

# change dir to /tmp
[root@DNS-325]# cd /tmp

# get the fw file. This example and the next commands are for the DNS-325 and for RC4.1, adapt where necessary
[root@DNS-325]# wget http://downloads.sourceforge.net/project/alt-f/Releases/0.1RC4.1/Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin

# notice the fw size in the 5th column
[root@DNS-325]# ls -l Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin
-rwx------    1 root     root      19721700 Feb 16 18:15 Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin

# extract the fw components

[root@DNS-325]# dns323-fw -s Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin 

product_id=0;

custom_id=8;

model_id=5;

sub_id=2;

NewVersion=0;

signature="DNS-325";

sig_num=3 header=128 Next_offset=0

ko=128          kl=1803556      kr=0    kc=3429078352   next=1803684

io=1803684      il=3055680      ir=0    ic=3844963483   next=4859364

so=4859364      sl=14862336     sr=0    sc=1273201637   next=19721700

do=19721700     dl=0            dr=0    dc=0    next=19721700

filesz=19721700 compsz=19721700

signature is "DNS-325"

kernel saved, checksum is OK.

initramfs saved, checksum is OK.

sqimage saved, checksum is OK.

defaults saved, checksum is OK.

# notice the files size and names in the 5th and 9th column

[root@DNS-325]# ls -l kernel initramfs sqimage -rwx------ 1 root root 3055680 Feb 16 20:22 initramfs -rwx------ 1 root root 1803556 Feb 16 20:22 kernel -rwx------ 1 root root 14862336 Feb 16 20:22 sqimage
# free some space
[root@DNS-325]# rm Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin

C-flash the kernel

In the following sections the status=0 line shown that the command had success; any value other than 0 means that an error occurred and you should not reboot the box.

Any  messages other than the ones shown might also mean that an error has occurred.

You might also run the 'dmesg|tail' command to see if any kernel error occurred during the last executed command.

# kernel is mtd1, its filename is named kernel, its size is 1803556
fdev=mtd1
fname=kernel
fsz=1803556

# now lets erase, flash, read and verify the kernel
[root@DNS-325]# flash_erase /dev/$fdev 0 0; echo status1=$?

Erasing 128 Kibyte @ c0000 -- 15 % complete flash_erase: Skipping bad block at 000e0000

Erasing 128 Kibyte @ 4e0000 -- 100 % complete

status1=0

[root@DNS-325]# nandwrite -p /dev/$fdev $fname; echo status2=$?

Writing data to block 0 at offset 0x0

Writing data to block 1 at offset 0x20000

Writing data to block 2 at offset 0x40000

Writing data to block 3 at offset 0x60000

Writing data to block 4 at offset 0x80000

Writing data to block 5 at offset 0xa0000

Writing data to block 6 at offset 0xc0000

Writing data to block 7 at offset 0xe0000

Bad block at e0000, 1 block(s) from e0000 will be skipped

Writing data to block 8 at offset 0x100000

Writing data to block 9 at offset 0x120000

Writing data to block 10 at offset 0x140000

Writing data to block 11 at offset 0x160000

Writing data to block 12 at offset 0x180000

Writing data to block 13 at offset 0x1a0000

Writing data to block 14 at offset 0x1c0000

status2=0

[root@DNS-325]# nanddump -l $fsz -f flash-dump /dev/$fdev; echo status3=$?

ECC failed: 0

ECC corrected: 0

Number of bad blocks: 1

Number of bbt blocks: 0

Block size 131072, page size 2048, OOB size 64

Dumping data starting at 0x00000000 and ending at 0x001b8524...

status3=0

[root@DNS-325]# dd if=flash-dump bs=$fsz count=1 | cmp $fname; echo status4=$?

1+0 records in

1+0 records out

1803556 bytes (1.7MB) copied, 0.098394 seconds, 17.5MB/s

status4=0

[root@DNS-325]# rm flash-dump

D-flash the rootfs

# rootfs is mtd2, its filename is named initramfs, its size is 3055680

fdev=mtd2

fname=initramfs

fsz=3055680

flash_erase /dev/$fdev 0 0; echo status1=$?
nandwrite -p /dev/$fdev $fname; echo status2=$?
nanddump -l $fsz -f flash-dump /dev/$fdev; echo status3=$?
dd if=flash-dump bs=$fsz count=1 | cmp $fname; echo status4=$?
rm flash-dump

E-flash the remaining rootfs

# sqimage is mtd3, its filename is named sqimage, its size is 14862336

fdev=mtd3

fname=sqimage

fsz=14862336

flash_erase /dev/$fdev 0 0; echo status1=$?

nandwrite -p /dev/$fdev $fname; echo status2=$?

nanddump -l $fsz -f flash-dump /dev/$fdev; echo status3=$?

dd if=flash-dump bs=$fsz count=1 | cmp $fname; echo status4=$?

rm flash-dump

I have actually executed the above commands on my dns-325-rev-A1, and after executing the 'reboot' command the box rebooted OK afterwards.

But, as usual, NO WARRANTY.

Let the Force be with you :)

[Chris Archer]

I found badblocks while Googling the error in the Kernel Log. Figured it was worth trying to see if would shed some more light on what might be wrong.
I will run an fsck later (after trying the steps below for flashing).

Step A

cat /tmp/board
DNS-325-A1A2

echo $PATH
/bin:/sbin:/usr/bin:/usr/sbin:/ffp/bin:/ffp/sbin

which flash_erase nandwrite nandtest
/usr/sbin/flash_erase
/usr/sbin/nandwrite
/usr/sbin/nandtest

Step B

wget http://downloads.sourceforge.net/project/alt-f/Releases/0.1RC4.1/Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin
2015-02-16 19:54:31 (2.10 MB/s) - 'Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin' saved [19721700/19721700]

dns323-fw -s Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin
product_id=0;
custom_id=8;
model_id=5;
sub_id=2;
NewVersion=0;
signature="DNS-325";

sig_num=3 header=128 Next_offset=0
ko=128        kl=1803556    kr=0    kc=3429078352    next=1803684
io=1803684    il=3055680    ir=0    ic=3844963483    next=4859364
so=4859364    sl=14862336    sr=0    sc=1273201637    next=19721700
do=19721700    dl=0        dr=0    dc=0    next=19721700
filesz=19721700 compsz=19721700

signature is "DNS-325"
kernel saved, checksum is OK.
initramfs saved, checksum is OK.
sqimage saved, checksum is OK.
defaults saved, checksum is OK.

ls -l kernel initramfs sqimage

-rwx------    1 root     root       3055680 Feb 16 19:55 initramfs
-rwx------    1 root     root       1803556 Feb 16 19:55 kernel
-rwx------    1 root     root      14862336 Feb 16 19:55 sqimage

ran rm Alt-F-0.1RC4.1-DNS-325-rev-A1A2.bin to free up space

Step C

fdev=mtd1
fname=kernel
fsz=1803556


flash_erase /dev/$fdev 0 0; echo status1=$?


Erasing 128 Kibyte @ 4e0000 -- 100 % complete
status1=0



nandwrite -p /dev/$fdev $fname; echo status2=$?
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000

Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000
Writing data to block 12 at offset 0x180000
Writing data to block 13 at offset 0x1a0000

status2=0

nanddump -l $fsz -f flash-dump /dev/$fdev; echo status3=$?
ECC failed: 0
ECC corrected: 0

Number of bad blocks: 0

Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x001b8524...
status3=0

dd if=flash-dump bs=$fsz count=1 | cmp $fname; echo status4=$?
1+0 records in
1+0 records out

1803556 bytes (1.7MB) copied, 0.091059 seconds, 18.9MB/s
status4=0

rm flash-dump

... and here I noticed I missed the step of moving to the /tmp directory!

I'll move the extracted files there and proceed...

mv initramfs /tmp
mv kernel /tmp
mv sqimage /tmp
cp defaults /tmp
cd /tmp

(not sure if defaults was extracted, but it has the same time stamp as the other extracted files.

Step D

fdev=mtd2
fname=initramfs
fsz=3055680

flash_erase /dev/$fdev 0 0; echo status1=$?

Erasing 128 Kibyte @ 4e0000 -- 100 % complete
status1=0

nandwrite -p /dev/$fdev $fname; echo status2=$?
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000

Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000
Writing data to block 12 at offset 0x180000
Writing data to block 13 at offset 0x1a0000
Writing data to block 14 at offset 0x1c0000

Writing data to block 15 at offset 0x1e0000
Writing data to block 16 at offset 0x200000
Writing data to block 17 at offset 0x220000
Writing data to block 18 at offset 0x240000
Writing data to block 19 at offset 0x260000
Writing data to block 20 at offset 0x280000
Writing data to block 21 at offset 0x2a0000
Writing data to block 22 at offset 0x2c0000
Writing data to block 23 at offset 0x2e0000
status2=0

nanddump -l $fsz -f flash-dump /dev/$fdev; echo status3=$?
ECC failed: 0
ECC corrected: 0

Number of bad blocks: 0

Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64

Dumping data starting at 0x00000000 and ending at 0x002ea040...
status3=0

dd if=flash-dump bs=$fsz count=1 | cmp $fname; echo status4=$?
1+0 records in
1+0 records out

3055680 bytes (2.9MB) copied, 0.155970 seconds, 18.7MB/s
status4=0

rm flash-dump

Step E

fdev=mtd3
fname=sqimage
fsz=14862336

flash_erase /dev/$fdev 0 0; echo status1=$?

Erasing 128 Kibyte @ 3c20000 -- 58 % complete flash_erase: Skipping bad block at 03c40000
Erasing 128 Kibyte @ 65e0000 -- 100 % complete
status1=0

nandwrite -p /dev/$fdev $fname; echo status2=$?
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000

Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000
Writing data to block 12 at offset 0x180000
Writing data to block 13 at offset 0x1a0000
Writing data to block 14 at offset 0x1c0000

Writing data to block 15 at offset 0x1e0000
Writing data to block 16 at offset 0x200000
Writing data to block 17 at offset 0x220000
Writing data to block 18 at offset 0x240000
Writing data to block 19 at offset 0x260000
Writing data to block 20 at offset 0x280000
Writing data to block 21 at offset 0x2a0000
Writing data to block 22 at offset 0x2c0000
Writing data to block 23 at offset 0x2e0000
Writing data to block 24 at offset 0x300000
Writing data to block 25 at offset 0x320000
Writing data to block 26 at offset 0x340000
Writing data to block 27 at offset 0x360000
Writing data to block 28 at offset 0x380000
Writing data to block 29 at offset 0x3a0000
Writing data to block 30 at offset 0x3c0000
Writing data to block 31 at offset 0x3e0000
Writing data to block 32 at offset 0x400000
Writing data to block 33 at offset 0x420000
Writing data to block 34 at offset 0x440000
Writing data to block 35 at offset 0x460000
Writing data to block 36 at offset 0x480000
Writing data to block 37 at offset 0x4a0000
Writing data to block 38 at offset 0x4c0000
Writing data to block 39 at offset 0x4e0000
Writing data to block 40 at offset 0x500000
Writing data to block 41 at offset 0x520000
Writing data to block 42 at offset 0x540000
Writing data to block 43 at offset 0x560000
Writing data to block 44 at offset 0x580000
Writing data to block 45 at offset 0x5a0000
Writing data to block 46 at offset 0x5c0000
Writing data to block 47 at offset 0x5e0000
Writing data to block 48 at offset 0x600000
Writing data to block 49 at offset 0x620000
Writing data to block 50 at offset 0x640000
Writing data to block 51 at offset 0x660000
Writing data to block 52 at offset 0x680000
Writing data to block 53 at offset 0x6a0000
Writing data to block 54 at offset 0x6c0000
Writing data to block 55 at offset 0x6e0000
Writing data to block 56 at offset 0x700000
Writing data to block 57 at offset 0x720000
Writing data to block 58 at offset 0x740000
Writing data to block 59 at offset 0x760000
Writing data to block 60 at offset 0x780000
Writing data to block 61 at offset 0x7a0000
Writing data to block 62 at offset 0x7c0000
Writing data to block 63 at offset 0x7e0000
Writing data to block 64 at offset 0x800000
Writing data to block 65 at offset 0x820000
Writing data to block 66 at offset 0x840000
Writing data to block 67 at offset 0x860000
Writing data to block 68 at offset 0x880000
Writing data to block 69 at offset 0x8a0000
Writing data to block 70 at offset 0x8c0000
Writing data to block 71 at offset 0x8e0000
Writing data to block 72 at offset 0x900000
Writing data to block 73 at offset 0x920000
Writing data to block 74 at offset 0x940000
Writing data to block 75 at offset 0x960000
Writing data to block 76 at offset 0x980000
Writing data to block 77 at offset 0x9a0000
Writing data to block 78 at offset 0x9c0000
Writing data to block 79 at offset 0x9e0000
Writing data to block 80 at offset 0xa00000
Writing data to block 81 at offset 0xa20000
Writing data to block 82 at offset 0xa40000
Writing data to block 83 at offset 0xa60000
Writing data to block 84 at offset 0xa80000
Writing data to block 85 at offset 0xaa0000
Writing data to block 86 at offset 0xac0000
Writing data to block 87 at offset 0xae0000
Writing data to block 88 at offset 0xb00000
Writing data to block 89 at offset 0xb20000
Writing data to block 90 at offset 0xb40000
Writing data to block 91 at offset 0xb60000
Writing data to block 92 at offset 0xb80000
Writing data to block 93 at offset 0xba0000
Writing data to block 94 at offset 0xbc0000
Writing data to block 95 at offset 0xbe0000
Writing data to block 96 at offset 0xc00000
Writing data to block 97 at offset 0xc20000
Writing data to block 98 at offset 0xc40000
Writing data to block 99 at offset 0xc60000
Writing data to block 100 at offset 0xc80000
Writing data to block 101 at offset 0xca0000
Writing data to block 102 at offset 0xcc0000
Writing data to block 103 at offset 0xce0000
Writing data to block 104 at offset 0xd00000
Writing data to block 105 at offset 0xd20000
Writing data to block 106 at offset 0xd40000
Writing data to block 107 at offset 0xd60000
Writing data to block 108 at offset 0xd80000
Writing data to block 109 at offset 0xda0000
Writing data to block 110 at offset 0xdc0000
Writing data to block 111 at offset 0xde0000
Writing data to block 112 at offset 0xe00000
Writing data to block 113 at offset 0xe20000
status2=0

nanddump -l $fsz -f flash-dump /dev/$fdev; echo status3=$?
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 1
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64

Dumping data starting at 0x00000000 and ending at 0x00e2c800...
status3=0

dd if=flash-dump bs=$fsz count=1 | cmp $fname; echo status4=$?
1+0 records in
1+0 records out

14862336 bytes (14.2MB) copied, 0.767246 seconds, 18.5MB/s
status4=0

rm flash-dump

This is what I see on the Firmware Update page
...
The box is currently running Alt-F 0.1RC4 with kernel 3.10.32, and flashed with Alt-F-0.1RC4.1, initrd.

Better than before :-)

Anything else I need to check before a restart?

Thanks so much,
Chris.


On Monday, February 16, 2015 at 5:12:48 PM UTC-5, João Cardoso wrote:

On Monday, February 16, 2015 at 5:06:44 PM UTC, Chris Archer wrote:

Thanks for the update.

[root@DOT]# dmesg | tail
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs (sda3): error count: 9311
EXT4-fs (sda3): initial error at 1423986727: __ext4_new_inode:741
EXT4-fs (sda3): last error at 1423986837: __ext4_new_inode:741
EXT4-fs (sdb3): error count: 9311
EXT4-fs (sdb3): initial error at 1423986837: __ext4_new_inode:741
EXT4-fs (sdb3): last error at 1423986942: __ext4_new_inode:741

 

There are errors on the ext4 filesystem at sda3 and sdb3. That is a different issue that you have to correct latter by using fsck.

  

Remained the same after each test. BTW, I ran 'badblocks /dev/sdb' and it came up empty. Running 'badblocks /dev/sda' but I suspect it won't show anything either.

badblocks diagnose problems at the hardware level, the errors are at the filesystem level -- they can or not be related. But again, that is a separate issue. And... where did you get 'badblocks' from? ffp?

 

[Chris Archer]

After following your instructions for flashing, tried the commands you had posted earlier

dd if=/dev/mtd1 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'
Alt-F-0.1RC4.1, kernel 3.10.32

[root@DOT]# dd if=/dev/mtd2 ibs=32 skip=1 count=1 2> /dev/null | grep -o 'Alt-F.*'
Alt-F-0.1RC4.1, initrd

Chris.

[Chris Archer]

It worked!

Rebooted and status shows sdb3 is being checked, and Firmware Update page shows:
The box is currently running Alt-F 0.1RC4.1 with kernel 3.10.32, and flashed with Alt-F-0.1RC4.1, initrd.

THANK YOU, THANK YOU, a million times THANK YOU for the patient, detailed explanation.

It is HUGELY appreciated by me, and I hope it's useful to others.

In case I did not say it before, THANK YOU!

Chris.

[João Cardoso]

On Tuesday, February 17, 2015 at 1:55:40 AM UTC, Chris Archer wrote:

It worked!

Great!

Now the question is: why did the webUI failed? The commands you executed are exactly the same that the webUI uses... and no error (status=0) was ever reported in your commands (thanks for posting its full output, saying just "run OK" is not enough, as small details can be unnoticed to the untrained eye).

So, the issue might reappear when you will try to upgrade again. Please post the output of the command

ls -l /Alt-F/usr/www/cgi-bin/firmware*

I would expect a "ls: /Alt-F/usr/www/cgi-bin/firmware*: No such file or directory". If files exists, that is the issue (and I should have started by this)

Rebooted and status shows sdb3 is being checked, and Firmware Update page shows:
The box is currently running Alt-F 0.1RC4.1 with kernel 3.10.32, and flashed with Alt-F-0.1RC4.1, initrd.

THANK YOU, THANK YOU, a million times THANK YOU for the patient, detailed explanation.

It is HUGELY appreciated by me, and I hope it's useful to others.

In case I did not say it before, THANK YOU!

Chris.

I (or someone else) now only need to create a Wiki page on this subject, essentially copying/using my instructions on "How to  flash the firmware for the DNS-320/320L/325 from the command line", "How the test the flash memory for  DNS-320/320L/325 the from the command line", and "How to  flash the firmware for the DNS-321/323 from the command line". 

[Chris Archer]

ls -l /Alt-F/usr/www/cgi-bin/f*
ls: /Alt-F/usr/www/cgi-bin/f*: No such file or directory

My web UI also looks "strange" compared to the old web UI. Font is bigger. I'll attach a screen shot. This has been true on all flashed boxes, both the DNS-323 and DNS-325

I (or someone else) now only need to create a Wiki page on this subject, essentially copying/using my instructions on "How to  flash the firmware for the DNS-320/320L/325 from the command line", "How the test the flash memory for  DNS-320/320L/325 the from the command line", and "How to  flash the firmware for the DNS-321/323 from the command line".

I can volunteer to do that. What Wiki software, where is it hosted?

Chris.

[João Cardoso]

On Thursday, February 19, 2015 at 2:02:27 AM UTC, Chris Archer wrote:

ls -l /Alt-F/usr/www/cgi-bin/f*
ls: /Alt-F/usr/www/cgi-bin/f*: No such file or directory

So it remains unexplained. Damn!

 

My web UI also looks "strange" compared to the old web UI. Font is bigger. I'll attach a screen shot. This has been true on all flashed boxes, both the DNS-323 and DNS-325

There was no changes to the font size.

 

I (or someone else) now only need to create a Wiki page on this subject, essentially copying/using my instructions on "How to  flash the firmware for the DNS-320/320L/325 from the command line", "How the test the flash memory for  DNS-320/320L/325 the from the command line", and "How to  flash the firmware for the DNS-321/323 from the command line".

I can volunteer to do that. What Wiki software, where is it hosted?

https://sourceforge.net/p/alt-f/wiki/Home/

[Luca Avalle]

Works FINE on DNS 320 Rev B1.

All my respect to Joao!

THANK YOU!

[Zsolt Lenart]

The manual updgrade works absolutely FINE on 320 Rev A1 too. Thanks a lot for the detailed steps! 

Before  this, I tired  via Web UI multiple times, but that process always stopped at "Don't power off ..." message for hours, while the blue led was blinking rapidly. 


On Monday, 16 February 2015 23:12:48 UTC+1, João Cardoso wrote:

On Monday, February 16, 2015 at 5:06:44 PM UTC, Chris Archer wrote:

Thanks for the update.

[root@DOT]# dmesg | tail
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs error (device sdb3): __ext4_new_inode:741: comm cp: reserved inode found cleared - inode=1
EXT4-fs (sda3): error count: 9311
EXT4-fs (sda3): initial error at 1423986727: __ext4_new_inode:741
EXT4-fs (sda3): last error at 1423986837: __ext4_new_inode:741
EXT4-fs (sdb3): error count: 9311
EXT4-fs (sdb3): initial error at 1423986837: __ext4_new_inode:741
EXT4-fs (sdb3): last error at 1423986942: __ext4_new_inode:741

 

There are errors on the ext4 filesystem at sda3 and sdb3. That is a different issue that you have to correct latter by using fsck.

  

Remained the same after each test. BTW, I ran 'badblocks /dev/sdb' and it came up empty. Running 'badblocks /dev/sda' but I suspect it won't show anything either.

badblocks diagnose problems at the hardware level, the errors are at the filesystem level -- they can or not be related. But again, that is a separate issue. And... where did you get 'badblocks' from? ffp?

 

In the following sections the status=0 line shown that the command had success; any value other than 0 means that an error occurred and you should not reboot the box.

Any  messages other than the ones shown might also mean that an error has occurred.

You might also run the 'dmesg|tail' command to see if any kernel error occurred during the last executed command.

[thiago branquinho]

hello Firstly, thank you very much for the support you always provide here in the group, @joão would you have an ace up your sleeve to help me with my Dlink-320l A3 as I installed Alt-F 1.0 I was unable to progress with the installation of the packages and then I decided to downgrade but I must have done something wrong and now it turns on and has an IP but I can't get any type of connection with it, is there any light?