Question about recovery mode after mtd layout changes

[TBBle]

Given #20 (comment), if f I can't find my old MTD backups (Hopefully archived somewhere) or can't find them on the 'net (can I extract it from the Qnap firmware download or LiveCD? I can see the 16MB image sent by tftp in the latter, I guess I can dd out of the middle of that to get what I need?), am I correct in understanding I could still use network recovery to reflash the Qnap stock image? I see in the U-Boot_Config:

bootcmd=cp.l 0xf8100000 0x800000 0xc0000;cp.l 0xf8400000 0xb00000 0x300000;bootm 0x800000;echo Kernel_legacy layout fallback;bootm 0x900000

so I assume that means if it can't boot the kernel in (new) mtd1, it'll boot the kernel in (new) mtd3, i.e. the kernel flashed by the network recovery. I'm not sure how bootm fails though, so I might be reading too much into this and it will never actually fall back, or only falls back if I actually erase (new) mtd1 first or something.

If this fallback setup works, it seems that with a small-enough d-i image, i.e the one from buster, that would also be doable via network-recovery boot.

Or have I misunderstood something about u-boot and the network recovery? Does it always boot from the (new) mtd3 partition after flashing it, irrespective of uboot configuration? I also see this in the U-Boot_Config, which I guess is related?:

update=tftp 0x800000 uImage; tftp 0xa00000 rootfs.gz;bootm 0x800000

[amouiche]

Hello. Just to be sure before giving you an advise, can you copy/paste your whole uboot config, in particularly the "bootargs" part ? Arnaud

…

On Sun, 2022-09-25 at 01:15 -0700, TBBle wrote: Given #20 (comment), if f I can't find my old MTD backups (Hopefully archived somewhere) or can't find them on the 'net (can I extract it from the Qnap firmware download or LiveCD? I can see the 16MB image sent by tftp in the latter, do I need to dd out of the middle of that?), am I correct in understanding I could still use network recovery to reflash the Qnap stock image? I see in the U-Boot_Config: bootcmd=cp.l 0xf8100000 0x800000 0xc0000;cp.l 0xf8400000 0xb00000 0x300000;bootm 0x800000;echo Kernel_legacy layout fallback;bootm 0x900000 so I assume that means if it can't boot the kernel in (new) mtd1, it'll boot the kernel in (new) mtd3, i.e. the kernel flashed by the network recovery. I'm not sure how bootm fails though, so I might be reading too much into this and it will never actually fall back, or only falls back if I actually erase (new) mtd1 first or something. If this fallback setup works, it seems that with a small-enough d-i image, i.e the one from buster, that would also be doable via network-recovery boot. Or have I misunderstood something about u-boot and the network recovery? Does it always boot from the (new) mtd3 partition after flashing it, irrespective of uboot configuration? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[TBBle]

Oh, blast. I already went ahead and flashed the installer (using flashcp per #32), confirmed that it boots into d-i, and put the machine aside.

If I get a chance to boot the machine again before I pass it on, I'll extract the uboot config and share it, in case the next user hits issues. Otherwise I'll close this issue.

[amouiche]

ok. The way it should work once you install the new partition scheme is that the boot try to load a kernel from BIG/New kernel partitin first, and if it fails (there is a hash check done by the bootloader), it will try to load from Legacy partition. So you should boot whatever installer/QNAP original firmware you install. for the rootfs, since we keep the partition start offset, there is no issue. If you install a debian installer again, you are already using the new partiion scheme (BIG kernelfs+rootfs) regards, arnaud

…

On Mon, 2022-09-26 at 01:59 -0700, TBBle wrote: Oh, blast. I already went ahead and flashed the installer (using flashcp per #32), confirmed that it boots into d-i, and put the machine aside. If I get a chance to boot the machine again before I pass it on, I'll extract the uboot config and share it, in case the next user hits issues. Otherwise I'll close this issue. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.*** m>

[TBBle]

Okay, that makes sense. The hash-check explains how the fall-back can operate, thank you.