OpenWrt Forum Archive

Topic: ReadOnly FS with DSL-502T due to not being aligned on an erase boundry

The content of this topic has been archived on 15 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

From the following portion of logread

Jan  1 00:00:07 (none) user.warn kernel: Looking for mtd device :mtd1:
Jan  1 00:00:07 (none) user.warn kernel: Found a mtd1 image (0x10000), with size (0x76b78).
Jan  1 00:00:07 (none) user.warn kernel: Looking for mtd device :mtd2:
Jan  1 00:00:07 (none) user.warn kernel: Found a mtd2 image (0x0), with size (0x10000).
Jan  1 00:00:07 (none) user.warn kernel: Assuming adam2 size of 0x10000
Jan  1 00:00:07 (none) user.warn kernel: Looking for mtd device :mtd3:
Jan  1 00:00:07 (none) user.warn kernel: Found a mtd3 image (0x3f0000), with size (0x10000).
Jan  1 00:00:07 (none) user.warn kernel: Looking for mtd device :mtd4:
Jan  1 00:00:07 (none) user.warn kernel: Found a mtd4 image (0x10000), with size (0x3e0000).
Jan  1 00:00:07 (none) user.warn kernel: Setting new rootfs offset to 00086b78
Jan  1 00:00:07 (none) user.warn kernel: Squashfs detected (size = 0xb0086bec)
Jan  1 00:00:07 (none) user.notice kernel: Creating 5 MTD partitions on "Physically mapped flash":
Jan  1 00:00:07 (none) user.notice kernel: 0x00000000-0x00010000 : "adam2"
Jan  1 00:00:07 (none) user.notice kernel: 0x00010000-0x003f0000 : "linux"
Jan  1 00:00:07 (none) user.notice kernel: 0x00086b78-0x001c0000 : "rootfs"
Jan  1 00:00:07 (none) user.warn kernel: mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only

It looks like the squashfs must be aligned on an erase boundary. I have flashed a WRT54GS and that worked perfectly, but the same version of code compiled for the AR7 to run on my DSL-502T stays in RO mode obviously (I think) from the last line in the above log.

Should the code compile normally with the correct allignment or is there an option I need to add to the make command (or maybe somewhere in the make menuconfig) that I have missed ?

I have read quite a lot on the processes required but have been unable to turn up a solution.

I have been setting the mtd0 value to
mtd0 0x90086bc7,0x903f0000
by looking for the position of sqsh in the file (theres ony 1 such entry) and using this as the offset. It looks as though the 0x90086bc7 needs to be on an erase boundary (I assume a 4K boundary ?) but I cant see how to get the compile process to pad it to a correct boundary.

I was following the procedure from http://wiki.openwrt.org/OpenWrtDocs/Har … k/DSL-502T

Thanks,
Andrew

Squashfs is not a writable filesystem, so it does not have to be on an erase block boundary at all.

Is that the same for the rootfs ?

The message implies that it would have been RW but because it want on an erase boundary, it was set to RO.

This agrees with what I'm seeing on my modem as it does not retain changes after a boot. On the WRT54GS I flashed, it does retain changes.

Andrew

If you flashed a squashfs image, then squashfs is what goes on the rootfs partition...
By the way, the filesystem/image stuff of AR7 is different than what you have on a WRT54GS. Different boot loader, different image type, different scripts...

Ok  Thanks for your replies ndb.

Looks like I must be looking in the wrong area...

Back to the drawing board I guess.

Thanks,
Andrew

Hi Z3ro,

I tried your suggestion but it didnt work. Below is what was shown on the screen

root@OpenWrt:/bin# firstboot switch2jffs
Unlocking OpenWrt ...
Erasing OpenWrt ...
mount: mounting none on / failed
mount: mounting /dev/mtdblock/4 on /rom/jffs failed
copying files ... done
mount: mounting /mnt/sys on /sys failed
mount: mounting /rom/sys on /sys failed
root@OpenWrt:~/root/bin#

The switch2jffs2 only recopied the files. The above looks promising except for the fact of the failed messages.

I executed the lines in firstboot manually to check the responses and got the following

root@OpenWrt:/bin# mtd erase OpenWrt
Unlocking OpenWrt ...
Erasing OpenWrt ...

executed without error

root@OpenWrt:/bin# mount -o remount,ro none
mount: mounting none on /mnt failed

failed. I checked /mnt it was there with nothing in it.

root@OpenWrt:/bin# mount -o bind / /mnt

Came back to the prompt with no messages

root@OpenWrt:/bin# mount /dev/mtdblock/4 /rom/jffs -t jffs2
mount: mounting /dev/mtdblock/4 on /rom/jffs failed

Seems /rom/jffs already exists and with nothing in it.

Interesting, /mnt now has a copy of / in it, and /rom/jffs also has a copy of /

root@OpenWrt:/bin# umount /mnt

No messages, /mnt still exists and with the same copy of / in it

root@OpenWrt:/bin# pivot /rom /mnt
/bin/ash: pivot: not found

I'll have to see if I can find where pivot is meant to be. I have also seen mention of nvram in some scripts and havent been able to find that either. Is that meant for the WRT54X's ?

Thanks for the suggestion,
Andrew

Hi.

I've got the same problem with Asmax AR 804gu (Aztech DWL600EW).

Try this:

1. After flashing, telnet to device and type reboot (for sure).
2. Telnet again and execute firstboot - this will copy files to /rom/jffs (I don't know why this is not happening after first reboot).
3. Type reboot (not unplug the power).
4. When device is up, you should have writable root fs mounted on /.

Because Kamikaze comes without mini_fo (I think) to edit files, you have to remove symlinks, copy file form squash fs and then edit it. For example, to change root password, you have to do this before passwd:

rm /etc/passwd
cp /rom/passwd /etc/

Booboo.

The "not aligned to erase boundary" is normal. A readonly filesystem does not need to be writable.

Firstboot should run automatically on the first bootup - do not interrupt it by rebooting.

bubu01:
mini_fo is used for the express purposes of not using symlinks; just edit the file directly and it should do the right thing.

Sorry, it should be "I've had the same problem..."

But I had to do things 1 to 4, to have writable root fs on my device.

Bubu01,

Thanks heaps !

That did the trick. I have tried a number of combinations but must have missed that one. Worked a treat.

It's not as nice as the WRT54GS I flashed which makes the entire system look RW (ie no links to /rom) but this one works fine.

Thanks again,
Andrew

thanks for the hint

I just flashed 6193

The discussion might have continued from here.