Raspberry Pi 5

Tato stránka je pouze pro čtení. Můžete si pouze prohlédnout zdrojový kód, ale ne ho měnit. Zeptejte se správce, pokud si myslíte, že něco není v pořádku.
====== Raspberry Pi 5 - domácí server ======

Dokumentovaná sestava se skládá z těchto komponent:

  * [[https://rpishop.cz/563516/raspberry-pi-5-16gb-ram/|Raspberry Pi 5 - 16GB RAM]]
  * [[https://rpishop.cz/chladice-pro-raspberry-pi-5/6496-raspberry-pi-5-active-cooler.html|Raspberry Pi 5 Active Cooler]]
  * [[https://rpishop.cz/560366/suptronics-x1005-2280-m-2-nvme-dual-shield/|Suptronics - X1005 2280 M.2 NVMe dual Shield pro Raspberry Pi 5]]
  * [[https://rpishop.cz/sprava-napajeni-a-ups/3102-suptronics-x728-ups-deska-pro-inteligentni-napajeni.html|Suptronics X728 v2.5 UPS deska pro inteligentní napájení]]
  * [[https://rpishop.cz/zdroje-s-25x55mm-kabelem/5048-cellevia-25x55-mm-5v4a-napajeci-zdroj-eu-cerny.html|Cellevia 2,5x5,5 mm 5V⎓4A napájecí zdroj, EU]]


Napájecí zdroj je kvůli UPS desce, protože UPS deska dokáže přes jack konektor 2,5×5,5 mm dodat až 20W. To je maximum, které půjde do UPS desky dodat a zároveň pokud nebudu připojovat další náročné periferie, tak tento výkon utáhne NVMe disky.
===== Bootování z NVMe disku ======

Standardně Raspberry Pi 5 bootuje z microSD karty, ale je možné nakonfigurovat systém tak, aby bootoval přímo z NVMe SSD připojeného přes PCIe. Návod vychází z článku [[https://wiki.geekworm.com/NVMe_SSD_boot_with_the_Raspberry_Pi_5|https://wiki.geekworm.com/NVMe_SSD_boot_with_the_Raspberry_Pi_5]]. Tento postup zahrnuje několik kroků:


=== 1. Flashování NVMe SSD pomocí Raspberry Pi Imager ===

Pro instalaci operačního systému na NVMe SSD můžete použít nástroj **Raspberry Pi Imager** na Windows nebo macOS. K tomu budete potřebovat **USB → NVMe adaptér**.

**Postup:**
  * Nainstalujte a spusťte **Raspberry Pi Imager**.
  * Připojte NVMe SSD k počítači pomocí **USB → NVMe adaptéru**.
  * Vyberte operační systém pro instalaci (např. Raspberry Pi OS).
  * Zvolte disk (NVMe SSD připojené přes adaptér).
  * Klikněte na **Write** a potvrďte zápis.
  * Po dokončení **NEODPOJUJTE NVMe SSD**, dokud neprovedete aktivaci PCIe. Tedy bod níže a jednoduchá editace config.txt na NVMe disku. Pak je možné z disku nabootovat a řešit už další kroky.


=== 2. Aktivace PCIe konektoru ===

Ve výchozím nastavení je PCIe port deaktivovaný a je nutné jej povolit.

Otevřete konfigurační soubor:

<code bash>
sudo nano /boot/firmware/config.txt
</code>

Přidejte následující řádky na konec souboru:

<code ini>
# Povolení PCIe externího konektoru
dtparam=pciex1

# Alternativní zápis pro povolení NVMe portu
dtparam=nvme
</code>

Uložte změny, vložte disk do Raspberry a můžete nabootovat. 


=== 3. Nastavení NVMe disku jako primárního bootovacího zařízení ===

Po povolení PCIe portu je třeba upravit pořadí bootování v bootloaderu.

**Možnost 1: Použití raspi-config**

Spusťte konfigurátor:

<code bash>
sudo raspi-config
</code>

Zvolte:
  * **6 Advanced Options → A4 Boot Order → B2 NVMe/USB Boot**
  * Potvrďte volbu **Yes** a restartujte:

<code bash>
sudo reboot
</code>

**Možnost 2: Ruční úprava bootovacího řetězce**

Otevřete EEPROM konfiguraci:

<code bash>
sudo rpi-eeprom-config --edit
</code>

Najděte řádek `BOOT_ORDER` a upravte ho na:

<code ini>
BOOT_ORDER=0xf416
</code>

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)



===== UPS X728 ======

UPS desku jsem kupoval ve verzi 2.5. Je důležité si uvědomit, že **UPS X728 není určena k automatickému spuštění Raspberry Pi po obnovení napájení**. Její hlavní funkcí je zajistit nepřerušený provoz **během výpadku**, dokud je baterie dostatečně nabitá.  

Jakmile baterie klesne na **kritickou úroveň**, Raspberry Pi by mělo být **řízeně vypnuto**, aby se zabránilo náhlé ztrátě dat nebo poškození systému. **UPS však Raspberry Pi znovu automaticky nenastartuje**, i když je baterie plně nabitá.

Pokud po zapnutí tlačítka na UPS svítí **červená LED dioda** na Raspberry Pi, znamená to, že deska je pod napětím, ale Raspberry Pi se samo nespustilo. Skutečné spuštění a běh systému indikují **jiné LED diody** na Raspberry Pi.
==== Specifikace ====

  * Napájení:
    * přes USB-C: 5Vdc, 3A
    * přes DC jack: 5Vdc ±5%, ≥4A
  * UPS výstup : 5.1V ±5% Max 8A
  * UPS nabíjecí proud: 2,3-3,2A
  * Terminální napětí baterie : 4,24V
  * Limit nabití : 4,1V


==== Dokumentace: ====

  * https://wiki.geekworm.com/X728-script
  * https://github.com/geekworm-com/x728-script/tree/main

{{:hardware:jednodeskove-pocitace:pasted:20250214-225625.jpeg}}


==== Zprovoznění software ====

Tento návod popisuje postup pro zprovoznění softwaru UPS X728 a jeho správné nastavení.

=== Aktivace I2C podpory ===

Nejprve zapněte podporu I2C pomocí `raspi-config`:

<code bash>
sudo raspi-config
</code>

Poté nainstalujte potřebné balíčky:

<code bash>
apt-get install i2c-tools
apt install python3-smbus
</code>

Ověření připojení přes I2C:

<code bash>
root@propasiv-server:~# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- 36 -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
</code>

#36 - adresa chipu pro měření úrovně nabití baterie
#68 - adresa RTC chipu

=== Instalace X728 ovladačů a skriptů ===

Nainstalujte potřebné nástroje:

<code bash>
sudo apt install -y gpiod
</code>

Stáhněte ovladače:

<code bash>
git clone https://github.com/geekworm-com/x728-script
</code>

Nastavte práva pro skripty:

<code bash>
cd x728-script
chmod +x *.sh
</code>

=== Konfigurace tlačítka pro fyzické vypnutí ===

Přesuňte potřebné soubory na správná místa:

<code bash>
sudo cp -f ./xPWR.sh /usr/local/bin/
sudo cp -f x728-pwr.service /lib/systemd/system
sudo systemctl daemon-reload
sudo systemctl enable x728-pwr
sudo systemctl start x728-pwr
</code>

Tento postup umožní, aby fyzické tlačítko na UPS desce X728 fungovalo takto:

  * Stisknutí po dobu **1-2 sekund** – **restart** zařízení.
  * Stisknutí po dobu **3 sekund** – **bezpečné vypnutí** (safe shutdown).
  * Stisknutí po dobu **7-8 sekund** – **nucené vypnutí** (force shutdown).

Tento postup **nedělá nic jiného** – pouze definuje chování tlačítka.

=== Softwarové vypnutí UPS (bez použití Linuxového `shutdown`) ===

Pro správné softwarové vypnutí je nutné nastavit vlastní alias:

1. Připravte skript `xSoft.sh`:

<code bash>
sudo cp -f ./xSoft.sh /usr/local/bin/
</code>

2. Vytvořte alias `x728off`, který bude bezpečně vypínat UPS:

<code bash>
echo "alias x728off='sudo /usr/local/bin/xSoft.sh 0 '''26''' '" >> ~/.bashrc
</code>

3. Aktivujte změny v `.bashrc`:

<code bash>
source ~/.bashrc
</code>

4. Nyní můžete bezpečně vypnout UPS příkazem:

<code bash>
x728off
</code>

**Pozor:** Nepoužívejte klasický Linuxový příkaz `shutdown`, jinak se UPS nevypne správně a může zůstat zapnutá.

=== Test bezpečného vypnutí ===

Softwarové bezpečné vypnutí:

<code bash>
x728off
</code>

**Nepoužívejte příkaz `shutdown` v Linuxu**, jinak se X728 nevypne správně.

=== Hardwarové bezpečné vypnutí ===

Pomocí fyzického tlačítka na UPS lze ověřit bezpečné vypnutí:

  * **1-2 sekundy** – restart zařízení.
  * **3 sekundy** – bezpečné vypnutí, LED diody pomalu zhasnou.
  * **7-8 sekund** – vynucené vypnutí, okamžité zhasnutí.

Tímto postupem zajistíte, že UPS X728 bude správně fungovat a umožní bezpečné vypnutí jak softwarově, tak fyzickým tlačítkem.


=== Přehled dostupných skriptů pro další práci s UPS ===

Každý skript demonstruje jinou funkcionalitu UPS X728:

  * **x728-v2.x-bat.py** – Čtení napětí baterie a jejího nabití.
  * **x728-v2.x-pld.py** – Detekce výpadku napájení z AC adaptéru.  
  * **x728-v2.x-asd.py** – Automatické vypnutí při poklesu napětí baterie pod nastavenou hodnotu.  
  
== Problém s knihovnou RPi.GPIO a řešení pomocí libgpiod ==

Starší ukázkové skripty používají knihovnu **RPi.GPIO**, která **není podporována v jádru Linuxu 6.6.x**. Pokud spustíte skript jako:

<code bash>
sudo python3 sample/x728-v2.x-plsd.py
</code>

může se objevit chyba kvůli nesprávnému **gpiochip** číslu.  

Doporučuje se přejít na knihovnu **libgpiod**, která je oficiálně doporučena a lépe podporována. UPS X728 poskytuje **jediný oficiální skript** využívající libgpiod:

<code bash>
sudo python3 sample/x728-v2.x-plsd-gpiod.py
</code>

U ostatních skriptů, které stále používají RPi.GPIO, je doporučeno přepsání na libgpiod nebo jejich převedení na shell skripty.

Skript jsem si tedy přizpůsobil pro libgpiod:

<code python>
#!/usr/bin/env python

import struct
import smbus
import time
import gpiod
import logging


# Log interval
LOG_INTERVAL = 300  # seconds
last_power_state = None # Stores last power state
last_log_time = 0 # Stores last log timestamp


# Logging configuration
logging.basicConfig(filename='/var/log/x728-battery.log', level=logging.INFO, format='%(asctime)s - %(message)s')


# GPIO chip and line definitions
#chipname = "gpiochip0"  # Use "gpiochip4" for Raspberry Pi 4/3
chipname = "gpiochip4"  # Use "gpiochip4" for Raspberry Pi 5
out_line_offset = 26  # Corresponds to GPIO26
pld_line_offset = 6  # Power loss detection pin
buzzer_line_offset = 20  # Buzzer control pin

# I2C address for battery monitoring
I2C_ADDR = 0x36

# Initialize I2C bus
bus = smbus.SMBus(1)

# Open GPIO chip
chip = gpiod.Chip(chipname)

# Get the output lines
out_line = chip.get_line(out_line_offset)
out_line.request(consumer="battery_monitor", type=gpiod.LINE_REQ_DIR_OUT)

buzzer_line = chip.get_line(buzzer_line_offset)
buzzer_line.request(consumer="power_monitor", type=gpiod.LINE_REQ_DIR_OUT)

# Get the input line for power loss detection
pld_line = chip.get_line(pld_line_offset)
pld_line.request(consumer="power_monitor", type=gpiod.LINE_REQ_EV_BOTH_EDGES)

def readVoltage(bus):
    """Reads battery voltage from I2C bus."""
    address = I2C_ADDR
    read = bus.read_word_data(address, 2)
    swapped = struct.unpack("<H", struct.pack(">H", read))[0]
    voltage = swapped * 1.25 / 1000 / 16
    return voltage

def readCapacity(bus):
    """Reads battery capacity from I2C bus."""
    address = I2C_ADDR
    read = bus.read_word_data(address, 4)
    swapped = struct.unpack("<H", struct.pack(">H", read))[0]
    capacity = swapped / 256
    if capacity > 100:
        capacity = 100
    return capacity

def print_power_status():
    """Monitors power status and logs changes."""
    global last_power_state, last_log_time
    state = pld_line.get_value()
    current_time = time.time()

    if state == 1:
        print("Power Supply A/C Lost") # First detection of power loss
        if last_power_state != 1:
            logging.warning("Power Supply A/C Lost")
        elif current_time - last_log_time > LOG_INTERVAL: # Subsequent logging at intervals
            logging.warning("Power Supply A/C Lost")
            last_log_time = current_time

        # Activate buzzer to indicate power loss
        for _ in range(3):  # Buzzer alarm cycle
            buzzer_line.set_value(1)
            time.sleep(0.1)
            buzzer_line.set_value(0)
            time.sleep(0.1)
    else:
        print("AC Power OK")
        if last_power_state != 0: # First detection of power restoration
            logging.info("AC Power OK")
        elif current_time - last_log_time > LOG_INTERVAL: # Subsequent logging at intervals
            logging.info("AC Power OK")
            last_log_time = current_time
        buzzer_line.set_value(0)

    last_power_state = state
    return state


try:
    while True:
        print("******************")
        voltage = readVoltage(bus)
        capacity = readCapacity(bus)
        print(f"Voltage: {voltage:.2f}V")
        print(f"Battery: {capacity:.0f}%")

        # Log battery voltage and capacity at intervals
        if time.time() - last_log_time > LOG_INTERVAL:
            logging.info(f"Voltage: {voltage:.2f}V, Battery: {capacity:.0f}%")
            last_log_time = time.time()

        # Monitor power loss detection
        power_status = print_power_status()

        if capacity == 100:
            print("Battery FULL")

        if capacity < 20:
            print("Battery Low")

        # This condition ensures shutdown only if the battery is below 99% and the power is disconnected.
        # This means that if the power is connected, the server will not shut down.
        # Everyone should evaluate whether this is safe and adjust the condition if necessary.
        if voltage < 3.00 and power_status == 1:
            print("Battery LOW!!!")
            logging.critical("Battery LOW! Shutdown in 10 seconds")
            print("Shutdown in 10 seconds")
            time.sleep(10)
            out_line.set_value(1)
            time.sleep(3)
            out_line.set_value(0)


        time.sleep(2)

except KeyboardInterrupt:
    print("Exiting...")
finally:
    chip.close()

</code>

=== Automatické spuštění po restartu ===

Pro zajištění automatického spuštění skriptu po restartu použijeme **systemd service**, což je spolehlivý způsob, jak zajistit, že skript poběží na pozadí.

== Vytvoření systemd služby ==

Otevřete terminál a vytvořte soubor pro službu:

<code bash>
sudo nano /etc/systemd/system/x728-battery.service
</code>

Do souboru vložte následující obsah a uložte:

<code ini>
[Unit]
Description=X728 Battery Monitor
After=multi-user.target

[Service]
Type=simple
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=null
StandardError=append:/var/log/x728-battery.log

[Install]
WantedBy=multi-user.target
</code>


== Aktivace služby při startu ==

Načtěte systemd a povolte službu při startu:

<code bash>
sudo systemctl daemon-reload
sudo systemctl enable x728-battery.service
</code>

== Okamžité spuštění služby ==

Pro okamžité spuštění služby spusťte:

<code bash>
sudo systemctl start x728-battery.service
</code>

== Kontrola stavu služby ==

Pro ověření, zda služba běží správně, použijte:

<code bash>
sudo systemctl status x728-battery.service
</code>


=== Použití logrotate pro rotaci logů na Raspberry Pi ===

Na Raspberry Pi mi aplikace vytvořila nový logový soubor `/var/log/x728-battery.log`. Abych zajistil jeho pravidelnou rotaci a zabránil nadměrnému růstu, rozhodl jsem se použít **logrotate**. Tento nástroj už byl v systému nainstalován.

== Jak přidat pravidlo do logrotate ==

Nejprve jsem vytvořil nový konfigurační soubor v `/etc/logrotate.d/`:

<code bash>
sudo nano /etc/logrotate.d/x728-battery
</code>

Do souboru jsem přidal následující konfiguraci:

<code>
/var/log/x728-battery.log {                           
        weekly                                        
        rotate 4                                      
        compress                                      
        missingok                                     
        notifempty                                    
        create 644 root root                          
        postrotate                                    
                systemctl restart x728-battery.service
        endscript                                     
}                                                     
</code>

Bylo nutné přidat `postrotate` sekci, která restartuje službu `x728-battery.service`, protože jinak aplikace nepokračovala v logování do nového souboru.

== Otestování konfigurace ==

Pro kontrolu, zda logrotate soubor správně rozpoznává, jsem spustil:

<code bash>
sudo logrotate -d /etc/logrotate.d/x728-battery
</code>

(Debug mód `-d` pouze zobrazí, co by se stalo, ale skutečně rotaci neprovede.)

Pokud konfigurace neobsahovala chyby, provedl jsem ruční rotaci:

<code bash>
sudo logrotate -f /etc/logrotate.d/x728-battery
</code>

Po této úpravě se logy správně rotují a starší soubory jsou automaticky komprimovány a spravovány.



=== Nastavení a čtení RTC času ===

Tento návod popisuje kompletní nastavení a použití RTC (Real Time Clock) na UPS X728. UPS využívá RTC modul pro udržení přesného času i po odpojení napájení. Tento postup byl testován na **Raspberry Pi OS**.

== Povolení RTC modulu ==

1. Otevřete konfigurační soubor `/boot/config.txt` a přidejte na konec nebo pod sekci `[all]` tento řádek:

<code bash>
sudo nano /boot/config.txt
</code>

Přidejte:

<code>
dtoverlay=i2c-rtc,ds1307
</code>

Uložte změny stisknutím **Ctrl+O**, potvrďte **Enter**, a ukončete editor **Ctrl+X**.

2. Restartujte Raspberry Pi:

<code bash>
sudo reboot
</code>



== Zakázání falešného hwclocku ==

Raspberry Pi OS obsahuje **fake-hwclock**, který simuluje RTC a může způsobovat problémy s reálným RTC modulem. Proto je nutné ho odstranit:

<code bash>
sudo apt-get -y remove fake-hwclock
sudo update-rc.d -f fake-hwclock remove
sudo systemctl disable fake-hwclock
</code>

== Úprava udev pravidel ==

Pro správné fungování RTC je třeba upravit soubor `/lib/udev/hwclock-set` a zakomentovat řádky 7-12:

<code bash>
sudo nano /lib/udev/hwclock-set
</code>

Najděte následující část kódu:

<code>
#!/bin/sh
# Reset the System Clock to UTC if the hardware clock from which it
# was copied by the kernel was in localtime.

dev=$1

#if [ -e /run/systemd/system ] ; then
#    exit 0
#fi
#
#/sbin/hwclock --rtc=$dev --systz
#/sbin/hwclock --rtc=$dev --hctosys
</code>

Každý řádek označený `#` je zakomentován a nebude se vykonávat.

Uložte změny a ukončete editor.

== Ověření a nastavení času ==

Po dokončení výše uvedených kroků restartujte Raspberry Pi:

<code bash>
sudo reboot
</code>

Po restartu můžete ověřit aktuální systémový čas:

<code bash>
date
</code>

Pokud je čas nesprávný, nastavte ho ručně:

<code bash>
date -s "5 MAR 2019 13:00:00"
</code>

Uložte nastavený čas do RTC:

<code bash>
sudo hwclock -w
</code>

Pro ověření času uloženého v RTC modulu použijte:

<code bash>
sudo hwclock -r
</code>

**Poznámka:** Ujistěte se, že jsou v UPS X728 vloženy baterie, aby se uložený čas zachoval i po vypnutí zařízení.

Po dokončení tohoto postupu bude při každém startu Raspberry Pi čas automaticky synchronizován z RTC modulu.


=== Možné problémy a jejich řešení ===

Tato sekce popisuje možné problémy při používání UPS X728 a jejich řešení. Informace čerpám z oficiální dokumentace výrobce:  
[Zdroj: Geekworm Wiki - X728 FAQ](https://wiki.geekworm.com/X728#FAQ)

__Problém: Zobrazuje se hláška „This power supply is not capable of supplying 5A“ na Raspberry Pi 5__

UPS X728/X729 má dostatečnou kapacitu pro napájení **5A**, nicméně je potřeba provést následující nastavení:

**Krok 1: Úprava konfigurace napájení (povinné)**

Otevřete terminál v Raspberry Pi OS a spusťte příkaz:

<code bash>
sudo rpi-eeprom-config -e
</code>

Na konec souboru přidejte následující řádek:

<code>
PSU_MAX_CURRENT=5000
</code>

Uložte změny stisknutím **Ctrl+O**, potvrďte klávesou **Enter**, a ukončete editor stisknutím **Ctrl+X**.

**Krok 2: Zvýšení proudového limitu USB (volitelné, pokud používáte USB zařízení s vyšší spotřebou)**

Otevřete konfigurační soubor:

<code bash>
sudo nano /boot/firmware/config.txt
</code>

Přidejte tento řádek:

<code>
usb_max_current_enable=1
</code>

Uložte změny a zavřete editor stejným způsobem jako v předchozím kroku.

**Restartujte Raspberry Pi, aby se změny projevily:**

<code bash>
sudo reboot
</code>

**Poznámka:** Pokud používáte jiný operační systém (například Ubuntu), je nutné nejprve nahrát Raspberry Pi OS, provést výše uvedené úpravy a teprve poté znovu nahrát požadovaný operační systém.


=== Softwarové řízení nabíjení pomocí GPIO16 ===

Od verze **X728 v2.5** je možné **softwarově řídit nabíjení baterie** pomocí **GPIO16**. Tato funkce je určena pouze pro **pokročilé uživatele**, kteří mají zkušenosti s Linuxem. Pokud si nejste jisti, doporučuje se ponechat jumper "CHG Ctrl" zkratovaný, což umožní **automatické nabíjení** při připojení napájecího adaptéru.

**Možnosti nastavení "CHG Ctrl" jumperu:**
- **Jumper zkratovaný** → Baterie se **automaticky nabíjí**, pokud je připojen napájecí adaptér.
- **Jumper otevřený** → Nabíjení lze **ovládat přes GPIO16**:
  - **GPIO16 = HIGH** → Nabíjení povoleno.
  - **GPIO16 = LOW** → Nabíjení zakázáno.

== Ovládání nabíjení pomocí GPIO16 ==

Pro ruční ovládání nabíjení je nutné nejprve zjistit odpovídající GPIO pin:

<code bash>
GPIO=16

# Zjištění skutečného čísla GPIO pinu
GPIO=$(cat /sys/kernel/debug/gpio | grep "GPIO$GPIO" | awk -F'gpio-' '{print $2}' | awk -F' ' '{print $1}')
echo "$GPIO" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio$GPIO/direction
</code>

**Povolení nabíjení:**
<code bash>
echo "1" > /sys/class/gpio/gpio$GPIO/value
</code>

**Zakázání nabíjení:**
<code bash>
echo "0" > /sys/class/gpio/gpio$GPIO/value
</code>

**Poznámka:** Nakonec jsem tuto funkci **nevyužil**, ale uvádím ji pro **kompletní dokumentaci**, pokud by bylo v budoucnu potřeba řídit nabíjení softwarově.



===== Konfigurace softwarového RAIDu – zrcadlení =====

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ů.

Na desce jsou viditelně označeny dva sloty:
  * **SSD1**
  * **SSD2**

Při připojení jednoho disku do **SSD1**, systém jej rozpozná jako **nvme0n1**:

<code bash>
lsblk 
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 /
</code>

Po připojení druhého disku do **SSD2** došlo k nečekanému přeskupení číslování disků. Systém nyní rozpoznává:

* Disk připojený v **SSD2** jako **nvme0n1**
* Disk připojený v **SSD1** jako **nvme1n1**

Výstup příkazu `lsblk` po připojení druhého disku:

<code bash>
lsblk 
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0  1,8T  0 disk 
nvme1n1     259:1    0  1,8T  0 disk 
├─nvme1n1p1 259:2    0  512M  0 part /boot/firmware
└─nvme1n1p2 259:3    0  1,8T  0 part /
</code>

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