# Upgrade Nextbox SSD (Austausch) \[de/en\]

**URL:** <https://support.nitrokey.com/t/upgrade-nextbox-ssd-austausch-de-en/5018>\
**Category:** NextBox\
**Created:** [May 1, 2023, 6:54am UTC](https://support.nitrokey.com/t/upgrade-nextbox-ssd-austausch-de-en/5018 "2023-05-01T06:54:06Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![timera](https://support.nitrokey.com/letter_avatar_proxy/v4/letter/t/e56c9b/32.png) [@timera](https://support.nitrokey.com/u/timera)\
**Post date:** [May 1, 2023, 6:54am UTC](https://support.nitrokey.com/t/upgrade-nextbox-ssd-austausch-de-en/5018/1 "2023-05-01T06:54:06Z")

</div>

Halihalo,

[de]  
spricht etwas dagegen, dass man die verbaute SSD auf eine größere SSD ([Samsung 870 Evo 4TB](https://www.idealo.de/preisvergleich/OffersOfProduct/201032820_-870-evo-4tb-samsung.html)) 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](https://www.idealo.de/preisvergleich/OffersOfProduct/201032820_-870-evo-4tb-samsung.html)) and resizing it afterwards with GParted? Apart from the loss of warranty?

Vielen Dank / Thank you  
Matthias

---

<div class="post-metadata">

**Author:** ![nielsson4711](https://support.nitrokey.com/user_avatar/support.nitrokey.com/nielsson4711/32/1408_2.png) [@nielsson4711](https://support.nitrokey.com/u/nielsson4711)\
**Post date:** [May 8, 2023, 5:30am UTC](https://support.nitrokey.com/t/upgrade-nextbox-ssd-austausch-de-en/5018/2 "2023-05-08T05:30:11Z")

</div>

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](https://wiki.archlinux.org/title/Persistent_block_device_naming) und [Labels › Wiki › ubuntuusers.de](https://wiki.ubuntuusers.de/Labels/)

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)

```auto
# 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:

```auto
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

```

---

<div class="post-metadata">

**Author:** ![benzkji](https://support.nitrokey.com/user_avatar/support.nitrokey.com/benzkji/32/870_2.png) [@benzkji](https://support.nitrokey.com/u/benzkji)\
**Post date:** [November 4, 2023, 10:34am UTC](https://support.nitrokey.com/t/upgrade-nextbox-ssd-austausch-de-en/5018/3 "2023-11-04T10:34:13Z")

</div>

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](https://github.com/Nitrokey/nitrokey-documentation/blob/master/nextbox/technical/replace-drive.rst)

---

<div class="post-metadata">

**Author:** ![nielsson4711](https://support.nitrokey.com/user_avatar/support.nitrokey.com/nielsson4711/32/1408_2.png) [@nielsson4711](https://support.nitrokey.com/u/nielsson4711)\
**Post date:** [November 5, 2023, 5:50pm UTC](https://support.nitrokey.com/t/upgrade-nextbox-ssd-austausch-de-en/5018/4 "2023-11-05T17:50:41Z")

</div>

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:

> - Get the following script: _**[https://raw.githubusercontent.com/Nitrokey/nextbox/master/assembly/simple\_prepare\_harddrive.sh](https://raw.githubusercontent.com/Nitrokey/nextbox/master/assembly/simple_prepare_harddrive.sh)**_
> - Make the script executable: `chmod +x simple_prepare_harddrive.sh`
> - Connect your new hard-disk to your computer
> - Determine your hard-disk’s device name (e.g., `/dev/sdb`) and make sure none of its partitions are mounted

In diesem Script (Quelle: [nextbox/assembly/prepare\_harddrive.sh at master · Nitrokey/nextbox · GitHub](https://github.com/Nitrokey/nextbox/blob/master/assembly/prepare_harddrive.sh)) 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:

```auto
> 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](https://github.com/Nitrokey/nextbox/blob/master/image/image-config/stage-nextbox/00-init/01-run.sh)” wird mit Zeile 53 die Anweisung zum montieren der Hard Disk mit dem LABEL “NextBoxHardDisk” an den Ort “/srv” gegeben.

```auto
> 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](http://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:

- [nextbox/assembly/prepare\_harddrive.sh at master · Nitrokey/nextbox · GitHub](https://github.com/Nitrokey/nextbox/blob/master/assembly/prepare_harddrive.sh) so verändern, dass auf der neuen HD ein LABEL definiert wird, und kein PARTLABEL.
- [nextbox/assembly/prepare\_harddrive.sh at master · Nitrokey/nextbox · GitHub](https://github.com/Nitrokey/nextbox/blob/master/assembly/prepare_harddrive.sh) so ändern, dass in /etc/fstab PARTLABEL, anstelle LABEL gesucht und montiert wird. ZUSÄTZLICH Ergänzung der Dokumentation.
- Das Kommando _mount_ ODER das Script zur Auswertung von _/etc/fstab_ beim Systemstart auf eine Weise anpassen, dass sowohl LABEL, als auch PARTLABEL mit demselben Inhalt erkannt werden, und mehrfache Überlagerungen von “_labels_” nachvollziehbar gelöst werden können.

---

<div class="post-metadata">

**Author:** ![benzkji](https://support.nitrokey.com/user_avatar/support.nitrokey.com/benzkji/32/870_2.png) [@benzkji](https://support.nitrokey.com/u/benzkji)\
**Post date:** [November 5, 2023, 6:26pm UTC](https://support.nitrokey.com/t/upgrade-nextbox-ssd-austausch-de-en/5018/5 "2023-11-05T18:26:38Z")

</div>

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?