Script for resizing MTD partitions on a QNAP device in order to be available to upgrade from buster to bullseye

Overview

QNAP partitions resize for kirkwood devices.

As explained by Marin Michlmayr, Debian bullseye support on kirkwood QNAP devices was dropped due to [mainly] the limited size of the Kernel partition (2MB).

Indeed, Bullseye current kernel image (vmlinuz-5.10.0-8-marvell) is 2445216 bytes long (2.3MB)

In addition, partition for initrd is also limited (9MB) which may lead to space issues.

Hopefully, some space is still unused for Debian in QNAP 16MB NOR flash.

  • An additional 3MB Rootfs2 partition is used by original QNAP firmware for its own purpose (install on empty HDD ?)
  • A "NAS config" partition is 1.2MB large despite containing few configuration files (<128KB). This partition can be resized to 256KB (Flash block size) without losing the information.

New Layout

With this script, we propose to use a new flash layout

Layout

  • We keep /dev/mtdX numbers mapping, in case some other users are using a fix numbering.
  • we keep a window on legacy kernel mapping to help if we want to restore the original QNAP firmware or to install the Buster installer
  • Rootfs1 is larger but use the same start offset (simplify the transition since no write in flash is required)
  • Kernel is larger. We must be careful during the transition since offsets are different.

With this new layout, we can transparently upgrade to Bullseye

  • More room for kernel and initrd
  • Future kernel updates performed during apt upgradewill use the new layout without any further change or manual operations.

Kernel and MTD partitions

Linux has 2 methods for configuring the partitions.

  1. Device Tree

    This is the standard way to describe the device.

    see: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-ts219.dtsi

    ; label = "Kernel"; }; partition@400000 { reg = <0x00400000 0x00900000>; label = "RootFS1"; }; partition@d00000 { reg = <0x00d00000 0x00300000>; label = "RootFS2"; }; partition@40000 { reg = <0x00080000 0x00040000>; label = "U-Boot Config"; }; partition@c0000 { reg = <0x000c0000 0x00140000>; label = "NAS Config"; }; }; ">
    			m25p128@0 {
    				[...]
    				partition@0 {
    					reg = <0x00000000 0x00080000>;
    					label = "U-Boot";
    				};
    				partition@200000 {
    					reg = <0x00200000 0x00200000>;
    					label = "Kernel";
    				};
    				partition@400000 {
    					reg = <0x00400000 0x00900000>;
    					label = "RootFS1";
    				};
    				partition@d00000 {
    					reg = <0x00d00000 0x00300000>;
    					label = "RootFS2";
    				};
    				partition@40000 {
    					reg = <0x00080000 0x00040000>;
    					label = "U-Boot Config";
    				};
    				partition@c0000 {
    					reg = <0x000c0000 0x00140000>;
    					label = "NAS Config";
    				};
    			};
    

    On Debian, binary versions (dtb) are provided by the linux-image-4.19.0-16-marvell package.

    Every time a new kernel version is flashed by flash-kernel, the proper dtb blob is concatenated to the kernel image so the kernel knows the details of the machine and is able to configure all the drivers properly (including the MTD partitions).

    It is not difficult to build a DTB and configure Debian to use this alternate DTB file. It simply need to be present in /etc/flash-kernel/dtbs/directory and flash-kernel will correctly switch to our own specific file.

    Example:

    cd [clone of linux sources]/linux
    # modify arch/arm/boot/dts/kirkwood-ts219.dtsi
    
    for D in kirkwood-ts219-6281 kirkwood-ts219-6282; do
        cpp -nostdinc -I include -I arch  -undef -x assembler-with-cpp \
           ./arch/arm/boot/dts/$D.dts \
           /tmp/preprocess.dts
        dtc -O dtb -o /tmp/$D.dtb /tmp/preprocess.dts
        cp /tmp/$D.dtb /etc/flash-kernel/dtbs/
        done
    
    
  2. kernel boot cmdline

    U-boot can also override the DTB information by using mtdparts=....options as parsed by https://github.com/torvalds/linux/blob/master/drivers/mtd/parsers/cmdlinepart.c

    The kernel try use use cmdline parameters before DTB information.

    Original QNAP U-boot configuration doesn't use this method.

I select the "kernel boot cmdline" solution to configure the new layout:

  • if /etc/flash-kernel/dtbs/content is modified or erased for some reasons (new install ?) the u-boot setup and the kernel MTD usage will not be synchronized and the device will fail to boot.
  • cmdline only "patch/override" the MTD partitions information. If the original DTB file provided by Debian is updated for some reasons (driver fixes), the kernel will still continue to use those fixes.

The qnap_mtd_resize.py script will:

  • Resize the "NAS config" filesystem
  • Prepare the content of current "NAS config" partition (offset 0xc0000 to 0x200000) with the shrink FS + first 1MB of the current kernel
  • prepare the image of current "Kernel" partition (starting at 0x200000) with tail of the current kernel
  • Patch U-boot env/config for the new bootargsand bootcmdvariables.
  • Write flash from 0xc0000 to 0x200000 ("NAS config" + 1MB head of kernel)
  • write flash from 0x200000 with 1MB tail of kernel.

Resize process

First, Do a backup of your MTD

cat /dev/mtd0 > /tmp/mtd0.uboot.backup
cat /dev/mtd1 > /tmp/mtd1.kernel.backup
cat /dev/mtd2 > /tmp/mtd2.rootfs1.backup
cat /dev/mtd3 > /tmp/mtd3.rootfs2.backup
cat /dev/mtd4 > /tmp/mtd4.uboot-config.backup
cat /dev/mtd5 > /tmp/mtd5.nas-config.backup
cd /tmp
tar cvzf mtd_backup.tgz mtd?.*.backup

And save this mtd_backup.tgzon your PC, transfering the file with scp / sftp or a USB drive....

Then, run qnap_mtd_resize.py

A first run with --dry-runoption to check that everything will be fine (except flashing)

sudo ./qnap_mtd_resize.py --dry-run

Example of dry-run log here.

If everything is fine run again without --dry-run

sudo ./qnap_mtd_resize.py

And reboot...

You are now running the same system, but with more room:

$ cat /proc/mtd 
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"

Which makes possible to install Bullseye's kernel:

