The firstboot command does not look happy:
root@OpenWrt:/etc# firstboot -y
/dev/loop0 is mounted as /overlay, only erasing files
I managed to install fdisk, below is is the reported partition scheme. At least the space is there
root@OpenWrt:/etc/opkg# fdisk /dev/mmcblk0
Welcome to fdisk (util-linux 2.39).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.
Command (m for help): p
Disk /dev/mmcblk0: 3.53 GiB, 3791650816 bytes, 7405568 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 98101B32-BBE2-4BF2-A06E-2BB33D000C20
Device Start End Sectors Size Type
/dev/mmcblk0p1 34 16417 16384 8M unknown
/dev/mmcblk0p2 16418 18465 2048 1M unknown
/dev/mmcblk0p3 18466 30753 12288 6M unknown
/dev/mmcblk0p4 30754 153633 122880 60M unknown
/dev/mmcblk0p5 153634 161825 8192 4M unknown
/dev/mmcblk0p6 161826 163873 2048 1M unknown
/dev/mmcblk0p7 163874 176161 12288 6M unknown
/dev/mmcblk0p8 176162 299041 122880 60M unknown
/dev/mmcblk0p9 299042 307233 8192 4M unknown
/dev/mmcblk0p10 307234 1355809 1048576 512M unknown
/dev/mmcblk0p11 1355810 7122977 5767168 2.8G unknown
I can mount correctly partitions 1 (ext4 containing just two dirs,
work with something that looks like a linux directory structure), 10 (empty ext4 filesystem) and 11 (ext4, I suppose it's the /tmp/ApplicationData of the official firmware), the others throw
/etc/fstab does not contain any mountpoint.
That looks like you did the process a 2nd time and this is wrong and does produce errors like this. You have installed OpenWrt already. The commands are not there.
What you could do is to load the sysupgrade file to /tmp and execute sysupgrade from command line like:
sysupgrade -v /path/to/filename
To see if it works flawlessly.
That is correct. This is due to how OpenWrt is built.
Correct, but the output was exactly the same when I first run the script from the official firmware.
Same for sysupgrade command: I've just run it and had exactly the same result, a factory openwrt install without using vendor emmc partitions.
I tried to go back to the original firmware with the change_boot_partition.sh to repeat the install procedure, but I got this:
1+0 records in
1+0 records out
1+0 records in
1+0 records out
Could not open mtd device: /dev/mtd2
Can't open device for writing!
Could not open mtd device: /dev/mtd3
Can't open device for writing!
It looks like these commands are failing:
mtd write boot.bin /dev/mtd2
mtd write boot.bin /dev/mtd3
I tried rebooting but it went back to openwrt, which makes sense since it was not able to write the boot partition.
What if I force a reset procedure via the hardware button?
If you did an sysupgrade already then you cannot go back with this method because sysupgrade is writing the other boot partition. This works only if you've flashed exactly once. This is missleading in the wiki.
Serial access is the only way I know atm to get OEM firmware back to your device.
Reset Button resets the installed system to its defaults. It does not reset to another firmware.
Ok then, I suppose the only way out I have - besides going serial - is fixing the overlay mount point.
Is it ok if I do it via extroot or there are cleaner ways?
EDIT: tried extroot method but it does not like it, it keeps falling back to loop0
root@OpenWrt:~# block info; uci show fstab; logread | sed -n -e "/- preinit -/,/- init -/p"
/dev/loop0: UUID="6b98b264-5fb9-42fa-ba2f-a0083007bc08" LABEL="rootfs_data" VERSION="1.0" MOUNT="/overlay" TYPE="ext4"
/dev/mmcblk0p1: UUID="6219f2d2-f042-420a-90be-f02b039de9fc" VERSION="1.0" TYPE="ext4"
/dev/mmcblk0p10: UUID="43fbd48b-10fb-4368-aa21-1310186c72ad" VERSION="1.0" TYPE="ext4"
/dev/mmcblk0p11: UUID="417be33b-a0e7-4bb4-939e-0d54c315e5c6" LABEL="extroot" VERSION="1.0" TYPE="ext4"
/dev/mmcblk0p4: UUID="94956bf8-c7b04361-f144155c-ebee7d4e" VERSION="4.0" TYPE="squashfs"
/dev/mmcblk0p5: UUID="c16c0598-b9ca654e-958daa12-10dff7a6" VERSION="4.0" TYPE="squashfs"
/dev/mmcblk0p8: UUID="94956bf8-c7b04361-f144155c-ebee7d4e" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
/dev/mmcblk0p9: UUID="d3a1b394-b47d964f-c45497fd-89ea35eb" VERSION="4.0" TYPE="squashfs"
Mon May 29 01:34:53 2023 user.info kernel: [ 4.275203] init: - preinit -
Mon May 29 01:34:53 2023 kern.notice kernel: [ 4.449009] random: jshn: uninitialized urandom read (4 bytes read)
Mon May 29 01:34:53 2023 kern.notice kernel: [ 4.468144] random: jshn: uninitialized urandom read (4 bytes read)
Mon May 29 01:34:53 2023 kern.notice kernel: [ 4.475445] random: jshn: uninitialized urandom read (4 bytes read)
Mon May 29 01:34:53 2023 kern.info kernel: [ 6.570477] loop0: detected capacity change from 0 to 122880
Mon May 29 01:34:53 2023 kern.info kernel: [ 6.648250] loop0: detected capacity change from 122880 to 108928
Mon May 29 01:34:53 2023 kern.notice kernel: [ 6.648612] random: procd: uninitialized urandom read (4 bytes read)
Mon May 29 01:34:53 2023 kern.info kernel: [ 6.687914] EXT4-fs (loop0): recovery complete
Mon May 29 01:34:53 2023 kern.info kernel: [ 6.690004] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
Mon May 29 01:34:53 2023 user.info kernel: [ 6.692411] mount_root: loading kmods from internal overlay
Mon May 29 01:34:53 2023 user.info kernel: [ 6.708489] kmodloader: loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
Mon May 29 01:34:53 2023 user.info kernel: [ 6.709222] kmodloader: done loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
Mon May 29 01:34:53 2023 user.info kernel: [ 7.700787] block: attempting to load /etc/config/fstab
Mon May 29 01:34:53 2023 user.err kernel: [ 7.701756] block: unable to load configuration (fstab: Entry not found)
Mon May 29 01:34:53 2023 user.err kernel: [ 7.704829] block: no usable configuration
Mon May 29 01:34:53 2023 user.info kernel: [ 7.712411] mount_root: switching to ext4 overlay
Mon May 29 01:34:53 2023 kern.warn kernel: [ 7.717899] overlayfs: null uuid detected in lower fs '/', falling back to xino=off,index=off,nfs_export=off.
Mon May 29 01:34:53 2023 user.warn kernel: [ 7.722876] urandom-seed: Seeding with /etc/urandom.seed
Mon May 29 01:34:53 2023 user.info kernel: [ 7.750919] procd: - early -
Mon May 29 01:34:53 2023 user.info kernel: [ 7.750999] procd: - watchdog -
Mon May 29 01:34:53 2023 kern.notice kernel: [ 8.068250] random: crng init done
Mon May 29 01:34:53 2023 kern.notice kernel: [ 8.068289] random: 2 urandom warning(s) missed due to ratelimiting
Mon May 29 01:34:53 2023 user.info kernel: [ 8.289323] procd: - watchdog -
Mon May 29 01:34:53 2023 user.info kernel: [ 8.289692] procd: - ubus -
Mon May 29 01:34:53 2023 user.info kernel: [ 8.344601] procd: - init -
daemon.err block: /dev/loop0 is already mounted on /overlay in logread
I just noticed that loop0 is backed by /mmcblk0p8
root@OpenWrt:~# cat /sys/class/block/loop0/loop/backing_file
I am missing which process is forcing the overlay to loop0, and/or how to change it redirecting to mmcblk0p11.
Full logread here.
That's correct, because OpenWrt is written as an image to the "partition" and then mounted as a loop device. The error about "already mounted" is not popping up on my device. But I would not weigh it heavy (it could just be a process trying it again). The log itself looks fine to me. The mtd partitions and its boundaries are all found and the same as on my device.
The output from "df -h" is telling the overlay is mounted and has free space. fdisk is looking good as well. firstboot command output is correct also. It is deleting files as it is mounted.
What do you want achive exactly now? If you are able to install fdisk the overlay should be O.K. and OpenWrt is running fine.
If you want to go back to OEM firmware then there is one option only. Serial access.
If you did an mtd/nand backup before flashing you could try to write it back to its partitions. But writing to mtd is risky because it is not bothering with faulty flash cells. Nanddump would be able to do this but it is not included within standard OpenWrt images. I don't have a backup from boot and root. I just saved the essentials like art.
Maybe another one have it and could provide it to you uploading it.
Maybe I'm looking at it in the wrong way, but my problem here is that I wasn't expecting an overlay partition of 60MB while there are two usable partitions of about 512MB and a 3GB... I basically would like to move the overlay to one of them.
I don't want to go back to the stock firmware, that was just an option to try a reinstall, expecting a different mount scheme.
Could you share your
df -h output?
Rootfs is there 2 times (mmcblk0p4 and p8). Boot/Kernel 2 times (p3 and p7) also. That is dual boot.
The Application/Data partition is not used by OpenWrt itself to keep the layout for a possible revert to OEM firmware. That is a decission made by OpenWrt.
While I do not need extroot or the extra space I think you can use it as extroot. But that is out of scope here. I would recommend to follow the wiki and adopt it accordingly and if you have problems open a new thread and ask specific questions. You have propably a wider audience then here.
root@NBG7815:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 36.0M 36.0M 0 100% /rom
tmpfs 434.3M 6.4M 427.9M 1% /tmp
/dev/loop0 21.1M 716.0K 18.7M 4% /overlay
overlayfs:/overlay 21.1M 716.0K 18.7M 4% /
tmpfs 512.0K 0 512.0K 0% /dev
My bad then, I always misunderstood the correct configuration...
I'll let you know if I manage to find a way to make extroot working: I already followed the wiki instruction but there's probably a bug in block that needs a patch.
Yes, this makes sense here and it could explain the issues with block-mount and wifi as well. Maybe I'll give it a try and integrate this patch in my next build to see what happens.
What i have to do? how to install Luci?
got it. next step?
I want to install openwrt in order to directly connect the wan port to the provider ont
@asvio may I use your repo as a base ? I noticed that the
mac-address-ascii from @pwned patch was already merged together with fan and led control, I'd like to try to build my own image patching it with the mentioned block patch above to allow emmc extroot.
Anything to look out for? A build .config to share?
You mean a stable build instead of a snapshot release (see here: https://openwrt.org/downloads)? As far as I understand you have to wait until 23.XX is released.
Of course you can. It's there in case anyone wants to use it.
mac-address-ascii patch is on main branch. I've not make any change about it.
EDIT: nbg7815-nss repo it's not ready to use. It's better to wait until i find a way to make wifi stable and a better comunication between client.
It's a known problem of nss version.
As i said in the previous post., mac- address modification was there, so if no one has the mac address change behavor it's must be my config what it is introducing it. I have tried also with master branch. No way for me. Next will be reset to default.
Sorry I didn't realize that. Is there a non-nss repo with all the additional patches? I noticed that the not all the ones committed in your repo are easily exportable to be integrated directly in a openwrt
All nbg7815 branches of my openwrt repository include led and fan support from @itorK and @avalentin, main branch is a original openwrt clone.
You can look to the last commits to see what extras its have.
Thanks, I didn't notice the branches inside the openwrt repo.