Prosíme přihlašte se nebo zaregistrujte.

Přihlašte se svým uživatelským jménem a heslem.
Vaše pomoc je stále potřeba!

Autor Téma: Problem plne boot parition...  (Přečteno 2913 krát)

miro_

  • Aktivní člen
  • *
  • Příspěvků: 238
Problem plne boot parition...
« kdy: 18 Března 2024, 13:09:07 »
Na RPI4 v SSD s U22-mate bylo pri jeho instalaci automaticky, vytvoreno 'boot' partition FAT32 255Mb.
Vlivem ruznych pokusu a predchozich aktualizaci tam nyni dochazi misto.
Je tam jiz pouze 16MB volnych, coz se zrejme projevilo pri pokusu o aktualizaci:
E: linux-firmware: podproces skript z instalovaného balíku linux-firmware: post-installation vrátil chybový návratový stav 1
E: linux-image-raspi: problém se závislostmi - nechávám nezkonfigurované


Zkusil jsem boot vycistit sudo 'apt-get autoremove --purge' ale proces skoncil rovnez chybou.
Dle prubehu procesu cisteni, bylo neco vymazano ale vypada to, jako by adresar oddilu byl poskozen.
  viz v logu:
  depmod: WARNING: could not open modules.order at /var/tmp/mkinitramfs_qLsUG1/lib/modules/5.15.0-1043-raspi: No such file or directory

Na RPI4 mi bezi server 'Mosquitto' a tak bych nechtel opravou zpusobit,
v pripade nejakych vetsich problemu nebo pripadne zkouceni systemu, jeho delsi odstavku .

Napada mne nasledujici postup:
   V zrejme poskozenem adresarovem systemu
     mohou byt zabrane neuzivane oblasti. Zkusit 'boot' jeho SSD opravit v jinem PC
     a zkusit znovu spustit cisteni ?
  V jinem PC zmensit EXT4 se systemem a rozsirit 'boot' oddil pres Gparted.
     (Nevim, zda nefunkcni boot lze stale opravovat, jako kdysi jeste u Ubuntu10 atd.)   
  Uvazuji i zakoupeni noveho SSD, a nove instalaci. Ale to mi prijde prilis narocne.
     Spoustu dulezitych uprav instalace, ktere jsem musel udelat si jiz nepamatuji.

Mam zde instalovan 'timeshift' nekolik zaloh od 20.10.2023 az do 21.1.2024.
Bohuzel pri obnovach zustavaji v systemu ruzne baliky, ktere jsem musel
rucne mazat.
Zrejme pokusy instalaci cpou neco i do 'boot' oddilu, protoze bylo videt,
ze byly mazany zde v boot 'libruby3.0:arm64 ...', ktere tam nacpal
nefunkcni pokus instalace na RPI4 'gimagereader' viz. priloha.

Zajimal by mne Vas nazor, co s tim.


Ventero

  • Závislák
  • ***
  • Příspěvků: 3650
Re:Problem plne boot parition...
« Odpověď #1 kdy: 18 Března 2024, 15:27:18 »
Pripoj ten oddil a mrkni, co v nem je a pripadne smeti vymaz rucne - nemel by to byt boot oddil (to je nejaka haluz), ale ESP a tam ma byt jenom zavadec a pripadne nejaky konfigurak.

Jestli jsi si vytvoril /boot oddil jako fat32 255MB, tak jsi udelal chybu. Boot oddil by mel byt alespon nekolik giga a ext, bo tam se sypou aj jadra ...
Zvuky jsou mantrami a myšlenky moudrostí, prostě proto, že se mohou objevovat ...

miro_

  • Aktivní člen
  • *
  • Příspěvků: 238
Re:Problem plne boot parition...
« Odpověď #2 kdy: 18 Března 2024, 17:15:14 »
Bohuzel instalace na RPI4 (Raspberry) nelze provadet jako na std. PC !
HW system ma procesor ARM, a tedy neexistuji nektere aplikace dostupne pro bezne PC.
Zavadec na HW desce bootuje bezne z SD karty. U teto novejsi verze HW  jej lze modifikovat pro
boot primo z pripojeneho SSD na USB. Primy boot z USB na RPI4 podporuje az verze U22-mate. 
Vzpominam si, ze jsem pri instalaci naplnil  SSD primo instalacnim image U22mate na  beznem PC.
Teprve po jeho pripojeni k RPI4 byl spusten proces instalace U22mate  .
Nevidel jsem v teto fazi moznost pracovat s oddily. Az v 'rozinstalovanem' stavu jsem  vytvarel z oddilu EXT4,
ktery byl pres cele SSD, na konci oddil pro zalohy na beznem PC. Pri teto uprave mne nenapadlo zvetsit
boot oddil. Predpokladal jsem, ze by se sem nemelo nic ukladat.

