[Linuxtrent] Re: Sostituzione disco RAID1+LVM e allargamento di una partizione: da DOS a GPT?
- From: Emanuele Olivetti <emanuele@xxxxxxxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Wed, 17 Apr 2019 10:55:44 +0200
On 10/04/19 23:59, Emanuele Olivetti wrote:
[...]
Ne deduco che, se /dev/sda ora ha uno schema delle partizioni DOS/MBR e non
GPT, non potrò allargare i volumi RAID1/LVM oltre i 2TB, giusto? Se si, come
dovrei fare per rifare le partizioni con GPT nel modo corretto? Non devo usare
sfsdisk?
Rispondo qui con alcuni elementi nuovi sulla faccenda. Ho scritto in mailing
list [debian-arm] della mia questione, visto che alla fine il dubbio su tutto
quanto riguarda l'interzione tra U-boot, GPT e RAID1+LVM. Mi ha risposto Martin
Michlmayr, che è proprio la persona che cura il supporto Debian per QNAP (
https://www.cyrius.com/debian/kirkwood/qnap/):
---
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).
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.
---
Questa è un'ottima notizia e, in sintesi, il problema che mi ponevo non è un
problema: indipendentemente dal fatto che io usi MBR o GPT, o che sia o meno
RAID1+LVM, il processo di boot è gestito nella flash separata del QNAP e non
dall'hard disk. L'uso dell'hard disk avviene solo dopo che il kernel è partito.
È quindi necessario che initrd.img sia corretta, in modo che il kernel "trovi"
le partizioni una volta partito. Perché non lo è già?
Ho fatto un'ulteriore domanda su [debian-arm] ma non ho ancora ricevuto
risposta, per cui la giro anche qui: se cambio i dischi e rifaccio il RAID1,
come ho fatto, devo rieseguire a mano "update-initramfs -u" (o qualcosa di
analogo) in modo che gli UUID dei nuovi dischi siano segnati anche in
/boot/initrd.img , oppure non serve? Sembra un'operazione banale e innocua, ma
visto che il QNAP è headless e si può contattare solo via rete, un eventuale
cambiamento in quello che c'è nella flash - che è ciò che "update-initramfs -u"
farebbe - potrebbe rendere il sistema difficile da recuperare...
Emanuele
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a
mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: