On Tue, Apr 16, 2019 at 5:04 PM Martin Michlmayr <[email protected]> wrote:
> 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
