Success on QNAP TS-119
Opened this issue · 1 comments
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!
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.