Closed vmasseron closed 1 year ago
AS I understand:- you recover with QNAP procedure- install buster again- you try to resize again and you have this message. Is that correct ? can you run the followig commands from linux and copy/paster the output: cat /proc/mtd cat /proc/cmdline cat /etc/modprobe.d/local.conf
Regrads,Arnaud
On Fri, 2022-03-25 at 14:59 -0700, lapourgagner wrote:
Like #19 I have recovered my NAS with Qnap procedure. My NAS is a TS419P. When dryrunning (commit 4941696) the script, I got this log that I don't really understand; [Check of the QNAP model and see if supported]DTB file: kirkwood- ts419-6281.dtbPartition resize was not tested on this device yet. Do you want to continue ? (y/N)In case of success, please report the DTB file indication.
Checking: flashcp -VChecking: flash_erase --versionUsing 'u-boot- tools' package [find on which MTD device partitions are currently mounted] spi0.0 [Dump current U-boot config']Current U-boot bootcmd: uart1 0x68;cp.l 0xf8100000 0x800000 0xc0000;cp.l 0xf8400000 0xb00000 0x300000;bootm 0x800000;echo Kernel_legacy layout fallback;bootm 0x900000Current U-boot bootargs: console=ttyS0,115200 root=/dev/ram initrd=0xb00000,0xc00000 ramdisk=32768 @.**@.(Kernel), @.**@*.**@*.(U-Boot @.(NAS Config)" @.(uboot)ro, @*.**@*.**@.(Kernel_legacy), @.(U-Boot @.(NAS Config)" [Prepare new 'bootcmd']"'cp.l 0xf8200000 0x800000 0x0*80000' not found in 'uart1 0x68;cp.l 0xf8100000 0x800000 0xc0000;cp.l 0xf8400000 0xb00000 0x300000;bootm 0x800000;echo Kernel_legacy layout fallback;bootm 0x900000'"Don't know how to patch 'bootcmd' for this model. Please report this log. Let me know if you need any additionnal info.
Btw, I've tested, I have access to Uboot by serial.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: < @.***>
Yes that's it, I will try it on thursday.
you are not the only one to get a problem after recovery.
The investigation shows a debian bug in the installer. The fix for you is:
rm /etc/modprobe.d/local.conf
reboot
qnap_mtd_resize_for_bullseye.py has been updated to not trigger this debian bug... but it is too late for you this time (I mean you will also need to do the rm /etc/modprobe.d/local.conf
again in the future if you reinstall debian again after a recovery)
Arnaud
Hi,
As you adived I have deleted the local.conf
file.
But while running with --dry-run
I got this error:
[Check of the QNAP model and see if supported]
kirkwood-qnap: machine: QNAP TS419 family
DTB file: kirkwood-ts419-6281.dtb
Partition resize was not tested on this device yet. Do you want to continue ? (y/N)
y
In case of success, please report the DTB file indication.
Kernel has already been resized. Can't process further safely.
cat /proc/mtd
return this:
dev: size erasesize name
mtd0: 00080000 00040000 "uboot"
mtd1: 00300000 00040000 "Kernel"
mtd2: 00c00000 00040000 "RootFS1"
mtd3: 00200000 00040000 "Kernel_legacy"
mtd4: 00040000 00040000 "U-Boot Config"
mtd5: 00040000 00040000 "NAS Config"
So if I understand correctly the resize process seems to already have append. Does I understad correctly ? And how ? Haven't oldest tries aborted ?
On Sat, 2022-04-09 at 09:10 -0700, lapourgagner wrote:
Hi, As you adived I have deleted the local.conf file. But while running with --dry-run I got this error: [Check of the QNAP model and see if supported] kirkwood-qnap: machine: QNAP TS419 family DTB file: kirkwood-ts419-6281.dtb Partition resize was not tested on this device yet. Do you want to continue ? (y/N) y In case of success, please report the DTB file indication.
Kernel has already been resized. Can't process further safely. cat /proc/mtd return this: dev: size erasesize name mtd0: 00080000 00040000 "uboot" mtd1: 00300000 00040000 "Kernel" mtd2: 00c00000 00040000 "RootFS1" mtd3: 00200000 00040000 "Kernel_legacy" mtd4: 00040000 00040000 "U-Boot Config" mtd5: 00040000 00040000 "NAS Config" So if I understand correctly the resize process seems to already have append. Does I understad correctly ? And how ? Haven't oldest tries aborted ? yes, exactly. It was already resized because the QNAP recovery process doesn't recover everything, in particularly doesn't modify the uboot configuration where we setup the partitionning.
You can upgrade to bullseye directly
Arnaud
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.*** m>
Thanks a lot
Like #19 I have recovered my NAS with Qnap procedure. My NAS is a TS419P. When dryrunning (commit 4941696) the script, I got this log that I don't really understand;
Let me know if you need any additionnal info. Btw, I've tested, I have access to Uboot by serial.