Mam zkusenost se starsim HW Raspberry z roku 2017.  Tento HW  bootuje  jen z SD karty !
Na SD karte je take zavadec s FAT32, ktery muze spoustet nejaky system na SSD.
Obcas se do oddilu boot na SD karte neco zapsalo a system SD karty byl poskozen.
Od 2017,  kdy se uzival tento starsi  Raspberry s U16-mate jako terminal pro pristupy na weby k TV,
se to stalo asi  5x. Nekdy stacila jen oprava souboroveho  systemu  SD karty,  nekdy bylo nutne prepsat
instalacnim image.



Ventero

  • Závislák
  • ***
  • Příspěvků: 3650
Re:Problem plne boot parition...
« Odpověď #3 kdy: 18 Března 2024, 21:23:40 »
Tak to promin - nevsiml jsem si, ze jde o tyhle arm strojky. S tim zkusenost nemam a chapu, ze jsou tam omezeni. I kdyz vpastne moc nechapu - povazuji to za vyvojarsky nedotah - nevim, proc to nemuze standardni instalacni koncepce - i ten ujetej Apple se alespon hrube toho drzel a instalacni procedura mela nejakou hlavu a patu.
Udelat strojek, kde musis kopirovat obrazy je na hlavu postaveny upadek. Osobne bych si Malinu nekoupil - sel bych v armu spis do Firefly, kde je mozny multiboot na podobne bazi jako u Mac ..

Ale s tim rucnim vycistenim oddilu a pak zkusit preskupit a rozsirit - to zkusit muzes. I kdyz to bude babracka ..
« Poslední změna: 18 Března 2024, 21:26:41 od Ventero »
Zvuky jsou mantrami a myšlenky moudrostí, prostě proto, že se mohou objevovat ...

Roman Vacho

  • Moderátor
  • Závislák
  • ***
  • Příspěvků: 6162
Re:Problem plne boot parition...
« Odpověď #4 kdy: 19 Března 2024, 07:46:34 »
Trošku se tu motá terminologie.
/boot je prostě buď oddíl nebo adresář někam směrovaný.
Ale může to být i /boot/efi a další dle nastavení distribuce. Ano, je to dneska decentně komplikovanější.
ESP je FATxx oddíl zpravidla sdílený mezi OS, který takový mountpoint většinou obsahuje.
Čili když si otevřete adresář /boot, jste ve FAT32 oddíle. Takže oba tvrdíte to samé jinou terminologií.

Kód: [Vybrat]
lsblk --fs
NAME   FSTYPE FSVER LABEL          UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                   
├─sda1 vfat   FAT32                xxxx-xxxx                             453M      11% /boot/efi

mount -l | grep /boot
/dev/sdxx on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)

df -h | grep /boot
/dev/sdxx            511M   58M  454M  12% /boot/efi
Teď nevím proč mi to u df -h nepíše druh hodnot. Když to použiju bez grep, tak to vypíše.
Kód: [Vybrat]
df -hlT
Souborový systém Typ      Velikost Užito Volno Uži% Připojeno do
efivarfs         efivarfs     128K   46K   78K  37% /sys/firmware/efi/efivars
/dev/sdxx        vfat         511M   58M  454M  12% /boot/efi
Proč doporučuji věnovat pozornost volnému místu. Stalo se mi, ale už nevím proč, že se uváděné alokované místo uvádělo chybně daným nástrojem.
Všimněte si také, že se mi u této distribuce vypisuje nikoliv /boot, ale /boot/efi.

Proto si vyžádám přímý výpis.
Kód: [Vybrat]
df -hlTa /boot
Souborový systém Typ   Velikost Užito Volno Uži% Připojeno do
/dev/sdxx        btrfs      32G   11G   22G  33% /
A zjistím z toho, že je to jen adresář jež má sdílené místo s kořenem /.

