With Debian on the QNAP, the Debian kernel and ramdisk are stored in
flash and not on the disk, so MBR vs GPT doesn't really matter (u-boot
won't access the disk anyway).
Martin, thanks a lot for the information! This is very good news and simplifies a lot the process.
But I am also puzzled...
Generally, when moving disks on QNAP systems, you have to be aware
that we put some disk information into the ramdisk (since you cannot
pass a root= paramter via the command line easily). In most cases,
this is the UUID= from /etc/fstab.
I cannot remember how this is done for RAIDs. Maybe we just use
/dev/md1 in that case.
...in my /etc/fstab I have:
----
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/mapper/vg00-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/md0 during installation
UUID=8ecca189-7483-4324-8de2-13f6a5ad7a8b /boot ext2 defaults 0 2
/dev/mapper/vg00-home /home ext4 defaults 0 2
/dev/mapper/vg00-swap none swap sw 0 0
----
and UUID=8ecca189-7483-4324-8de2-13f6a5ad7a8b (boot) is /dev/md0. All seems correct. But the system won't boot from the second 6TB disk alone - the one with GPT.
Maybe initrd.img is not updated and I just need to execute "update-initramfs"? I expect that I don't have to manually change initrd.img...
I'm very cautious in these steps because, as you know, it's not straightforward to fix a non-booting QNAP :-)
Best,
Emanuele