$ flash-kernel 
kirkwood-qnap: machine: QNAP TS219 family
Using DTB: kirkwood-ts219-6281.dtb
Installing /usr/lib/linux-image-5.10.0-8-marvell/kirkwood-ts219-6281.dtb into /boot/dtbs/5.10.0-8-marvell/./kirkwood-ts219-6281.dtb
Taking backup of kirkwood-ts219-6281.dtb.
Installing new kirkwood-ts219-6281.dtb.
flash-kernel: installing version 5.10.0-8-marvell
flash-kernel: appending /usr/lib/linux-image-5.10.0-8-marvell/kirkwood-ts219-6281.dtb to kernel
Generating kernel u-boot image... done.
Flashing kernel (using 2455558/3145728 bytes)... done.
Flashing initramfs (using 3992060/12582912 bytes)... done.

Additional configuration to improveinitrd size

Even if we increase Rootfs1 from 9 to 12 MB, you can still decrease the initrd size by compressing with xz

/etc/initramfs-tools/conf.d/compress ">
echo "COMPRESS=xz" > /etc/initramfs-tools/conf.d/compress

List of tested devices:

Model cat /sys/firmware/devicetree/base/model DTB file uboot env
(legacy)
uboot_env
(new)
Resize log
TS-219P QNAP TS219 family kirkwood-ts219-6281.dtb
TS-419PII QNAP TS419 family kirkwood-ts419-6282.dtb QNAP_TS419_family,uboot-env.legacy QNAP_TS419_family,uboot-env.new log
Comments
  • Upgrade from Buster to Bullseye failed.

    Upgrade from Buster to Bullseye failed.

    Hi, first of all many thanks a lot for providing this script!

    However, I have problem. I realized Bullseye was not supported on QNAP only at the end of the upgrade from Buster, when I got the following message:

    Processing triggers for initramfs-tools (0.140) ...
    update-initramfs: Generating /boot/initrd.img-5.10.0-9-marvell
    kirkwood-qnap: machine: QNAP TS219 family
    Using DTB: kirkwood-ts219-6282.dtb
    Installing /usr/lib/linux-image-5.10.0-9-marvell/kirkwood-ts219-6282.dtb into /boot/dtbs/5.10.0-9-marvell/./kirkwood-ts219-6282.dtb
    Taking backup of kirkwood-ts219-6282.dtb.
    Installing new kirkwood-ts219-6282.dtb.
    Installing /usr/lib/linux-image-5.10.0-9-marvell/kirkwood-ts219-6282.dtb into /boot/dtbs/5.10.0-9-marvell/./kirkwood-ts219-6282.dtb
    Taking backup of kirkwood-ts219-6282.dtb.
    Installing new kirkwood-ts219-6282.dtb.
    flash-kernel: installing version 5.10.0-9-marvell
    Not enough space for kernel in MTD 'Kernel' (need 2448968 but is actually 2097152).
    run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
    dpkg: error processing package initramfs-tools (--configure):
     installed initramfs-tools package post-installation script subprocess returned error exit status 1
    Processing triggers for libgdk-pixbuf-2.0-0:armel (2.42.2+dfsg-1) ...
    Errors were encountered while processing:
     initramfs-tools
    needrestart is being skipped since dpkg has failed
    E: Sub-process /usr/bin/dpkg returned an error code (1)
    

    I tried to run your script in dry mode, but it failed because both fw_setenv and fw_printenv required -V (vs -v) to check the version. I updated the script and it succeeded:

        SUCCESS. You can reboot now.
    
        Notes:
        - Don't perform kernel or system update before the next reboot...
          so don't wait too long.
        - Consider compressing initrd with 'xz' to optimize the size with:
    
            echo "COMPRESS=xz" > /etc/initramfs-tools/conf.d/compress
    

    I thought rebooting would have failed at this point, so I tried to complete the upgrade by running apt full-upgrade once again, but I got the same error message:

    Not enough space for kernel in MTD 'Kernel' (need 2448968 but is actually 2097152).
    

    So, I rebooted and, as expected, it failed booting:

    ### Booting image at 00800000
    Bad Magic Number
    

    What can I do now? :-( I'm on a QNAP TS-221.

    Thanks in advance for any help you can provide.

    opened by lpaolini 18
  • TS-119P+: Failed: no information found with dmesg

    TS-119P+: Failed: no information found with dmesg

    Hi,

    I did the dry run and got the following:

    $ sudo ./qnap_mtd_resize.py --dry-run
    
    [Check of the QNAP model and see if supported]
    kirkwood-qnap: machine: QNAP TS219 family
    DTB file: kirkwood-ts219-6282.dtb
    Checking: flashcp -V
    Checking: flash_erase --version
    Using 'u-boot-tools' package
    
    [find on which MTD device partitions are currently mounted]
    Failed: no information found with dmesg
    

    I am currently running Buster. neofetch shows:

           _,met$$$$$gg.          user@localhost 
        ,g$$$$$$$$$$$$$$$P.       ------------- 
      ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 10 (buster) armv5tel 
     ,$$P'              `$$$.     Host: QNAP TS219 family 
    ',$$P       ,ggs.     `$$b:   Kernel: 4.19.0-20-marvell 
    `d$$'     ,$P"'   .    $$$    Uptime: 53 days, 21 hours, 56 mins 
     $$P      d$'     ,    $$P    Packages: 664 (dpkg) 
     $$:      $$.   -    ,d$$'    Shell: bash 5.0.3 
     $$;      Y$b._   _,d$P'      Terminal: /dev/pts/1 
     Y$$.    `.`"Y$$$$P"'         CPU: Feroceon 88FR131 rev 1 (v5l) (1) @ 2.000GHz 
     `$$b      "-.__              Memory: 114MiB / 501MiB 
      `Y$$
       `Y$$.                                              
         `$$b.
           `Y$$b.
              `"Y$b._
                  `"""
    
    opened by zoof 9
  • TS-421 dry run failed

    TS-421 dry run failed

    Hello@all

    The dry run on my ts-421 (debian) end with fails: root@Qnap-NAS:/home/Con# sudo ./qnap_mtd_resize.py --dry-run

    [Check of the QNAP model and see if supported] kirkwood-qnap: machine: QNAP TS419 family DTB file: kirkwood-ts419-6282.dtb Checking: flashcp -V Checking: flash_erase --version Using 'u-boot-tools' package

    [find on which MTD device partitions are currently mounted] Failed: no information found with dmesg root@Qnap-NAS:/home/Con#

    opened by Conan179 8
  • TS-219P+ - Resize corrupts uboot configuration

    TS-219P+ - Resize corrupts uboot configuration

    Discovered a problem when using qnap_mtd_resize.py at c9ccf4d4b6fe9802d6558b9a88609c68709b2ddf to upgrade my TS-219P+. This unit uses Debian Bullseye with the Buster kernel pinned as per the official release notes. The upgrade appeared to work correctly but when rebooting it failed to boot reporting "Bad Magic" and returning to the u-boot prompt.

    The log of the script runing follows:

    [Check of the QNAP model and see if supported]
    kirkwood-qnap: machine: QNAP TS219 family
    DTB file: kirkwood-ts219-6282.dtb
    Checking: flashcp -V
    Checking: flash_erase --version
    ici
    Using 'u-boot-tools' package
    
    [find on which MTD device partitions are currently mounted]
       spi0.0
    
    [Dump current U-boot config']
    Current U-boot bootcmd:
        cp.l 0xf8200000 0x800000 0x080000;cp.l 0xf8400000 0xa00000 0x240000;bootm 0x800000
    Current U-boot bootargs:
        console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=34816
    
    [Prepare new 'bootcmd']
       Old: cp.l 0xf8200000 0x800000 0x080000;cp.l 0xf8400000 0xa00000 0x240000;bootm 0x800000
       New: cp.l 0xf8100000 0x800000 0xc0000;cp.l 0xf8400000 0xb00000 0x300000;bootm 0x800000;echo Kernel_legacy layout fallback;bootm 0x900000
    
    [Prepare new 'bootargs']
       Old: console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=34816
       New: console=ttyS0,115200 root=/dev/ram initrd=0xb00000,0xc00000 ramdisk=34816 cmdlinepart.mtdparts="spi0.0:512k@0(uboot)ro,3M@0x100000(Kernel),12M@0x400000(RootFS1),2M@0x200000(Kernel_legacy),256k@0x80000(U-Boot Config),256k@0xc0000(NAS Config)" mtdparts="spi0.0:512k@0(uboot)ro,3M@0x100000(Kernel),12M@0x400000(RootFS1),2M@0x200000(Kernel_legacy),256k@0x80000(U-Boot Config),256k@0xc0000(NAS Config)"
    
    [Prepare fw_setenv script (/tmp/fw_setenv.script)]
    
    [Dump current 'NAS config' and 'Kernel' images]
    + cat /dev/mtd5
    [Resize 'NAS config' dump from 1280KB to 256KB.]
    + modprobe loop
    + losetup --show -f /tmp/mtd_nas_config.dump
    + loopdev=/dev/loop0
    + e2fsck -f -p -v /dev/loop0
    
              17 inodes used (13.28%, out of 128)
               2 non-contiguous files (11.8%)
               0 non-contiguous directories (0.0%)
                 # of inodes with ind/dind/tind blocks: 0/0/0
              51 blocks used (4.98%, out of 1024)
               0 bad blocks
               0 large files
    
               6 regular files
               2 directories
               0 character device files
               0 block device files
               0 fifos
               0 links
               0 symbolic links (0 fast symbolic links)
               0 sockets
    ------------
               8 files
    + e2fsck -f -p -v /dev/loop0
    
              17 inodes used (13.28%, out of 128)
               2 non-contiguous files (11.8%)
               0 non-contiguous directories (0.0%)
                 # of inodes with ind/dind/tind blocks: 0/0/0
              51 blocks used (4.98%, out of 1024)
               0 bad blocks
               0 large files
    
               6 regular files
               2 directories
               0 character device files
               0 block device files
               0 fifos
               0 links
               0 symbolic links (0 fast symbolic links)
               0 sockets
    ------------
               8 files
    + resize2fs /dev/loop0 128
    resize2fs 1.46.2 (28-Feb-2021)
    Resizing the filesystem on /dev/loop0 to 128 (1k) blocks.
    The filesystem on /dev/loop0 is now 128 (1k) blocks long.
    
    + losetup -d /dev/loop0
    
    [Concatenate first 256K of 'NAS config' with first 1MB of Kernel > /tmp/mtd_nas_config.new]
    
    [Prepare second 1MB of kernel tail > /tmp/mtd_kernel.tail]
    ------------------------------------------------------------
        !!!! Warning !!!!
    
        Everything is fine up to now.
        Next steps will write the flash and may be subject to failures.
        
        It is highly recommended to perform a MTD backup and save the files
        somewhere (USB device, PC)
        
            cat /dev/mtd0 > /tmp/mtd0.uboot.backup
            cat /dev/mtd1 > /tmp/mtd1.kernel.backup
            cat /dev/mtd2 > /tmp/mtd2.rootfs1.backup
            cat /dev/mtd3 > /tmp/mtd3.rootfs2.backup
            cat /dev/mtd4 > /tmp/mtd4.uboot-config.backup
            cat /dev/mtd5 > /tmp/mtd5.nas-config.backup
            fw_printenv -c /tmp/fw_env.config  > /tmp/uboot_config.backup.txt
            cd /tmp
            tar cvzf mtd_backup.tgz mtd?.*.backup uboot_config.backup.txt
            
            # now use scp / sftp to push/pull mtd_backup.tgz on another PC.
        
        Be sure you will not cut the power until the end of operations.
        In case of failure, you way need to recover with a Serial Console 
        to run U-boot commands
        
            https://www.cyrius.com/debian/kirkwood/qnap/ts-219/serial/
        
    Continue and flash the new partitions ? (y/N)
    y
    
    [Flash 'NAS config' partition content (ie 'NAS config' + head of Kernel) (still a 'safe' op)]
    + flashcp -v /tmp/mtd_nas_config.new /dev/mtd5
    Erasing blocks: 5/5 (100%)
    Writing data: 1280k/1280k (100%)
    Verifying data: 1280k/1280k (100%)
    
    [Change U-boot config with new values)]
    + fw_setenv -c /tmp/fw_env.config -s /tmp/fw_setenv.script
    
    [Flash tail of the kernel in old 'Kernel' Partition]
    + flashcp -v /tmp/mtd_kernel.tail /dev/mtd1
    Erasing blocks: 4/4 (100%)
    Writing data: 1024k/1024k (100%)
    Verifying data: 1024k/1024k (100%)
    ------------------------------------------------------------
    
        SUCCESS. 
    
        Now, REBOOT !
        
        Notes: 
        - DO NOT PERFORM A KERNEL OR SYSTEM UPDATE before the next reboot !... 
          so don't wait too long.
        - Consider compressing initrd with 'xz' to optimize the size with:
        
            echo "COMPRESS=xz" > /etc/initramfs-tools/conf.d/compress
    
        
    

    I have a serial console connected so was able to figure out what was happening and temporarily change the bootcmd and bootargs to what the script said they should be and the machine started up.

    This was my original configuration: uboot_config.backup.txt

    The failing configuration looked like this: qnap_mtd_resize-post-run-config-2021-12-21.txt

    I was able to permanently fix the config using fw_setenv after boot so it looks like: fixed-uboot-config-2021-12-21.txt. This now reboots cleanly and I was able to upgrade to the newer Bullseye 5.10 kernel and reboot successfully. Thanks!

    opened by davefiddes 8
  • TS-119 - 'bootcmd' for this model.

    TS-119 - 'bootcmd' for this model.

    Could this script be used with the QNAP TS-119?

    I get the following error:

    ~# ./qnap_mtd_resize.py --dry-run
    [Check of the QNAP model and see if supported]
    kirkwood-qnap: machine: QNAP TS219 family
    DTB file: kirkwood-ts219-6281.dtb
    Checking: flashcp -V
    Checking: flash_erase --version
    Using 'libubootenv-tool' package
    
    [find on which MTD device partitions are currently mounted]
       spi0.0
    
    [Dump current U-boot config']
    Current U-boot bootcmd:
        cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000
    Current U-boot bootargs:
        console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=32768
    
    [Prepare new 'bootcmd']
    "'cp.l 0xf8200000 0x800000 0x0*80000' not found in 'cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000'"
    Don't know how to patch 'bootcmd' for this model. Please report this log.
    

    Any hints?

    For reference:

    ~# cat /proc/mtd
    dev:    size   erasesize  name
    mtd0: 00080000 00040000 "U-Boot"
    mtd1: 00200000 00040000 "Kernel"
    mtd2: 00900000 00040000 "RootFS1"
    mtd3: 00300000 00040000 "RootFS2"
    mtd4: 00040000 00040000 "U-Boot Config"
    mtd5: 00140000 00040000 "NAS Config"
    

    And:

    ~# fw_printenv -c fw_env.config
    ASset=min
    MALLOC_len=1
    autoload=no
    baudrate=115200
    bootargs=console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=32768
    bootargs_end=:::DB88FXX81:eth0:none
    bootargs_root=root=/dev/nfs rw
    bootcmd=cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000
    bootdelay=3
    bootp_vendor_class=F_TS-119
    console=console=ttyS0,115200 mtdparts=cfi_flash:0xf40000(root),0xc0000(uboot)ro
    disL2Cache=no
    disL2Prefetch=yes
    disaMvPnp=no
    enaAutoRecovery=yes
    enaCpuStream=no
    enaDCPref=yes
    enaICPref=yes
    enaMonExt=no
    enaWrAllo=no
    ethact=egiga0
    ethaddr=00:08:XX:XX:XX:XX
    ethprime=egiga0
    fileaddr=A00000
    filesize=36464c
    image_name=uImage
    ipaddr=172.17.20.240
    loadaddr=0x02000000
    loads_echo=0
    mainlineLinux=no
    mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
    mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxo
    netbsd_en=no
    netmask=255.255.254.0
    netretry=no
    pexMode=RC
    rcvrip=169.254.100.100
    rootpath=/mnt/ARM_FS/
    sata_dma_mode=yes
    serverip=172.17.20.5
    setL2CacheWT=yes
    standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
    stderr=serial
    stdin=serial
    stdout=serial
    update=tftp 0x800000 uImage; tftp 0xa00000 rootfs.gz;bootm 0x800000
    usb0Mode=host
    vxworks_en=no
    yuk_ethaddr=00:00:00:EE:51:81
    
    opened by j1o1a 7
  • TS419P After recovery reinstallation

    TS419P After recovery reinstallation

    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.dtb
    Partition 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 -V
    Checking: flash_erase --version
    Using '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 0x900000
    Current U-boot bootargs:
        console=ttyS0,115200 root=/dev/ram initrd=0xb00000,0xc00000 ramdisk=32768 cmdlinepart.mtdparts="spi0.0:512k@0(uboot)ro,3M@0x100000(Kernel),12M@0x400000(RootFS1),2M@0x200000(Kernel_legacy),256k@0x80000(U-Boot Config),256k@0xc0000(NAS Config)" mtdparts="spi0.0:512k@0(uboot)ro,3M@0x100000(Kernel),12M@0x400000(RootFS1),2M@0x200000(Kernel_legacy),256k@0x80000(U-Boot Config),256k@0xc0000(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.

    opened by lapourgagner 6
  • Question about recovery mode after mtd layout changes

    Question about recovery mode after mtd layout changes

    Given https://github.com/amouiche/qnap_mtd_resize_for_bullseye/issues/20#issuecomment-1063757818, 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
    
    opened by TBBle 4
  • Debian Buster installer on modified mtd partitions

    Debian Buster installer on modified mtd partitions

    Hi Arnaud,

    I've successfully updated a TS-219p and a TS-221 using your script, so thanks again! Now, how can I build a Debian buster installer image for the new partition table?

    I tried different methods, but with no success.

    Method 1:

    1. downloaded kernel-6281 (on TS-219p) and padded it to 3MB with truncate -s 3145728 kernel-6281
    2. downloaded initrd and padded it to 12MB with truncate -s 12582912 initrd
    3. created an image with cat /dev/mtd0 /dev/mtd4 /dev/mtd5 kernel-6281 initrd > debian_buster_installer

    Method 2:

    1. downloaded kernel-6281 (on TS-219p) and padded it to 2MB with truncate -s 2097152 kernel-6281
    2. downloaded initrd and padded it to 12MB with truncate -s 12582912 initrd
    3. copied the padded kernel to "Kernel_legacy" partition with cp kernel-6281 /dev/mtd3
    4. copied the padded initrd to "RootFS1" partition with cp initrd /dev/mtd2
    5. created an image with cat /dev/mtd0 /dev/mtd4 /dev/mtd5 /dev/mtd1 /dev/mtd2 > debian_buster_installer

    Obviously I'm doing something wrong, as they both fail the CRC check (Bad magic number) while trying to boot.

    Any ideas? Thanks, Luca

    opened by lpaolini 4
  • Manual partition migration

    Manual partition migration

    Hi, I have a QNAP TS-221P running Debian 11 thanks to your script (and some manual intervention) and everything works like a charm.

    Now I'm upgrading my disks, manually degrading the RAID-1 to rebuild the two volumes one at a time.

    At the end of the process, the old disks will be installed on another QNAP, a TS-219P, whose partitions have not been updated to fit Debian 11 yet.

    My plan is to install the old disks into the TS-219P, boot the existing kernel (from previously installed Debian 10), and run flash-kernel for flashing the new kernel.

    Before that I would need to update partition table though. Can you help me with the the necessary steps to achieve the same result as running your script but running U-Boot commands instead?

             __  __                      _ _
            |  \/  | __ _ _ ____   _____| | |
            | |\/| |/ _` | '__\ \ / / _ \ | |
            | |  | | (_| | |   \ V /  __/ | |
            |_|  |_|\__,_|_|    \_/ \___|_|_|
     _   _     ____              _
    | | | |   | __ )  ___   ___ | |_
    | | | |___|  _ \ / _ \ / _ \| __|
    | |_| |___| |_) | (_) | (_) | |_
     \___/    |____/ \___/ \___/ \__|  ** LOADER **
     ** MARVELL BOARD: DB-88F6281A-BP LE
    
    U-Boot 1.1.4 (Apr 23 2009 - 19:01:28) Marvell version: 3.4.4
    
    U-Boot code: 00600000 -> 0067FFF0  BSS: -> 00690DCC
    
    Soc: 88F6281 A0 (DDR2)
    CPU running @ 1200Mhz L2 running @ 400Mhz
    SysClock = 400Mhz , TClock = 200Mhz
    
    DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
    DRAM CS[0] base 0x00000000   size 256MB
    DRAM CS[1] base 0x10000000   size 256MB
    DRAM Total size 512MB  16bit width
    [16384kB@f8000000] Flash: 16 MB
    Addresses 8M - 0M are saved for the U-Boot usage.
    Mem malloc Initialization (8M - 7M): Done
    
    CPU : Marvell Feroceon (Rev 1)
    
    Streaming disabled
    Write allocate disabled
    
    
    USB 0: host mode
    PCI 0: PCI Express Root Complex Interface
    PEX interface detected Link X1
    Net:   egiga0 [PRIME]
    Hit any key to stop autoboot:  0
    QNAP: Recovery Button pressed: 0
    Marvell>>
    Marvell>>
    Marvell>> printenv
    baudrate=115200
    loads_echo=0
    rootpath=/mnt/ARM_FS/
    console=console=ttyS0,115200 mtdparts=cfi_flash:0xf40000(root),0xc0000(uboot)ro
    CASset=min
    MALLOC_len=1
    ethprime=egiga0
    bootargs_root=root=/dev/nfs rw
    bootargs_end=:::DB88FXX81:eth0:none
    image_name=uImage
    standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
    ethaddr=00:00:00:00:05:09
    mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxo
    mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
    usb0Mode=host
    yuk_ethaddr=00:00:00:EE:51:81
    netretry=no
    rcvrip=169.254.100.100
    loadaddr=0x02000000
    autoload=no
    ethact=egiga0
    update=tftp 0x800000 uImage; tftp 0xa00000 rootfs.gz;bootm 0x800000
    filesize=36464c
    fileaddr=A00000
    bootcmd=cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000
    ipaddr=172.17.21.248
    serverip=172.17.21.7
    netmask=255.255.254.0
    bootargs=console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=32768
    bootp_vendor_class=F_TS-219PE
    stdin=serial
    stdout=serial
    stderr=serial
    mainlineLinux=no
    enaMonExt=no
    enaCpuStream=no
    enaWrAllo=no
    pexMode=RC
    disL2Cache=no
    setL2CacheWT=yes
    disL2Prefetch=yes
    enaICPref=yes
    enaDCPref=yes
    sata_dma_mode=yes
    netbsd_en=no
    vxworks_en=no
    bootdelay=3
    disaMvPnp=no
    enaAutoRecovery=yes
    
    Environment size: 1331/4092 bytes
    
    opened by lpaolini 4
  • TS212P - problem with qnap_mtd_resize

    TS212P - problem with qnap_mtd_resize

    I am using a TS-212P with Debian Stretch installed. I would like to install Debian Bullseye using the qnap_mtd_resiz.py script but I always get errors. If I use Python 3.5.3 I get

    File "qnap_mtd_resize.py", line 95 Raise KeyError(f"No mtd '{name}' device found.") Syntax error: invalid syntax

    If I use Python 3.9.4 I get

    kirkwood-qnap: machine:QNAP TS219 family DTB file: kirkwood-ts219-6282.dtb Checking: /sbin/flashcp -V Checking: /sbin/flash_erase --version Checking: /usr/bin/fw_setenv -v /usr/bin/fw_setenv: invalid option -- 'v' Usage: fw_setenv [OPTIONS]... [VARIABLE]... Modify variables in U-Boot environment ecc... ecc...

    any suggestions?

    opened by giallino64 3
  • Record successful test with my QNAP TS-419P

    Record successful test with my QNAP TS-419P

    It booted back up okay, but I haven't yet done the upgrade to bullseye. I also had earlier XZ-compressed by initrd from the instructions here because after the upgrade to buster, the initrd image was slightly too large.

    Anyway, thank you for this tool, particularly since Buster didn't get LTS support for the QNAP Kirkwood NASes, and Stretch LTS ended two months ago.

    opened by TBBle 2
  • Why? (Really, hear me out.)

    Why? (Really, hear me out.)

    I currently run Bullseye with a Buster kernel on ye olde QNAP TS119. And after having a kernel clusterf*ck of my own design (kernel in flash older than kernel on disk) I started to wonder if having the kernel image in flash is absolutely necessary.

    The kernel is expected to keep growing in size and eventually it won't fit in the resized mtdblock anymore anyway. I also had the experience in the past that (unchanged) images were flashed waaay to often. (I had it triggered when simply doing a minor upgrade of Python 2.x.) The kernel in flash is also not self-contained like the QNAP firmware itself. (At least the old version as I only used it for a short period many years ago.) It still needs the kernel modules on disk. Meanwhile the /boot area appears to be used only for staging when building new flash files.

    So why not go the way of the Odroid and flash Petitboot instead of a patched kernel? (mkimage and injecting dtb) Looking at some image sizes the total is always less than 9M. That is for an arm64 Odroid HC4, a stripped armel build is expected to be way smaller.

    And even if you could flash a Bullseye, or larger, kernel or go with Petitboot instead ... Is it worth it in terms of performance and security?

    opened by killemov 3
  • reverting changes

    reverting changes

    I used this script to change partition layout on my TS-421 but now I decided to sell it so I'd like to install QTS on it. I was able to do that using recovery via tftp and it went fine. However updating to newer firmware fails and I believe this is due to changed partition layout. So the question is how to revert it safely?

    I have backup of mdt files before I run your script.

    opened by fenio 3
  • Has anyone generated (unofficial) Debian Installer Bullseye builds?

    Has anyone generated (unofficial) Debian Installer Bullseye builds?

    I'm about to give away my old TS-419P, and since I have run this script successfully, I thought the best state to leave it in would be to have the Debian Installer pre-flashed (so I can secure-erase the drives, and still leave it bootable with the new partition layout, to avoid leaving the new user to hit https://github.com/amouiche/qnap_mtd_resize_for_bullseye/issues/20#issuecomment-1063757818 when they try to install Debian or something).

    I was going to follow the simple procedure at https://github.com/amouiche/qnap_mtd_resize_for_bullseye/issues/20#issuecomment-1061510263, but I was wondering before I do that if anyone has built appropriate d-i kernel and initrd, or if I should just flash https://ftp.debian.org/debian/dists/buster/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-41x/ and let the next user install buster and then upgrade.

    opened by TBBle 0
  • Success on QNAP TS-119

    Success on QNAP TS-119

    Unfortunately it's placed remotely so I don't know if its a TS-119 or a 119P+.

    The output of cat /sys/firmware/devicetree/base/model is QNAP TS219 family. The dtb is kirkwood-ts219-6281.dtb.

    I had already upgraded to bullseye before finding your script so --dry-run gave an error that fw_setenv was missing, but after downgrading u-boot-tools to the buster version (which has fw_setenv) --dry-run went fine and after that everything was smooth.

    Thanks a lot for giving my little companion new life. But now it seems appropriate to find a successor after 10+ years!

    opened by bjohv052 1
  • Successful with QNAP TS-112P.

    Successful with QNAP TS-112P.

    Successful with QNAP TS-112P. The script works without any problems and I was able to install Bullseye with the new kernel. Thanks for your work. Log:

    [Check of the QNAP model and see if supported]
    kirkwood-qnap: machine: QNAP TS219 family
    DTB file: kirkwood-ts219-6281.dtb
    Checking: flashcp -V
    Checking: flash_erase --version
    Using 'libubootenv-tool' 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 0xf8200000 0x800000 0x80000;cp.l 0xf8400000 0xa00000 0x240000;bootm 0x800000
    Current U-boot bootargs:
        console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=34816
    
    [Prepare new 'bootcmd']
       Old: uart1 0x68;cp.l 0xf8200000 0x800000 0x80000;cp.l 0xf8400000 0xa00000 0x240000;bootm 0x800000
       New: uart1 0x68;cp.l 0xf8100000 0x800000 0xc0000;cp.l 0xf8400000 0xb00000 0x300000;bootm 0x800000;echo Kernel_legacy layout fallback;bootm 0x900000
    
    [Prepare new 'bootargs']
       Old: console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=34816
       New: console=ttyS0,115200 root=/dev/ram initrd=0xb00000,0xc00000 ramdisk=34816 cmdlinepart.mtdparts=spi0.0:512k@0(uboot)ro,3M@0x100000(Kernel),12M@0x400000(RootFS1),2M@0x200000(Kernel_legacy),256k@0x80000(U-Boot_Config),256k@0xc0000(NAS_Config) mtdparts=spi0.0:512k@0(uboot)ro,3M@0x100000(Kernel),12M@0x400000(RootFS1),2M@0x200000(Kernel_legacy),256k@0x80000(U-Boot_Config),256k@0xc0000(NAS_Config)
    
    [Prepare fw_setenv script (/tmp/fw_setenv.script)]
    
    [Dump current 'NAS config' and 'Kernel' images]
    + cat /dev/mtd5
    [Resize 'NAS config' dump from 1280KB to 256KB.]
    + modprobe loop
    + losetup --show -f /tmp/mtd_nas_config.dump
    + loopdev=/dev/loop0
    + e2fsck -f -p -v /dev/loop0
    
              17 inodes used (13.28%, out of 128)
               0 non-contiguous files (0.0%)
               0 non-contiguous directories (0.0%)
                 # of inodes with ind/dind/tind blocks: 0/0/0
              50 blocks used (4.88%, out of 1024)
               0 bad blocks
               0 large files
    
               6 regular files
               2 directories
               0 character device files
               0 block device files
               0 fifos
               0 links
               0 symbolic links (0 fast symbolic links)
               0 sockets
    ------------
               8 files
    + e2fsck -f -p -v /dev/loop0
    
              17 inodes used (13.28%, out of 128)
               0 non-contiguous files (0.0%)
               0 non-contiguous directories (0.0%)
                 # of inodes with ind/dind/tind blocks: 0/0/0
              50 blocks used (4.88%, out of 1024)
               0 bad blocks
               0 large files
    
               6 regular files
               2 directories
               0 character device files
               0 block device files
               0 fifos
               0 links
               0 symbolic links (0 fast symbolic links)
               0 sockets
    ------------
               8 files
    + resize2fs /dev/loop0 128
    resize2fs 1.46.2 (28-Feb-2021)
    Resizing the filesystem on /dev/loop0 to 128 (1k) blocks.
    The filesystem on /dev/loop0 is now 128 (1k) blocks long.
    
    + losetup -d /dev/loop0
    
    [Concatenate first 256K of 'NAS config' with first 1MB of Kernel > /tmp/mtd_nas_config.new]
    
    [Prepare second 1MB of kernel tail > /tmp/mtd_kernel.tail]
    ------------------------------------------------------------
        !!!! Warning !!!!
    
        Everything is fine up to now.
        Next steps will write the flash and may be subject to failures.
    
        It is highly recommended to perform a MTD backup and save the files
        somewhere (USB device, PC)
    
            cat /dev/mtd0 > /tmp/mtd0.uboot.backup
            cat /dev/mtd1 > /tmp/mtd1.kernel.backup
            cat /dev/mtd2 > /tmp/mtd2.rootfs1.backup
            cat /dev/mtd3 > /tmp/mtd3.rootfs2.backup
            cat /dev/mtd4 > /tmp/mtd4.uboot-config.backup
            cat /dev/mtd5 > /tmp/mtd5.nas-config.backup
            fw_printenv -c /tmp/fw_env.config  > /tmp/uboot_config.backup.txt
            cd /tmp
            tar cvzf mtd_backup.tgz mtd?.*.backup uboot_config.backup.txt
    
            # now use scp / sftp to push/pull mtd_backup.tgz on another PC.
    
        Be sure you will not cut the power until the end of operations.
        In case of failure, you way need to recover with a Serial Console
        to run U-boot commands
    
            https://www.cyrius.com/debian/kirkwood/qnap/ts-219/serial/
    
    Continue and flash the new partitions ? (y/N)
    Note: You are using --dry-run option. No flash operations will be performed if you answer 'y'.
    y
    
    [Flash 'NAS config' partition content (ie 'NAS config' + head of Kernel) (still a 'safe' op)]
    (Dry run)
    + flashcp -v /tmp/mtd_nas_config.new /dev/mtd5
    
    [Change U-boot config with new values)]
    (Dry run)
    + fw_setenv -c /tmp/fw_env.config -s /tmp/fw_setenv.script
    
    [Flash tail of the kernel in old 'Kernel' Partition]
    (Dry run)
    + flashcp -v /tmp/mtd_kernel.tail /dev/mtd1
    
    [Make a copy of /tmp/fw_env.config into /etc/fw_env.config (if not already existing)]
    ------------------------------------------------------------
    
        SUCCESS.
    
        Now, REBOOT !
    
        Notes:
        - DO NOT PERFORM A KERNEL OR SYSTEM UPDATE before the next reboot !...
          so don't wait too long.
        - Consider compressing initrd with 'xz' to optimize the size with:
    
            echo "COMPRESS=xz" > /etc/initramfs-tools/conf.d/compress
    
    
    opened by krcs 0
  • Successful with QNAP TS-412. Logs included.

    Successful with QNAP TS-412. Logs included.

    root@NASC8F1EC:/tmp# cat /proc/mtd dev: size erasesize name mtd0: 00080000 00040000 "U-Boot" mtd1: 00200000 00040000 "Kernel" mtd2: 00900000 00040000 "RootFS1" mtd3: 00300000 00040000 "RootFS2" mtd4: 00040000 00040000 "U-Boot Config" mtd5: 00140000 00040000 "NAS Config" root@NASC8F1EC:/tmp# python3 qnap_mtd_resize.py

    [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.

    Checking: flashcp -V Checking: flash_erase --version Using '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 0xf8200000 0x800000 0x80000;cp.l 0xf8400000 0xa00000 0x240000;bootm 0x800000 Current U-boot bootargs: console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=34816

    [Prepare new 'bootcmd'] Old: uart1 0x68;cp.l 0xf8200000 0x800000 0x80000;cp.l 0xf8400000 0xa00000 0x240000;bootm 0x800000 New: uart1 0x68;cp.l 0xf8100000 0x800000 0xc0000;cp.l 0xf8400000 0xb00000 0x300000;bootm 0x800000;echo Kernel_legacy layout fallback;bootm 0x900000

    [Prepare new 'bootargs'] Old: console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=34816 New: console=ttyS0,115200 root=/dev/ram initrd=0xb00000,0xc00000 ramdisk=34816 cmdlinepart.mtdparts=spi0.0:512k@0(uboot)ro,3M@0x100000(Kernel),12M@0x400000(RootFS1),2M@0x200000(Kernel_legacy),256k@0x80000(U-Boot_Config),256k@0xc0000(NAS_Config) mtdparts=spi0.0:512k@0(uboot)ro,3M@0x100000(Kernel),12M@0x400000(RootFS1),2M@0x200000(Kernel_legacy),256k@0x80000(U-Boot_Config),256k@0xc0000(NAS_Config)

    [Prepare fw_setenv script (/tmp/fw_setenv.script)]

    [Dump current 'NAS config' and 'Kernel' images]

    • cat /dev/mtd5 [Resize 'NAS config' dump from 1280KB to 256KB.]

    • modprobe loop

    • losetup --show -f /tmp/mtd_nas_config.dump

    • loopdev=/dev/loop0

    • e2fsck -f -p -v /dev/loop0

          18 inodes used (14.06%, out of 128)
           2 non-contiguous files (11.1%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
          55 blocks used (5.37%, out of 1024)
           0 bad blocks
           0 large files
      
           7 regular files
           2 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
      

           9 files
    
    • true

    • e2fsck -f -p -v /dev/loop0

          18 inodes used (14.06%, out of 128)
           2 non-contiguous files (11.1%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
          55 blocks used (5.37%, out of 1024)
           0 bad blocks
           0 large files
      
           7 regular files
           2 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
      

           9 files
    
    • resize2fs /dev/loop0 128 resize2fs 1.44.5 (15-Dec-2018) Resizing the filesystem on /dev/loop0 to 128 (1k) blocks. The filesystem on /dev/loop0 is now 128 (1k) blocks long.

    • losetup -d /dev/loop0

    [Concatenate first 256K of 'NAS config' with first 1MB of Kernel > /tmp/mtd_nas_config.new]

    [Prepare second 1MB of kernel tail > /tmp/mtd_kernel.tail]

    !!!! Warning !!!!
    
    Everything is fine up to now.
    Next steps will write the flash and may be subject to failures.
    
    It is highly recommended to perform a MTD backup and save the files
    somewhere (USB device, PC)
    
        cat /dev/mtd0 > /tmp/mtd0.uboot.backup
        cat /dev/mtd1 > /tmp/mtd1.kernel.backup
        cat /dev/mtd2 > /tmp/mtd2.rootfs1.backup
        cat /dev/mtd3 > /tmp/mtd3.rootfs2.backup
        cat /dev/mtd4 > /tmp/mtd4.uboot-config.backup
        cat /dev/mtd5 > /tmp/mtd5.nas-config.backup
        fw_printenv -c /tmp/fw_env.config  > /tmp/uboot_config.backup.txt
        cd /tmp
        tar cvzf mtd_backup.tgz mtd?.*.backup uboot_config.backup.txt
        
        # now use scp / sftp to push/pull mtd_backup.tgz on another PC.
    
    Be sure you will not cut the power until the end of operations.
    In case of failure, you way need to recover with a Serial Console 
    to run U-boot commands
    
        https://www.cyrius.com/debian/kirkwood/qnap/ts-219/serial/
    

    Continue and flash the new partitions ? (y/N) y

    [Flash 'NAS config' partition content (ie 'NAS config' + head of Kernel) (still a 'safe' op)]

    • flashcp -v /tmp/mtd_nas_config.new /dev/mtd5 Erasing blocks: 5/5 (100%) Writing data: 1280k/1280k (100%) Verifying data: 1280k/1280k (100%)

    [Change U-boot config with new values)]

    • fw_setenv -c /tmp/fw_env.config -s /tmp/fw_setenv.script

    [Flash tail of the kernel in old 'Kernel' Partition]

    • flashcp -v /tmp/mtd_kernel.tail /dev/mtd1 Erasing blocks: 4/4 (100%) Writing data: 1024k/1024k (100%) Verifying data: 1024k/1024k (100%)

    [Make a copy of /tmp/fw_env.config into /etc/fw_env.config (if not already existing)]

    SUCCESS. 
    
    Now, REBOOT !
    
    Notes: 
    - DO NOT PERFORM A KERNEL OR SYSTEM UPDATE before the next reboot !... 
      so don't wait too long.
    - Consider compressing initrd with 'xz' to optimize the size with:
    
        echo "COMPRESS=xz" > /etc/initramfs-tools/conf.d/compress
    

    root@NASC8F1EC:/tmp# cat /proc/mtd dev: size erasesize name mtd0: 00080000 00040000 "U-Boot" mtd1: 00200000 00040000 "Kernel" mtd2: 00900000 00040000 "RootFS1" mtd3: 00300000 00040000 "RootFS2" mtd4: 00040000 00040000 "U-Boot Config" mtd5: 00140000 00040000 "NAS Config" root@NASC8F1EC:/tmp# shutdown -r now root@NASC8F1EC:/tmp# Connection to 10.180.100.106 closed by remote host. Connection to 10.180.100.106 closed. Xxxx ~ % ssh [email protected] [email protected]'s password: Linux NASC8F1EC 4.19.0-20-marvell #1 Debian 4.19.235-1 (2022-03-17) armv5tel

    The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Jun 14 22:33:24 2022 from 10.180.51.104 root@NASC8F1EC:~# cat /proc/mtd 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"

    opened by fadlytabrani 1
Owner
Arnaud Mouiche
Arnaud Mouiche
Change ACLs for QNAP LXD unprivileged container.

qnaplxdunpriv If Advanced Folder Permissions is enabled in QNAP NAS, unprivileged LXD containers won't start. qnaplxdunpriv changes ACLs of some Conta

null 1 Jan 10, 2022
Resizing using nnedi3/znedi3/nnedi3cl with center alignment and correct chroma placement

nnedi3_resample A VapourSynth script for easy resizing using nnedi3/znedi3/nnedi3cl with center alignment and correct chroma placement. Requirements n

Home Of VapourSynth Evolution 12 Sep 8, 2022
MIB2 STD ZR Firmware Upgrade

Upgrade MIB2 STD ZR Firmware (without Navigation) About This repository contains some scripts and documentation how to upgrade the MIB2 firmware to a

Fabian 18 Dec 29, 2022
BestBuy Script Designed to purchase any item when it becomes available.

prerequisites: Selnium; undetected-chromedriver. This Script is designed to order an Item provided a link from BestBuy.com only.

Bransen Smith 0 Jan 12, 2022
Islam - This is a simple python script.In this script I have written all the suras of Al Quran. As a result, by using this script, you can know the number of any sura at the moment.

Introduction: If you want to know sura number of al quran by just typing the name of sura than you can use this script. Usage in termux: $ pkg install

Fazle Rabbi 1 Jan 2, 2022
tidevice can be used to communicate with iPhone device

h 该工具能够用于与iOS设备进行通信, 提供以下功能 截图 获取手机信息 ipa包的安装和卸载 根据bundleID 启动和停止应用 列出安装应用信息 模拟Xcode运行XCTest,常用的如启动WebDriverAgent测试

Alibaba 1.8k Dec 30, 2022
Simple utlity for sniffing decrypted HTTP/HTTPS traffic on a jailbroken iOS device into an HAR format.

Description iOS devices contain a hidden feature for sniffing decrypted HTTP/HTTPS traffic from all processes using the CFNetwork framework into an HA

null 83 Dec 25, 2022
AndroidEnv is a Python library that exposes an Android device as a Reinforcement Learning (RL) environment.

AndroidEnv is a Python library that exposes an Android device as a Reinforcement Learning (RL) environment.

DeepMind 814 Dec 26, 2022
An AI-powered device to stop people from stealing my packages.

Package Theft Prevention Device An AI-powered device to stop people from stealing my packages. Installation To install on a raspberry pi, clone the re

rydercalmdown 157 Nov 24, 2022
Easily map device and application controls to a midi controller

pymidicontroller Introduction Easily map device and application controls to a midi controller

Tane Barriball 24 May 16, 2022
Simple Python-based web application to allow UGM students to fill their QR presence list without having another device in hand.

Praesentia Praesentia is a simple Python-based web application to allow UGM students to fill their QR presence list without having another device in h

loncat 20 Sep 29, 2022
This application demonstrates IoTVAS device discovery and security assessment API integration with the Rapid7 InsightVM.

Introduction This repository hosts a sample application that demonstrates integrating Firmalyzer's IoTVAS API with the Rapid7 InsightVM platform. This

Firmalyzer BV 4 Nov 9, 2022
CDM Device Checker for python

CDM Device Checker for python

zackmark29 79 Dec 14, 2022
Easy installer for running Amazon AVS Device SDK on Raspberry Pi

avs-device-sdk-pi Scripts to enable Alexa voice activation using Picovoice Porcupine If you like the work, find it useful and if you would like to get

null 4 Nov 14, 2022
Turn a raspberry pi into a Bluetooth Midi device

PiBluetoothMidSetup This will change serveral system wide packages/configurations Do not run this on your primary machine or anything you don't know h

MyLab6 40 Sep 19, 2022
A web UI for managing your 351ELEC device ROMs.

351ELEC WebUI A web UI for managing your 351ELEC device ROMs. Requirements Python 3 or Python 2.7 are required. If the ftfy package is installed, it w

Ben Phelps 5 Sep 26, 2022
Plugin to manage site, circuit and device diagrams and documents in Netbox

Netbox Documents Plugin A plugin designed to faciliate the storage of site, circuit and device specific documents within NetBox Note: Netbox v3.2+ is

Jason Yates 38 Dec 24, 2022
HPomb Is Socail Engineering Tool , Used For Bombing , Spoofing and Anonymity Available For Linux And Android(Termux)

HPomb v2020.02 Coming Soon Created By Secanonm HPomb Is Socail Engineering Tool , Used For Bombing , Spoofing and Anonymity Available For Linux And An

Secanonm 10 Jul 25, 2022
Check if Python package names are available on PyPI.

?? isavailable Can I haz this Python package on PyPI? Check if Python package names are available on PyPI. Usage $ isavailable checks whether your des

Felipe S. S. Schneider 3 May 18, 2022