Nejsem si teď jistý, když nepoužiju specializovaný nástroj a smažu si nějaké soubory v EFI adresáři, zda se smažou i v "BIOSe". Ale klidně to zkusím.
« Poslední změna: 19 Března 2024, 08:09:31 od Roman Vacho »
Vyřešená vlákna je vhodné uzavřít "Topic Solved" dole pod vláknem.

Prosím označit text kódu v editoru # pro lepší formátování textu případného výpisu. Děkuji.

Roman Vacho

  • Moderátor
  • Závislák
  • ***
  • Příspěvků: 6162
Re:Problem plne boot parition...
« Odpověď #5 kdy: 19 Března 2024, 08:24:03 »
https://www.cyberciti.biz/faq/ubuntu-18-04-remove-all-unused-old-kernels/
Hledej slova purge-old-kernels. Vypadá to na dost užitečný skript. Až budu na *buntu, tak se tomu musím podívat na zoubek.
Kód: [Vybrat]
sudo apt install byobu[/s]
Neplatí, protože je to nějaké upravené Ubuntu na Malinu.
« Poslední změna: 19 Března 2024, 13:43:28 od Roman Vacho »
Vyřešená vlákna je vhodné uzavřít "Topic Solved" dole pod vláknem.

Prosím označit text kódu v editoru # pro lepší formátování textu případného výpisu. Děkuji.

radin

  • Aktivní člen
  • *
  • Příspěvků: 245
Re:Problem plne boot parition...
« Odpověď #6 kdy: 19 Března 2024, 10:13:27 »
Nemyslím si, že by RPi používalo EFI, ale nevím, už mi nějakou dobu leží v šuplíku. Přeplnění /boot bývá způsobeno aktualizacemi jádra, která se prostě jen přidají a grub se přesměruje na nové. Staré tam zůstává pro možnost vrátit se k němu v případě potíží. Takže já bych SD kartu z RPi vrazil do stolního PC/notebooku, otevřel ji jako root a vymazal stará jádra s výjimkou posledního - pokud funguje bez problémů. V podstatě se jedná o soubory lišící se jen číslem, např. vmlinuz-6.1.0-18xxx a ostatní se stejným číslem bych ponechal, všechny s nižším číslem vymazat. Kartu pak vrátit do RPi a v terminálu spustit
Kód: [Vybrat]
sudo update-grub čímž se odstraní odkazy na dřívější jádra.
Vycházím ze zkušenosti s manželčiným NB, který má jen 32GB SSD a nedostatek místa bývá častým problémem.

Edit:
Omlouvám se, ale teď jsem se díval do starých image Raspbianu a tam jsou v /boot jiné soubory. Ovšem nějaký "kernel7" tam je, takže pokud jich tam bude více, mohlo by to fungovat. Jak jsem psal, už jsem malinu delší dobu nepoužíval a navíc jsem to řešil úplně jinak: nabootoval do Raspbianu a pak instaloval debian pro ARM na připojený flash disk. Ono provozovat malinu čistě z SD karty je sebevražda vzhledem k častým zápisům dlouho nevydrží a je potřeba mít několik kopií systemu v zásobě. Se systémem na flashce stačila SD karta 250 MB jen pro boot a dál vše běželo z flashky.
« Poslední změna: 19 Března 2024, 10:41:27 od radin »
Nobody is perfect!

ramael

  • Stálý člen
  • **
  • Příspěvků: 687
Re:Problem plne boot parition...
« Odpověď #7 kdy: 19 Března 2024, 11:48:59 »
Pokud si dobře pamatuju tak RPI nepoužívá GRUB. Správa boot RPI je jednoduchá, možná i jednodušší než ESP na klasickém PC. Stačí smazat staré jádra a basta.
Na co bych si dal bacha je, jaké jádro tam nechat. Předem píšu, že RPI4 nemám, Mám předchozí modely(několik let někde v šuplíku) a pak novější RPI5. Myslím, že od verze RPI4 není podporován U-BOOT. Na RPI5 na 100% nejde. Respetive, ještě před měsícem nešlo. Avšak RPI foundation vydává přímo bootovatelná jádra. A tak stačilo z /boot smazat u-boots, jádro distribuce a nahradit to jádrem RPI. Nevím jak by to fungovalo s Ubuntu, protože to používá "vlastní" opachtovaná jádra. Avšak i Ubuntí jádro pro RPI by to mělo zvládnout samo.

