malý boot

23.1.2024 12:14 | Přečteno: 861× | poslední úprava: 1.2.2024 10:28

Když jsem před asi deseti léty začínal s archlinuxem, byla doporučená velikost pro oddíl /boot minimálně 100MB. Řekl jsem si tenkrát běhěm dělení disku že nechám rači rezervu a udělal jsem ho 200MB veliký. Pokrok ale nezastavíš, jádro nám za ty roky hezky nakynulo. Až se mi dneska při přechodu z 6.6 ma 6.7 konečně objevila hláška:

zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
zstd: error 70 : Write error : cannot write block : No space left on device

Systémový disk mám rozdělěný na dva oddíly

fdisk -l /dev/sda
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: MB1000GCEEK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf992b201

Device     Boot  Start        End    Sectors   Size Id Type
/dev/sda1  *      2048     411647     409600   200M 83 Linux
/dev/sda2       411648 1953525167 1953113520 931.3G 83 Linux

Nemám moc odvahu na živém systému šachovat s oddílama protože nemám v rukávu žádné záložní řešení kdyby se něco podělalo. Tak první co mě napadlo bylo zakázat fallback image který je nevímproč třikrát větší jak obyčejný initramfs image který je 39MB velký. Z toho ale taky nemám zrovna pocit sucha a bezpečí, fallback jsem už párkrát potřeboval. Na archwiki jsem nakonec našel pár možností komprese

COMPRESSION_OPTIONS=(-v -5 --long)

S touto volbou se mi to tam už vleze, dokonce tam ještě zůstane celých 5MB volného místa. Co budu ale dělat příště to netuším. Nedělám si moc iluze že by se mohlo v budoucnosti jádro zmenšovat.

UPDATE: Nakonec se ukázalo že za to může KMS. Nejvíc tím prý trpí uživatelé nvidia karet, no já mám radeon a když jsem zakázal kms pro fallback image, tak se tento zmenšil skoro třikrát. Stačí upravit /etc/mkinitcpio.d/linux.preset na:

fallback_options="-S autodetect -S kms"

       

Komentáře

[vlastikroot]

Pustit si nejaky live CD s gparted a ten to hrave zvetsi.

[karkar]

Ale velmi silně doporučuji zálohu, ten gparted to sice hravě zvětší, ale taky to může hravě doyebat.

[disorder]

Staci ubrat od konca a tam spravit novy boot... alebo zlucit boot s / ak to nie je sifrovane.

[karkar]

Ano a to je přesně to, co třeba ten systém může velmi pěkně doyebat :)

[jejda]

Šifrované to bohužel je. Na konci taky místo není.

[Max]

Ty ale ten /dev/sda1 nemusíš používat. Evidentně nejedeš UEFI, ale legacy boot. Stačí dát bootlfag na /dev/sda2, zrušit mount "/dev/sda1 /boot" a překopírovat obsah /dev/sda1 do /boot a případně ještě zkontroloval, jak je nastaven grub. Neměl by pak být problém.
Zdar Max

[jejda]

Ano jedná se o legacy BIOS. Jsem zapomněl zmínit že ten /dev/sda2 je šifrovaný luksem stejně jako všecky ostatní disky, takže by grub neviděl jádro. Dobrovolně bych ten disk asi nedělil. Volné nešifrované místo nikde bohužel nemám. Ještě mě tak napadá jestli by nešel ten /boot nouzově připojit na nějakou starou flešku. Tady ale nevím jestli by grub na té flešce musel být taky nebo jestli by grub co je nainstalovaný na harddisku dokázal natáhnout z flešky jenom jádro. Začíná se mi taky hlavou honit myšlénka na nový disk. Co tak čtu diskuze tak mi připadá, že jsem ve střední evropě z posleních kdo nikdy neměl SSD.

[Max]

