When trying to install Samba on my Hnet HW-C108 travel router with OpenWRT 19.07.2 I unexpectedly ran out of space. It seems to me the device does not contain as much flash memory as claimed. I'm trying to understand the way the memory is used.
The device page claims the router comes with 16MB of flash memory. This is what I find in the kernel log at boot time:
[ 0.611747] spi spi0.0: force spi mode3
[ 0.625219] m25p80 spi0.0: s25fl064k (8192 Kbytes)
[ 0.630159] 4 fixed-partitions partitions found on MTD device spi0.0
[ 0.636667] Creating 4 MTD partitions on "spi0.0":
[ 0.641583] 0x000000000000-0x000000030000 : "u-boot"
[ 0.647561] 0x000000030000-0x000000040000 : "u-boot-env"
[ 0.653878] 0x000000040000-0x000000050000 : "factory"
[ 0.659822] 0x000000050000-0x000001000000 : "firmware"
[ 0.665140] mtd: partition "firmware" extends beyond the end of device "spi0.0" -- size truncated to 0x7b0000
[ 0.678996] 2 uimage-fw partitions found on MTD device firmware
[ 0.685113] Creating 2 MTD partitions on "firmware":
[ 0.690190] 0x000000000000-0x00000017df95 : "kernel"
[ 0.696115] 0x00000017df95-0x0000007b0000 : "rootfs"
[ 0.702024] mtd: device 5 (rootfs) set to be root filesystem
[ 0.709353] 1 squashfs-split partitions found on MTD device rootfs
[ 0.715749] 0x0000003e3000-0x0000007b0000 : "rootfs_data"
The sizes derived from the address ranges match the sizes of the MTDblock devices, with the peculiarity that the "firmware" partition seems to be sized for a 16MB device, but gets truncated according to a total 8MB device (note the kernel message):
Is there a way I could have misinterpreted this? Should I correct the value on the device page?
The output of df shows I have plenty of space on my SD card. I'm thinking of utilising some of it to make room on the overlay filesystem. What's the smartest way of doing that? Right now it's an exfat filesystem. I have refrained from converting it to ext2/3/4, as the required kernel driver and required utilities are MASSIVE: together they get close to 1MB.
No, the compatible "jedec,spi-nor" instructs the kernel to auto detect the spi nor flash according to the jedec standard.
As your flash chip is detected as "s25fl064k" instead of "en25q128" there are three reasons for your missing space.
Your device has really this detected spi nor type
The magic for your real flash chip does conflict with the one of "s25fl064k"
The magic for "s25fl064k" are wrong
The image hasn´t to be the same size as the space on the flash chip!
I know. But it is one of many hints that the 16MB was some initial mistake that never got corrected. After all, 8MB is also more than the actual data inside.
This brings me to another question: The kernel provides device nodes to access the flash memory. There are (# for some decimal digits) /dev/mtd#, /dev/mtd#ro (both major number 90), and /dev/mtdblock# (major number 31), which for the same decimal digit (0 ... 6 in this device) refer to the same memory. The file 'device.txt' from the linux source describes very shortly the devices. The major number 90 ("Memory Technology Devices") is straightforward: mtd# is read/write, mtd#ro is read-only access. The description for major number 31 confuses me:
31 block ROM/flash memory card
0 = /dev/rom0 First ROM card (rw)
...
7 = /dev/rom7 Eighth ROM card (rw)
8 = /dev/rrom0 First ROM card (ro)
...
15 = /dev/rrom7 Eighth ROM card (ro)
16 = /dev/flash0 First flash memory card (rw)
...
23 = /dev/flash7 Eighth flash memory card (rw)
24 = /dev/rflash0 First flash memory card (ro)
...
31 = /dev/rflash7 Eighth flash memory card (ro)
The read-write (rw) devices support back-caching
written data in RAM, as well as writing to flash RAM
devices. The read-only devices (ro) support reading
only.
Now, what is a ROM with read/write access?
I was looking for a tool that can backup the entire configuration, i.e. including software (installed packages). Basically what I want is a flash memory dump. Is there a special tool for backup/restore?
If not: Dumping via dd is easy, but the data may not be in a consistent state such that when restoring the router can boot again. For that I imagine I'd need to remount the overlay filesystem into ro mode. Is that sufficient for what I have in mind? Then, before restoring, I'd do the same (remount ro), then dd to the rw device, and reboot. Are there any obvious roadblocks to this approach?
Thanks, looks like exactly what I was looking for. I will study it carefully.
Aha, in fact I had not noticed it before. However, it says:
NOTE: THIS FEATURE IS FOR PROFESSIONALS!
I take that to mean that there are caveats involved that the user needs to be aware of, and the user should know exactly what LuCI is doing there in the background. Do you know of any docs related to this? An immediate question is, whether I get a pure image, or one that is tagged with info which block is backed up? I can check the size of course. But there is no specific option to restore an image, but only the sysupgrade option. How do I make a backup image sysupgrade-compatible (as the GUI calls it), such that sysupgrade knows which mtdblock to restore?
Maybe those questions are addressed in the document that you pointed me to. I will read that first.
So these backup scripts do not remount the overlay ro. Seems they rely on the fact that all normal system activity happens in RAM filesystems, and only the user would initiate write activities (via LuCI/uCI, or calling opkg). Still the filesystem is mounted rw, and most filesystems modify it anyway even if nothing writes to it, if for simply flagging it for non-proper unmounting after power failure.
Also the scripts assume nor flash. In an earlier message you called my device's flash nor-flash as well:
