it:jednodeskove-pocitace:raspberry-pi-5-domaci-server

Rozdíly

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

Odkaz na výstup diff

Obě strany předchozí revize Předchozí verze
Následující verze		 Předchozí verze
it:jednodeskove-pocitace:raspberry-pi-5-domaci-server [2025/02/15 12:49] – Petr Nosekit:jednodeskove-pocitace:raspberry-pi-5-domaci-server [2025/08/23 19:33] (aktuální) – Petr Nosek
Řádek 49: Řádek 49:
 </code> </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. 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] [Service]
 Type=simple 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 Restart=always
 User=root 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 StandardError=append:/var/log/x728-battery.log
  
Řádek 720: Řádek 857:
 ===== Konfigurace softwarového RAIDu – zrcadlení ===== ===== Konfigurace softwarového RAIDu – zrcadlení =====
  
-=== Adresace disků ===+Při konfiguraci jsem vycházel z těchto návodů, přičemž ani jeden není dokonalý pro moji situaci a musel jsem si návody přízpůsobit. Uvádím je pro úplnost jako zdroj: 
 + 
 +  * https://github.com/robertalexa/rpi-raid1-root-partition/blob/main/README.md 
 +  * https://www.jeffgeerling.com/blog/2020/building-fastest-raspberry-pi-nas-sata-raid 
 +  * https://gist.github.com/leandrofilipe/f9636be272f97d414652ce1f21e6b1f4 
 + 
 +==== Adresace disků ====
  
 Používám **Suptronics X1005 2280 M.2 NVMe Dual Shield** pro **Raspberry Pi 5**, který umožňuje připojení dvou disků. Používám **Suptronics X1005 2280 M.2 NVMe Dual Shield** pro **Raspberry Pi 5**, který umožňuje připojení dvou disků.
