amouiche / qnap_mtd_resize_for_bullseye

Script for resizing MTD partitions on a QNAP device in order to be able to upgrade from buster to bullseye
GNU General Public License v2.0
51 stars 11 forks source link

Success on QNAP TS-119 #28

Open bjohv052 opened 1 year ago

bjohv052 commented 1 year ago

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!

killemov commented 1 year ago

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

AFAIK the only difference is the case or housing, the thing you look at. The 119P+ has a fan and a hotswap drive bay.

I'm running a hybrid Bullseye with a Buster kernel. Is it worth it to have a Bullseye kernel on this old device?

After a horrible kernel mishap on my end I ended up with a 4.19.0.18 in flash memory and ONLY 4.19.0.21 on disk. This would hardly be a problem were it not that they are not compatible (21 kernel modules can not be loaded into a 18 kernel) AND the gods at Debian decided to purge many old kernel packages. If the kernel modules can't be loaded there is no networking, so I needed to go the serial-interface route. Also the mtd devices (flash blocks) are not available so I can't flash anything. Long story short, I ended up booting the Debian installer from TFTP in U-Boot and doing a minimal install of 4.19.0.21 on a spare drive, just to get that version flashed. Then changing the UUID of the original root partition matching the new install it finally worked.

My point: Why flash the kernel and initrd when it's not self-contained anyway? I have been thinking about flashing Petitboot instead and never flash a kernel again.

The origin of the kernel mishap was disabling flash-kernel because it was flashing images waaaaay to often in the past.