Upgrade Nextbox SSD (Austausch) [de/en]

NextBox
1

Halihalo,

[de]
spricht etwas dagegen, dass man die verbaute SSD auf eine größere SSD (Samsung 870 Evo 4TB) klont und mit GParted nachträglich von der Größe anpasst? Abgesehen vom Garantie-Verlust?

[en]
is there anything against cloning the installed SSD to a larger SSD (Samsung 870 Evo 4TB) and resizing it afterwards with GParted? Apart from the loss of warranty?

Vielen Dank / Thank you
Matthias

2

Kürzlich wechselte ich die 2TB SSD auf Samsung 870 QVO, 8TB.

Kurz
Der Wechsel funktioniert (fast) wie in HD Tausch beschrieben.
Je nach verwendeten Werkzeugen zum Partitioniern und Formatieren muss die /etc/fstab in puncto LABEL / PARTLABEL angepasst werden.

Lang:
Beobachtung: Da die Disk mit GPT Disklabel partitioniert wurde, erwartet mount ein “GPT-Partlabel”. Siehe auch Persistent block device naming - ArchWiki und Labels › Wiki › ubuntuusers.de

Das Supportscript zur HD Vorbereitung setzt ein GPT Partition Label. Mount erwartet dazu (neuerdings?) die Angaben “PARTLABEL”.

In der /etc/fstab wird ab Werk “LABEL” verwendet. Hat eine Partition “nur” ein “PARTLABEL”, und ist in der /etc/fstab “LABEL” abgegeben, erkennt das Kommando “mount” die Partition nicht und montiert nicht.

Das führt während dem Booten dazu dass das Montieren der Partition gemäss Angaben der /etc/fstab nicht funktioniert. Das System nutzt im Falle nextbox das Dateisystem der internen microSD. So lange, bis die vollgeschrieben ist. Und bleibt dann stehen.

Auszug /etc/fstab (Nach meinen Anpassungen)

# Label mismatch upon "mount": Mount ignores "LABEL" (since ?). Use "PARTLABEL" and prepare disk partition accordingly. Partitioning and filesystem tools usually use "name option", but apply a "PARTLABEL".
#LABEL=NextBoxHardDisk	/srv			ext4	defaults,noatime	0	2
PARTLABEL=NextBoxHardDisk	/srv			ext4	defaults,noatime	0	2

Veranschaulichung der ZWEI Arten von Labels:

user@nextbox:~# sudo lsblk -f -o+partlabel
NAME        FSTYPE LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINT PARTLABEL
sda                                                                                      
└─sda1      ext4          caaaaaaa-dddd-eeee-ffff-000000000002    6.9T     0% /srv       NextBoxHardDisk
mmcblk0                                                                                  
├─mmcblk0p1 vfat   boot   ABCD-EF12                             221.3M    12% /boot      
└─mmcblk0p2 ext4   rootfs abcdef12-9876-fed
2 Likes
3

Das betrifft in dem Fall auch Leute, welche die HDD ersetzen, und ist nicht SSD spezifisch?

Müsste man also hier anpassen: https://github.com/Nitrokey/nitrokey-documentation/blob/master/nextbox/technical/replace-drive.rst

1 Like
4

Guter Punkt, und ja, das betrifft jedwede Disk.
Aber womöglich genügt eine Ergänzung dort im Text nicht für weniger Linux-affine Menschen.

Beobachtung 1
Der Abschnitt “Prepare Hard Disk” im Text “Replace Internal Hard-Drive” beschreibt:

In diesem Script (Quelle: nextbox/assembly/prepare_harddrive.sh at master · Nitrokey/nextbox · GitHub) wird bei Zeile 38 eine Partitionstabelle vom Typ GPT auf die neue Disk geschrieben. Dabei wird ein PARTLABEL, jedoch kein LABEL geschrieben.
Beispielhafte Analyse, bei der die neue Hard Disk fiktiv als “/dev/sdc1” bekannt ist:

> nextuser@nextbox:~ $ lsblk -dno LABEL /dev/sdc1
> 
> nextuser@nextbox:~ $ lsblk -dno PARTLABEL /dev/sdc1
> NextBoxHardDisk

Beobachtung 2

Das LABEL oder PARTLABEL wird beim Starten des Systems zum montieren der “richtigen Hard Disk” an den richtigen Ort im System verwendet. Dazu werden im Debian OS Image der Nextbox Eigenschaften des Kommandos “mount” genutzt. Im Script “nextbox/image/image-config/stage-nextbox/00-init/01-run.sh at master · Nitrokey/nextbox · GitHub” wird mit Zeile 53 die Anweisung zum montieren der Hard Disk mit dem LABEL “NextBoxHardDisk” an den Ort “/srv” gegeben.

> echo "LABEL=NextBoxHardDisk 	/srv			ext4	defaults,noatime	0	2" >> /etc/fstab
> echo "/srv/varlog		/var/log		none	defaults,bind		0	0" >> /etc/fstab
> echo "/srv/varcache		/var/cache		none	defaults,bind		0	0" >> /etc/fstab

Doch die neue Hard Disk (siehe GPT in Beobachtung 1 oben) besitzt kein LABEL, sondern ein PARTLABEL mit dem Inhalt “NextBoxHardDisk”.

Beim Systemstart wird die Datei /etc/fstab für Aufgaben des Befehls mount ausgewertet:

  1. finde eine Partition auf den Hard Disks des Systems, welche das LABEL “NextCloudHardDisk” trägt
  2. montiere diese Partition im Dateisystem unter “/srv”.

HINWEIS: Ob und wie “mount” mit mehreren Partitionen desselben Namens umgehen wird, ist nicht Gegenstand dieser Beschreibung. Für Details sei kernel.org empfohlen.

Die Folgen sind

  • Weil kein passendes “LABEL” gefunden wird, wird KEINE (zusätzliche, grosse) Hard Disk montiert
  • Der Ort /srv ist auf dem internen 8GB Datenspeicher der Nextbox (des RaspberryPi) definiert. Er dient dem Einhängen eines voluminiöseren Datenspeichers.
  • Dieses “Einhängen” resp. “Montieren” misslingt, es stehen also nur < 8GB für System und Daten zur Verfügung.

Résumeé

“Ab Werk” ist die Datenpartition der Nextbox mit dem LABEL “NextBoxHardDisk” markiert, was mit dem Einhängen Hard Disk für Daten beim Systemstart harmoniert.

“Ab Hersteller & Community” ist die Datenpartition der Nextbox mit dem PARTLABEL “NextBoxHardDisk” markiert, was mit dem Einhängen Hard Disk für Daten beim Systemstart NICHT harmoniert.

Empfehlung

Meiner Ansicht nach hat es diese Möglichkeiten, das Dilemma zu lösen:

1 Like
5

Ja, das Skript müsste angepasst werden. Das wäre meiner Meinung nach das wichtigste. @daringer sieht das wohl auch so, und könnte das in die Wege leiten?

1 Like