Řádek 755: Řádek 898:
  
 Toto chování jsem nečekal, ale beru ho jako fakt a budu s ním dále pracovat obezřetně. Toto chování jsem nečekal, ale beru ho jako fakt a budu s ním dále pracovat obezřetně.
 +
 +
 +Abych si ušetřil problémy a následné zmatky, tak jsem raději disky prohodil. Tedy disk s operačním systémem jsem dal do slotu SSD2 a nový disk do slotu SSD1. Po změně zapojení vypadá výpis takto:
 +
 +<code bash>
 +NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS   
 +nvme0n1     259:0    0  1,8T  0 disk               
 +├─nvme0n1p1 259:1    0  512M  0 part /boot/firmware
 +└─nvme0n1p2 259:2    0  1,8T  0 part /             
 +nvme1n1     259:3    0  1,8T  0 disk               
 +</code>
 +
 +==== Vytvoření partition na novém disku před RAIDem ====
 +
 +Před vytvořením softwarového RAIDu je doporučeno **ručně vytvořit odpovídající partitiony na novém disku** (**nvme0n1**), aby odpovídaly rozdělení stávajícího disku (**nvme1n1**).  
 +RAID se obvykle vytváří nad existujícími partitionami, nikoliv nad celým diskem (i když je to možné, ale méně běžné).
 +
 +=== Jak vytvořit partitiony přesně podle původního disku? ===
 +
 +K tomu použijeme příkaz **sfdisk**, který umožňuje zkopírovat tabulku oddílů ze **nvme1n1** na **nvme0n1**.
 +
 +=== Krok 1: Záloha stávající partition tabulky ===
 +
 +Než cokoliv změníme, je vhodné **uložit stávající partition tabulku**, pokud by bylo potřeba ji obnovit:
 +
 +<code bash>
 +sudo sfdisk -d /dev/nvme0n1 > partition_backup.txt
 +</code>
 +
 +Tím se uloží rozložení oddílů do souboru **partition_backup.txt**, což umožní jejich případnou obnovu.
 +
 +=== Krok 2: Zkopírování partition schématu na nový disk ===
 +
 +Zkopíruj stejnou partition tabulku ze **nvme1n1** na **nvme0n1**:
 +
 +<code bash>
 +sudo sfdisk /dev/nvme1n1 < partition_backup.txt
 +</code>
 +
 +Tento příkaz vytvoří na **nvme1n1** stejnou strukturu jako na **nvme0n1**.
 +
 +=== Krok 3: Ověření správnosti nového rozdělení disku ===
 +
 +Po provedení předchozího příkazu je vhodné **ověřit, zda jsou partitiony nyní identické**:
 +
 +<code bash>
 +lsblk
 +fdisk -l /dev/nvme1n1
 +</code>
 +
 +Pokud se vše shoduje, můžeme pokračovat v nastavování RAIDu.
 +
 +
 +
 +==== Konfigurace RAID 1 pomocí mdadm ====
 +
 +Pro konfiguraci softwarového RAIDu pro zrcadlení (RAID 1) použijeme **mdadm**.
 +
 +Nejprve nainstalujeme potřebný balíček:
 +
 +<code bash>
 +sudo apt install mdadm
 +</code>
 +
 +Vzhledem k tomu, že RAID nastavujeme na běžícím systému, vytvoříme RAID **v degradovaném režimu**, tedy pouze s jedním diskem. Druhý disk přidáme později.
 +
 +=== Vytvoření RAID 1 v degradovaném režimu ===
 +
 +Místo dvou disků v RAIDu vytvoříme pole pouze s novým diskem (**nvme1n1p1** a **nvme1n1p2**).  
 +Druhý disk zatím nebude připojen (`missing`), což RAID umožňuje:
 +
 +<code bash>
 +sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/nvme1n1p1 missing --metadata=0.90
 +sudo mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 /dev/nvme1n1p2 missing
 +</code>
 +
 +✅ **Vysvětlení:**  
 +  * `missing` znamená, že druhý disk zatím není připojen, RAID poběží pouze s jedním diskem.
 +  * `--metadata=0.90` je doporučeno pro zaváděcí oddíly.
 +
 +Následujícím krokem je vytvoření souborového systému na nově vytvořeném RAIDu.
 +
 +=== Vytvoření souborových systémů ===
 +
 +Na nových RAID oddílech vytvoříme souborový systém:
 +
 +<code bash>
 +sudo mkfs.vfat /dev/md0
 +sudo mkfs.ext4 /dev/md1
 +</code>
 +
 +Nyní připojíme RAID a přeneseme systémové soubory.
 +
 +=== Přenos systémových souborů na RAID ===
 +
 +Nejprve připojíme bootovací oddíl RAID:
 +
 +<code bash>
 +mkdir /mnt/raid_boot
 +mount /dev/md0 /mnt/raid_boot
 +rsync -axv /boot/firmware/ /mnt/raid_boot/
 +</code>
 +
 +Poté připojíme hlavní oddíl a přeneseme systém:
 +
 +<code bash>
 +mkdir /mnt/raid_root
 +mount /dev/md1 /mnt/raid_root
 +rsync -axv / /mnt/raid_root --exclude=/mnt --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run --exclude=/tmp
 +</code>
 +
 +=== Úprava fstab pro použití RAIDu ===
 +
 +Otevřeme soubor **fstab** na novém RAIDu:
 +
 +<code bash>
 +nano /mnt/raid_root/etc/fstab
 +</code>
 +
 +Najdeme řádky obsahující `/dev/nvme0n1p1` a `/dev/nvme0n1p2` a upravíme je:
 +
 +<code>
 +/dev/md0  /boot/firmware vfat  defaults  0  2
 +/dev/md1  /              ext4  defaults,noatime,errors=remount-ro  0  1
 +</code>
 +
 +Tím zajistíme, že systém při bootu použije RAID.
 +
 +=== Aktualizace konfigurace mdadm ===
 +
 +Zjistíme UUID RAID polí:
 +
 +<code bash>
 +mdadm --detail --scan
 +</code>
 +
 +Výstup bude podobný tomuto:
 +
 +<code>
 +ARRAY /dev/md0 metadata=0.90 UUID=e11e72e6:cfe13794:c15f4f5c:b4c7de4f
 +ARRAY /dev/md1 metadata=1.2 name=server:1 UUID=6af6a5bd:b7fd9bcc:2cd91b19:bf09e0c3
 +</code>
 +
 +Tento výstup zapíšeme na konec souboru:
 +
 +<code bash>
 +nano /mnt/raid_root/etc/mdadm/mdadm.conf
 +</code>
 +
 +=== Úprava cmdline.txt pro bootování z RAIDu ===
 +
 +Otevřeme soubor bootovací konfigurace:
 +
 +<code bash>
 +nano /mnt/raid_boot/cmdline.txt
 +</code>
 +
 +Najdeme řádek obsahující:
 +
 +<code>
 +root=PARTUUID=aa235387-02
 +</code>
 +
 +A nahradíme jej:
 +
 +<code>
 +root=/dev/md1 rootfstype=ext4 fsck.repair=yes rootwait rootdelay=10 cfg80211.ieee80211_regdom=CZ
 +</code>
 +
 +✅ **Vysvětlení:**
 +  * `root=/dev/md1` – říká jádru, že root filesystem je na RAIDu.
 +  * `rootwait rootdelay=10` – umožňuje systému počkat na sestavení RAIDu.
 +  * `fsck.repair=yes` – umožní automatickou opravu souborového systému při bootu.
 +
 +=== Přidání RAID modulů do initramfs ===
 +
 +Aby jádro vědělo, že používáme RAID již při bootu, přidáme moduly do **initramfs**:
 +
 +<code bash>
 +nano /mnt/raid_root/etc/initramfs-tools/modules
 +</code>
 +
 +Přidáme tyto řádky:
 +
 +<code>
 +raid1
 +md_mod
 +ext4
 +</code>
 +
 +Aktualizujeme initramfs:
 +
 +<code bash>
 +umount /mnt/raid_boot
 +mount /dev/md0 /mnt/raid_root/boot/firmware/
 +
 +mkdir -p /mnt/raid_root/dev /mnt/raid_root/proc /mnt/raid_root/sys /mnt/raid_root/run
 +
 +mount --bind /dev /mnt/raid_root/dev
 +mount --bind /proc /mnt/raid_root/proc
 +mount --bind /sys /mnt/raid_root/sys
 +mount --bind /run /mnt/raid_root/run
 +
 +chroot /mnt/raid_root 
 +update-initramfs -u
 +</code>
 +
 +Tím jsme zajistili, že RAID bude dostupný již při startu systému.
 +
 +**Nyní jsem mohl Raspberry restartovat. Důležitá věc, musel jsem primární disk - tedy disk s RAID přesunout do slotu SSD2 na desce. Dokud jsem to neudělal, boot se nepodařil, systém byl zmatený. Tento krok je klíčový - prohodit disky ve slotech.**
 +
 +
 +==== Přidání disku do RAID ====
 +
 +Po prohození disků ve slotech (disk s nastaveným RAIDem musí být ve slotu **SSD2**) a nabootování systému je možné přidat druhý disk zpět do RAID pole.  
 +Stejný postup se použije i v případě, že se nějaký disk odpojí a pole je **degradované**, tedy běží pouze s jedním diskem.
 +
 +✅ **Klíčové pravidlo:**  
 +**Primární disk musí být ve slotu SSD2, aby systém správně nabootoval.**
 +
 +=== Stav RAID pole po nabootování ===
 +
 +Z výpisu je vidět, že v RAID poli je zatím pouze jeden disk:
 +
 +<code bash>
 +cat /proc/mdstat 
 +</code>
 +
 +**Výstup:**
 +<code>
 +Personalities : [raid1] [linear] [raid0] [raid6] [raid5] [raid4] [raid10] 
 +md0 : active raid1 nvme0n1p1[0]
 +      524224 blocks [2/1] [U_]
 +      
 +md1 : active raid1 nvme0n1p2[0]
 +      1952854080 blocks super 1.2 [2/1] [U_]
 +      bitmap: 4/4 pages [64KB], 65536KB chunk
 +</code>
 +
 +Nově připojený disk **nvme1n1** zatím není součástí RAID pole.
 +
 +=== Výpis připojených disků ===
 +
 +Podíváme se na aktuální stav připojených disků:
 +
 +<code bash>
 +lsblk
 +</code>
 +
 +**Výstup:**
 +<code>
 +NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
 +nvme0n1     259:0    0   1,8T  0 disk  
 +├─nvme0n1p1 259:1    0   512M  0 part  
 +│ └─md0       9:0    0 511,9M  0 raid1 /boot/firmware
 +└─nvme0n1p2 259:2    0   1,8T  0 part  
 +  └─md1       9:1    0   1,8T  0 raid1 /
 +nvme1n1     259:3    0   1,8T  0 disk  
 +├─nvme1n1p1 259:4    0   512M  0 part  
 +└─nvme1n1p2 259:5    0   1,8T  0 part  
 +</code>
 +
 +=== Detaily RAID pole ===
 +
 +Zkontrolujeme aktuální stav RAID pole:
 +
 +<code bash>
 +mdadm --detail /dev/md0
 +</code>
 +
 +<code>
 +/dev/md0:
 +           Version : 0.90
 +     Creation Time : Sat Feb 15 16:52:29 2025
 +        Raid Level : raid1
 +        Array Size : 524224 (511.94 MiB 536.81 MB)
 +     Used Dev Size : 524224 (511.94 MiB 536.81 MB)
 +      Raid Devices : 2
 +     Total Devices : 1
 +       Persistence : Superblock is persistent
 +
 +       Update Time : Sat Feb 15 19:15:46 2025
 +             State : clean, degraded 
 +    Active Devices : 1
 +   Working Devices : 1
 +    Failed Devices : 0
 +     Spare Devices : 0
 +
 +Consistency Policy : resync
 +
 +    Number   Major   Minor   RaidDevice State
 +       0     259        1        0      active sync   /dev/nvme0n1p1
 +       -       0        0        1      removed
 +</code>
 +
 +Stejným způsobem můžeme zkontrolovat i hlavní RAID oddíl:
 +
 +<code bash>
 +mdadm --detail /dev/md1
 +</code>
 +
 +**Výstup ukazuje, že RAID pole je degradované – chybí druhý disk.**
 +
 +=== Přidání nového disku do RAID pole ===
 +
 +Nyní přidáme nový disk **nvme1n1** do RAID pole:
 +
 +<code bash>
 +mdadm --add /dev/md0 /dev/nvme1n1p1
 +mdadm --add /dev/md1 /dev/nvme1n1p2
 +</code>
 +
 +Po přidání zkontrolujeme stav RAIDu:
 +
 +<code bash>
 +cat /proc/mdstat 
 +</code>
 +
 +**Výstup ukazuje, že RAID začíná synchronizaci:**
 +<code>
 +Personalities : [raid1] [linear] [raid0] [raid6] [raid5] [raid4] [raid10] 
 +md0 : active raid1 nvme1n1p1[1] nvme0n1p1[0]
 +      524224 blocks [2/2] [UU]
 +      
 +md1 : active raid1 nvme1n1p2[2] nvme0n1p2[0]
 +      1952854080 blocks super 1.2 [2/1] [U_]
 +      [=>...................]  recovery =  5.3% (104572928/1952854080) finish=149.1min speed=206517K/sec
 +      bitmap: 4/4 pages [64KB], 65536KB chunk
 +</code>
 +
 +=== Sledování průběhu synchronizace ===
 +
 +Pro sledování průběhu synchronizace RAID pole můžeme použít:
 +
 +<code bash>
 +watch -n 1 cat /proc/mdstat
 +</code>
 +
 +✅ **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`.
 +
  
  
  
  • it/jednodeskove-pocitace/raspberry-pi-5-domaci-server.1739623747.txt.gz
  • Poslední úprava: 2025/02/15 12:49
  • autor: Petr Nosek