Záleží, co máš za LUKS. Grub2 umí LUKS2 s PBKDF2. To, co neumí, je Argon2. Na to existuje patch, ale ten zase podporuje jen UEFI.
Takže spoustu podmínek a kliček. Kdybych byl líný, tak bych generování failback vypnul a v případě problémů prostě použil místo fallback kernelu nějakou flashku s clonezillou, system rescue apod.
Osobně mám ale doma spoustu plonkových disků, jak 2TB, tak 4TB disky. Takže bych si zahrál asi na přelévací kolečko a čistěji si rozložil disk a přešel i na UEFI.
Zdar Max

[vencour]

To přece blbne jen při generování, ne? Tak dočasně použít /boot jako část kořene a pak překopírovat na /dev/sda1, navíc v gentoo si můžu určit v kernelu čim komprimovat.
Neni to cesta?

[jejda]

Jako že se do /boot odkládají nějaké dočasné soubory které se potom smažou a nahradí se až hotovým obrazem? To se mi nějak nezdá. Na to je přece /tmp nebo přímo RAM. Ty volby komprese a dalších věcí se na archu nastavujou v konfiguráku /etc/mkinitcpio.conf Takto bych to musel při každém update ručně hlídat a to se mi jednak nechce a hlavně nikde není záruka že bych na to třeba někdy nezapomněl.

[k3dAR]

nevim jak na Archu, ale minimalne na *buntu to funguje pri update-initramfs takto:
- aktualni X zduplikuje do X.dpkg-bak
- novej pripravuje do X.new
- kdyz je novej hotovej presune X.new do X a smaze X.dpkg-bak
=> pri priprave je potreba misto na +2ks

[Martin Tůma]

Tak první co mě napadlo bylo zakázat fallback image který je nevímproč třikrát větší jak obyčejný initramfs image který je 39MB velký. Z toho ale taky nemám zrovna pocit sucha a bezpečí, fallback jsem už párkrát potřeboval.

Já třeba fallback image ani nemám v LILO uvedený, když se mi podaří boot rozbít, prostě šáhnu do šuplíku pro instalační flashku ArchLinuxu a nabootuju z ní. Než šachovat s filesystémem, rozhodně bych radši vypnul ten fallback.

[jejda]

Jo takto to nejspíš nakonec udělám. Minimálně do doby než bude nový disk.

[vencour]

Mimochodem anketa na počet boot záznamů.

[RealJ]

v dobe TB disku davam 1Gb...

[jejda]

Jo dneska už taky nechávám víc no tenkrát to byla moje první, víceméně pokusná instalace archu a ve snu by mě nenapadlo že ten systém vydrží tak dlouho. Předtím jsem si hrál s debianem ale ten se mi běhěm pár měsíců různýma experimentama podařilo úplně zabít.

[Heretik 《小魔神》]

Když jsem ještě míval Gentoo, tak jsem u toho často používal /boot s grubem na flashdisku eventuelně CF kartě eventuelně menším (64G) ssd. Právě z toho důvodu, by se bootování dalo snadno upravovat a zachraňovat bez dalšího vlivu na celý zbývající systém.

Schovaných i speciálních jader jsem na tom měl tucty. Kopie jsou v takovém případě triviální.

[Jendа]

Na Debianu doporučuji navštívit /etc/initramfs-tools/initramfs.conf a změnit MODULES=most na MODULES=dep. Defaultně se do initramdisku dávají všemožné moduly včetně síťovek (i když síť v initramdisku nevyžadujete), tohle zmenší velikost tak na polovinu. Nedělám to ani tak kvůli místu, ale protože se velký initramdisk pomalu generuje a pomalu bootuje.

Možná bude v Archu něco podobného, a ten fallback image trpí tímto?

[jejda]

Vypadá to že to na archu trochu tunit jde. Budu si to muset lehce nastudovat.

[Valgrind]

Kup za litr novy disk a preinstaluj to.

[pavel]

a toto si čítal?

[jejda]

Ha! To je přesně ono. Docela mě zachránils. Upravil jsem trochu zápisek. Dík moc!