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/02/15 18:58] – [Konfigurace softwarového RAIDu – zrcadlení] Petr Nosek
+++ it:jednodeskove-pocitace:raspberry-pi-5-domaci-server [2025/08/23 19:33] (aktuální) – Petr Nosek
@@ Řádek 49: / Řádek 49: @@
 </code>
-Uložte změny a restartujte Raspberry Pi:
+Uložte změny, vložte disk do Raspberry a můžete nabootovat.
-<code bash>
-sudo reboot
-</code>
@@ Řádek 91: / Řá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 440: / Řá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
@@ Řádek 1100: / Řádek 1237: @@
 ✅ **RAID nyní probíhá synchronizace a disk bude plně zrcadlen po dokončení procesu.**
+=== Priorita disků po odpojení a opětovném připojení ===
+Pokud dojde k **odpojení jednoho disku** a následně jej znovu připojíme, systém rozhodne, **který disk bude v RAIDu upřednostněn**, a to na základě několika faktorů.
+Nezáleží na tom, **že je disk ve slotu SSD2**, protože po připojení obou disků systém automaticky **vybere ten, který běžel jako poslední aktivní po rozpojení RAIDu**.
+=== Jak systém určuje, který disk bude upřednostněn? ===
+Systém rozhoduje na základě **poslední aktualizace metadat RAIDu**. Každý disk v RAIDu obsahuje **metadata (superblock)**, která uchovávají informace o změnách v poli.
+**Klíčový parametr je tzv. Event Count**, což je čítač změn.
+✅ **RAID vybere disk s nejvyšším Event Count jako platný.**
+Pokud má jeden disk vyšší Event Count než druhý, systém považuje tento disk za aktuální a použije jej jako primární.
+=== Jak zjistit, který disk má vyšší Event Count? ===
+Můžeš si ověřit, který disk má aktuálnější metadata pomocí příkazu:
+<code bash>
+mdadm --examine /dev/nvme0n1p2 /dev/nvme1n1p2
+</code>
+**Výstup bude obsahovat řádky podobné tomuto:**
+<code>
+/dev/nvme0n1p2:
+           Events : 405
+/dev/nvme1n1p2:
+           Events : 392
+</code>
+✅ **Disk s vyšším číslem „Events“ je považován za aktuální.**
+Pokud se **Event Count neshoduje**, mdadm automaticky označí **starší disk jako neaktuální** a vyřadí ho z RAID pole.
+=== Co se stane při neaktuálním disku? ===
+Pokud má jeden z disků nižší Event Count, systém jej při dalším spuštění považuje za **zastaralý** a označí jej jako neaktivní.
+RAID pak při připojení tohoto disku provede **resynchronizaci** dat.
+Proto je důležité po výpadku disku **zkontrolovat stav RAID**
+===== Nastavení NetworkManagera a statické IP adresy =====
+Nejprve jsem řešil přejmenování připojení v NetworkManageru:
+----
+==== 🟢 1. Ověř existující připojení ====
+<code bash>
+nmcli con show
+</code>
+Výstup:
+<code>
+NAME                 UUID                                  TYPE      DEVICE
+Drátové připojení 1  95b853d9-d49d-3af0-ac2e-38a74299292d  ethernet  eth0
+</code>
+==== 🔑 2. Přejmenuj připojení ====
+Například pro nový název `eth0-static`:
+<code bash>
+nmcli con modify "Drátové připojení 1" connection.id "eth0-static"
+</code>
+----
+==== 🛠️ 3. Ověř změnu ====
+<code bash>
+nmcli con show
+</code>
+Výstup bude vypadat takto:
+<code>
+NAME          UUID                                  TYPE      DEVICE
+eth0-static   95b853d9-d49d-3af0-ac2e-38a74299292d  ethernet  eth0
+</code>
+==== 🔄 4. Restartuj připojení (volitelné): ====
+Pro jistotu můžeš restartovat síťové připojení:
+<code bash>
+nmcli con down "eth0-static" && nmcli con up "eth0-static"
+</code>
+Nyní mohu pracovat s připojením pod vlastním názvem a upravit jeho parametry podle potřeby.
+----
+Pokud složka `/etc/NetworkManager/system-connections/` neobsahuje žádné soubory, znamená to, že NetworkManager uchovává konfiguraci pouze v paměti a neukládá ji do persistentních souborů. To se někdy stává, když se konfigurace vytvoří automaticky při prvním připojení a explicitně se neuloží.
+----
+==== 🟢 Jak zjistit současnou konfiguraci: ====
+**Zobraz detaily aktuálního připojení:**
+<code bash>
+nmcli con show "eth0-static"
+</code>
+To ukáže všechny parametry připojení, včetně IP, DNS a brány.
+----
+**Vytvoř trvalý konfigurační soubor:**
+Pokud chceš, aby bylo připojení trvalé a mělo statickou IP, můžeš ho upravit a uložit:
+<code bash>
+nmcli con modify "eth0-static" ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8 8.8.4.4"
+nmcli con up "eth0-static"
+</code>
+Tím se vytvoří i soubor v `/etc/NetworkManager/system-connections/`.
+----
+**Zálohuj konfiguraci (volitelné):**
+Před změnami můžeš exportovat aktuální nastavení:
+<code bash>
+nmcli con export "eth0-static" > eth0-static.conf
+</code>
+----
+**Ověř novou konfiguraci a soubor:**
+Po úpravě by se měl v `/etc/NetworkManager/system-connections/` objevit soubor `eth0-static`.