@miro_ můžeš si část ssd nakopírovat na sd kartu. Odpojit ssd, bootnout z sd. Na sd si smazat co chceš a zkoušet bootovat. Pakliže budeš mít uvolněné místo s funkčním bootem jednoduše tím přepiš boot na ssd a hotovo.

@Ventero, není to nedodělek. Jde o trend kde se přechází z MBR na UEFI. To jen Ubuntu, z pro mě známých (odzkoušených) distribucí, z bezpečnostního hlediska neumožňuje instalaci jader na FAT. Což je věc která se mi na Ubuntu líbí. Jen je to dvojsečné. Díky tomu se musí Ubuntu držet GRUBu a tím přechod na ESP není jednoduchý. Zkrátka a protože GRUB. Vzhledem k návrhu GRUBu to tipuju na vydání GRUB3 verze. Jinak to bude záplata na záplatě. Avšak, není problém to jádro na oddíl FAT přesunout a odtud normálně bootovat.

Trošku se tu motá terminologie.
/boot je prostě buď oddíl nebo adresář někam směrovaný.
Ale může to být i /boot/efi a další dle nastavení distribuce. Ano, je to dneska decentně komplikovanější.
ESP je FATxx oddíl zpravidla sdílený mezi OS, který takový mountpoint většinou obsahuje.
Čili když si otevřete adresář /boot, jste ve FAT32 oddíle. Takže oba tvrdíte to samé jinou terminologií.

Kód: [Vybrat]
lsblk --fs
NAME   FSTYPE FSVER LABEL          UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                   
├─sda1 vfat   FAT32                xxxx-xxxx                             453M      11% /boot/efi

mount -l | grep /boot
/dev/sdxx on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)

df -h | grep /boot
/dev/sdxx            511M   58M  454M  12% /boot/efi
Teď nevím proč mi to u df -h nepíše druh hodnot. Když to použiju bez grep, tak to vypíše.
Kód: [Vybrat]
df -hlT
Souborový systém Typ      Velikost Užito Volno Uži% Připojeno do
efivarfs         efivarfs     128K   46K   78K  37% /sys/firmware/efi/efivars
/dev/sdxx        vfat         511M   58M  454M  12% /boot/efi
Proč doporučuji věnovat pozornost volnému místu. Stalo se mi, ale už nevím proč, že se uváděné alokované místo uvádělo chybně daným nástrojem.
Všimněte si také, že se mi u této distribuce vypisuje nikoliv /boot, ale /boot/efi.

Proto si vyžádám přímý výpis.
Kód: [Vybrat]
df -hlTa /boot
Souborový systém Typ   Velikost Užito Volno Uži% Připojeno do
/dev/sdxx        btrfs      32G   11G   22G  33% /
A zjistím z toho, že je to jen adresář jež má sdílené místo s kořenem /.

Nejsem si teď jistý, když nepoužiju specializovaný nástroj a smažu si nějaké soubory v EFI adresáři, zda se smažou i v "BIOSe". Ale klidně to zkusím.
To je protože používáš UEFI. Ubuntu má standardně /boot jako EXT. Jinak máš pravdu.

Snad se mi podaří něco na to téma příští měsíc napsat.
Jen chci ještě vyzdvihnout jednu setsakra nespornou výhodu UEFI. Správa je neskutečně jednoduchá. Nemusí  se volat grub update a podobný ptákoviny. Zkrátka se přesune jádro a jupí jede se dál.
Veliké minus je velikost. Protože z dle specifikace UEFI musí být FAT a proto nelze tam mít softlinky. A proto musí být jádro/a umístěny přímo tam. Ale můžou se v pohodě strukturovat do složek.
Lenovo: ThinkPad X380 Yoga
Joutůůůůb

Roman Vacho

  • Moderátor
  • Závislák
  • ***
  • Příspěvků: 6162
Re:Problem plne boot parition...
« Odpověď #8 kdy: 19 Března 2024, 13:47:24 »
Problém s místem? No to se teprv rozjede s těmi immutable věcmi. Izolací na izolaci.
Vyřešená vlákna je vhodné uzavřít "Topic Solved" dole pod vláknem.

Prosím označit text kódu v editoru # pro lepší formátování textu případného výpisu. Děkuji.

 

Provoz zaštiťuje spolek OpenAlt.