Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- it:jednodeskove-pocitace:raspberry-pi-5-domaci-server [2025/08/21 21:34] – [Bootování z NVMe disku] Petr Nosek
+++ it:jednodeskove-pocitace:raspberry-pi-5-domaci-server [2025/08/23 19:33] (aktuální) – Petr Nosek
@@ Řádek 87: / Řádek 87: @@
 Uložte změny a restartujte Raspberry Pi.
+===== Raspberry Pi 5 s 4TB disk: převod MBR na GPT a oprava PARTUUID =====
+Raspberry Pi 5 je konečně dost výkonné na to, aby zvládlo velký disk a dělalo serverové úlohy. Ale pokud připojíte 4TB disk, narazíte na starý známý problém – **MBR tabulka oddílů**. Ta má strop **2 TiB**. Zbytek disku jako by neexistoval. Řešením je **GPT**. Jenže když jsem převedl disk z MBR na GPT, Raspberry Pi po restartu nenabootovalo. V tomhle článku popíšu krok za krokem, jak jsem to vyřešil.
+Důležitá poznámka: samotný disk jsem měl připojený k jinému počítači přes USB redukci, abych mohl bezpečně provádět změny. Teprve po úpravách jsem ho vrátil zpět k Raspberry Pi.
+==== Co je MBR a GPT ====
+**MBR (Master Boot Record)** je historický způsob zápisu tabulky oddílů, používaný od počátků PC. Využívá 32bit adresy sektorů, a proto dokáže adresovat maximálně 2 TiB na disku se sektory 512 B. Je kompatibilní téměř se vším, ale omezený kapacitou.
+**GPT (GUID Partition Table)** je modernější standard, součást specifikace UEFI. Umožňuje prakticky neomezenou velikost disků (v řádu zettabajtů), více než čtyři primární oddíly a navíc ukládá záložní kopii tabulky oddílů. Díky tomu je spolehlivější a určený právě pro velké disky, jako je 4TB nebo větší.
+----
+==== Problém: MBR limit ====
+MBR (msdos) tabulka oddílů používá 32bit adresy sektorů. Při velikosti sektoru 512 B umí oslovit maximálně **2 TiB** disku. Na mém 4TB disku jsem proto viděl jen polovinu kapacity. GPT (GUID Partition Table) žádný takový limit nemá.
+----
+==== Krok 1: převod na GPT pomocí gdisk ====
+Nechtěl jsem přijít o systém, takže jsem sáhl po nástroji **gdisk**, který umí převést MBR → GPT bez mazání dat.
+<code bash>
+sudo apt install gdisk
+sudo gdisk /dev/sda
+</code>
+Po spuštění `gdisk` hlásil, že našel MBR tabulku, a nabídl převod na GPT. Stačilo zkontrolovat oddíly příkazem `p` a uložit změny příkazem `w`.
+Při potvrzení mě `gdisk` vystrašil hláškou:
+<code>
+Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
+</code>
+Na první pohled to vypadá, že smaže všechno. Ve skutečnosti to znamená jen tolik, že se přepíše **tabulka oddílů** – data na samotných oddílech zůstanou. Přesto doporučuju mít zálohu.
+----
+==== Krok 2: první boot a chyba ====
+Po restartu Raspberry Pi 5 kernel nastartoval, ale hned spadl do **initramfs** s chybou:
+<code>
+ALERT! PARTUUID=xxxx-02 does not exist.
+</code>
+Co se stalo? Raspberry Pi OS používá k identifikaci oddílů **PARTUUID**. Jenže převodem na GPT se PARTUUID všech oddílů změnily. Konfigurační soubory pořád ukazovaly na staré hodnoty.
+----
+==== Krok 3: oprava cmdline.txt ====
+V adresáři `/boot/firmware` je soubor `cmdline.txt`. Obsahuje parametr `root=PARTUUID=...`.
+Pomocí příkazu:
+<code bash>
+lsblk -o NAME,FSTYPE,UUID,PARTUUID
+</code>
+jsem zjistil nové PARTUUID oddílů. Ukázkový výpis:
+<code>
+NAME   FSTYPE LABEL UUID                                 PARTUUID
+sda
+├─sda1 vfat         76B3-1F2A                            1c9f7d17-01
+└─sda2 ext4         d4cc7d63-da78-48ad-9bdd-64ffbba449a8 1c9f7d17-02
+</code>
+  * `/dev/sda1` je boot (FAT32 → /boot/firmware)
+  * `/dev/sda2` je root (ext4 → /)
+Do `cmdline.txt` jsem zapsal správnou hodnotu:
+<code>
+console=serial0,115200 console=tty1 root=PARTUUID=1c9f7d17-02 rootfstype=ext4 fsck.repair=yes rootwait
+</code>
+To posunulo boot dál – kernel už root oddíl našel.
+----
+==== Krok 4: oprava /etc/fstab ====
+Jenže boot stále padal do emergency módu. Důvod? `/etc/fstab` obsahoval staré PARTUUID pro `/` i `/boot/firmware`. Oba řádky dokonce ukazovaly na stejný oddíl.
+Správně to má vypadat takto:
+<code>
+proc            /proc           proc    defaults          0       0
+PARTUUID=1c9f7d17-01   /boot/firmware  vfat    defaults          0       2
+PARTUUID=1c9f7d17-02   /               ext4    defaults,noatime  0       1
+</code>
+Po úpravě `/etc/fstab` a restartu systém naběhl.
+----
+==== Výsledek ====
+Po opravě PARTUUID Raspberry Pi 5 nabootovalo z mého 4TB disku s tabulkou GPT. Celá kapacita disku je k dispozici a systém funguje, jako by se nic nestalo.
+----
+==== Shrnutí ====
+  - Raspberry Pi OS standardně instaluje disk s **MBR**, takže na 4TB disku vidíte jen 2TB.
+  - Pomocí `gdisk` lze převést tabulku na **GPT** bez ztráty dat.
+  - Po převodu je nutné **opravit PARTUUID v `cmdline.txt` i `/etc/fstab`**.
+  - Pak Pi 5 bez problémů bootuje z GPT disku a využije celou kapacitu.
+----
+✅ Pokud tedy narazíte na 2TB strop na Raspberry Pi, řešením je převést disk na GPT a opravit konfiguraci.\\
+📌 Doporučení: v `/etc/fstab` můžete místo PARTUUID používat přímo **UUID souborového systému** – je stabilnější a méně náchylné na změny v tabulce.
+----
+==== Jak číst výpis lsblk ====
+Ukázkový výpis:
+<code>
+NAME   FSTYPE LABEL UUID                                 PARTUUID
+sda
+├─sda1 vfat         76B3-1F2A                            1c9f7d17-01
+└─sda2 ext4         d4cc7d63-da78-48ad-9bdd-64ffbba449a8 1c9f7d17-02
+</code>
+Vysvětlení sloupců:
+  * **NAME** – název zařízení nebo oddílu (např. `sda1`)
+  * **FSTYPE** – typ souborového systému (např. `vfat`, `ext4`)
+  * **LABEL** – název oddílu, pokud je nastaven
+  * **UUID** – unikátní identifikátor souborového systému
+  * **PARTUUID** – unikátní identifikátor oddílu v tabulce oddílů (právě ten se změnil při převodu MBR → GPT)
@@ Řádek 436: / Řádek 576: @@
 [Service]
 Type=simple
-ExecStart=/usr/bin/python3 /etc/local-scripts/x728-script/sample/x728-v2.x-asd-gpiod.py
+ExecStart=/usr/bin/python3 /etc/local-scripts/x728-script/sample/x728-v2.x-plsd-gpiod.py
 Restart=always
 User=root
-StandardOutput=append:/var/log/x728-battery.log
+#StandardOutput=append:/var/log/x728-battery.log
+StandardOutput=null
 StandardError=append:/var/log/x728-battery.log