se stock nastavenim tezko, protoze 2 jadra+initramfs + 1 grub = 286MB ;-)
ja davam (pokud oddelim od rootfs) /boot 2GB (protoze krome stock jadra i UbuntuKernelMainline jadra kvuli mozne hibernaci se SecureBoot
a EFI take 2GB (protoze sicherboot@systemd-boot misto Grub)
kde mam mene z historickych duvodu (nebo mi nevadi pri update initrramfs zatizeni vsech jader, vetraku a delsi cas), zapinam pro initramfs kompresi XZ
Jednak proto, ze je dobre ho nemit bydefault pripojeny, dale proto, ze kdyz se neco podela, je to oddeleny FS = nejak to nastartuje alespon do nejakeho rezimu kdy se s tim da neco delat, dal se typicky na /boot pouziva nejaky jednodussi fs, opet predevsim proto, aby tech moznosti co se podela bylo co nejmene atd atd atd.
To znie rozumne, ale este som nevidel distribuciu, ktora by realne nechavala odpojeny boot.
Ono aj subvolume je samostatny filesystem, akurat alokuje priestor zo spolocneho poolu s ostatnymi subvolumes. V pripade, ze je disk tak hodne posahany, ze system nenabootuje, je aj tak lepsie nabootovat externy system.
Napriklad: Fedora, RH/CentOS/Alma, Debian, Ubuntu...
Ja nepoznam ziadny, kde by bol odpojeny. Jediny, co sa vzdialene priblizuje je Proxmox, ked bootuje cez UEFI a ma root na ZFS. Vtedy pouziva systemd-boot a jadro s initrd umiesni do ESP. A tych ESP ma tolko, kolko ma diskov ZFS, takze si ich synchronizuje.
Teraz sa nevyjadrujem k teme, ale k SSD a opotrebovanie citanim.
Ano, pri citani SSD sa opotrebovava bunka NAND. Nie v takej miere ako pri zapise, ale predsa. A netvrdim, ze pri beznom citani bootovani kernelu to bude mat nejaky prakticky dopad pocas celej zivotnosti SSD, ale len to, ze takyto jav na fyzickej urovni existuje.
Jeden efekt je Read Disturb:
Napr. Y. Cai, Y. Luo, S. Ghose and O. Mutlu, "Read Disturb Errors in MLC NAND Flash Memory: Characterization, Mitigation, and Recovery," (https://users.ece.cmu.edu/~omutlu/pub/flash-read-disturb-errors_dsn15.pdf)
> Abstract—NAND flash memory reliability continues to degrade as the memory is scaled down and more bits are programmed per cell. A key contributor to this reduced reliability is read disturb, where a read to one row of cells impacts the threshold voltages of unread flash cells in different rows of the same block. Such disturbances may shift the threshold voltages of these unread cells to different logical states than originally programmed, leading to read errors that hurt endurance.
A co je to za posahanou distribuci, ze do initramfs musi cpat VSECHNY moduly? Za mych mladych let se tam davala podmnoniza modulu nutna k bootu.. zbytek si zevlil a doposud zevli klidne v /lib/modules/
U Gentoo mam ted ernel 12.8MB a initramfs 6.75 MB.. (takze na 128MB se jich nekolik vejde) - ale i v tom malem initramfs je mini-distro, kterym sem tam opravuji boot kdyz se prenos mezi disky a pocitaci uplne nepovede.
Co ma HW spolecnyho s tim, jestli se nacte z disku kernel? V dobe kdy se nacitaji mofuly je davno primountovany /. Takze ano, je to posahane.
Ostatne nastartovat se da porad i z MBR, a neprekvapive stale existujou bootloadery, ktere se tam i cele vejdou (tzn nikoli grub2). Proc by mel nekdo vyrabet gigabajtove partysny jen proto, aby system jednou za 100let nastartoval?
Ono se nam z toho initramfs nacita treba ovladac disku, sw raid, dm_crypt... a dalsi veci, bez kterych ten root jaksi ani nenamountujete, ze? ;-) Ne, ono se to opravdu necpe natvrdo do vmlinuz (aneb proc by tam mel natvrdo strasit treba ovladac pro megaraid, kdyz mam disky jen na ahci, ze?). Ano, initramfs jde zmensit - a pisu to vyse, ale vzdycky je to neco za neco.
Ten jeden ovladac pro sata, ktery je navic typicky soucasti kernelu ... bavime se o nekolika malo kB. Lidi kteri pouzivaji nejaky obskurni HW a potrebuji obskurni modul(y) je tisicina promile.
Schvalne ...otevrel sem nahodnou instanci, kompletni vse /boot pro jednu verzi kernelu ... 12MB, takze do 100MB partysny dam 8 verzi jadra. A to se vubec nijak nesnazim to zmensovat, ve skutecnosti by se to nejspis dalo bez jakyhkoli problemu zredukovat na pulku, aniz bych u toho musel zvlast premyslet, protoze tam bude hromada veci ktere vubec nepouzivam.
Ehm ... kdys naposledy videl nejaky HW? Nebo konfiguraci kernelu? Zadne chipsety tam nejsou. Sata je standard a vsude se pouziva stejny jeden modul.
Mam doma stroj, na tom kompiluju kernel bez toho abych zasahoval do konfigurace ... nekdy od dob athlonu. Je to porad, protoze sem linej to predelavat a vlastne k tomu neni duvod ... 32bit. Tudiz kdyz vemu cokoli x86, nastartuje to na tom. Zadny stovky MB kvuli tomu nepotrebuju.
Naopak, mohl bych to vyrazne zredukovat, protoze v tom sou zakompilovany veci, ktery pro start vubec nejsou nutny. Ale jak sem rek, neresim to, konfigurace vychazi z distribucniho defaultu v dobe nasazeni.
Mozna jediny co se na tom v prubehu castu menilo, bylo to, ze puvodne se pro pata pouzival jiny kod, ktery byl nasledne reimplementovan vramci sata.
Kdyz ono radice nejsou jen univerzalni AHCI :-) Jen v ramci SATA subsystemu mate hromadu dalsich atypu, o SCSI/SAS nemluve (plus obcas nejake ty zavislosti), bootovat muzete treba i z MMC, MTD... a nedejboze i ze site. Ne, ten ovladac fakt neni jen jeden... to jen predvadite, jak moc Linuxovy kernel neznate :-)
Zpusoby, jak zmensit initramfs zde popsane take mate, pokud se vam ty defaulty univerzalne zacilenyc distribuci nelibi. To, ze je ma neco nejake vychozi nastaveni fakt neimplikuje povinnost to pouzivat tak, jak to v distribuci upekli. Nebo snad mate problem s editaci konfiguraku v /etc? ;-)
Nikoli, to ty jen predvadis, jak moc netusis o cem je rec. Rec byla vyhradne o sata, a zvasty byly o tom, ze pro kazdy chipset je potreba dalsi kus kodu a proto toho musi byt stovky MB. Sata je ostatne podmnozinou sas a cele to vychazi z scsi. Je to jeden kus kodu. V kernelu jsou moduly pro ruzne specificke radice, ale ty potrebuje ta tisicina promile lidi. A i na nich v 90% pro zakladni fukcnost ten modul vubec netreba.
Nehlede na to, ze kazdej jeden kus HW umi stale nastartovat z MBR, coz kdybys tusil jak funguje, tak vis, ze na to naprosto zadny ovladace nejsou treba. Funguje to totiz jednoduse a primitivne tak, ze primo HW nacte tech prvnich par B z prvniho disku a spusti je. A to co se spusti typicky neudela nic jinyho, nez ze to precte z disku dalsi kus kodu a ten spusti taky. Pricemz ze vsech disku se cte kupodivu porad stejne - po sektorech.
Jinak receno, kdyz na to prijde, nepotrebuju mit na disku zadnej fs, proste tam nasypu nejakou hromadu bajtu a ty spustim. A bude to fungovat.
Nikoliv, uz davno mate HW, kde si bez EFI neuprdnete a z MBR klasickym prectenim nulteho sektoru z disku to proste nebootne. V initrd mate i dalsi veci - treba i CPU microcode, ktery je zahodno zavadet co mozna nejdriv. A uz davno se nebootuje jen ze SATA, ono mame nejaky ten patecek i NVMe, ze? ;-) Ale chapu, ze k vam na venkov asi tyhle moderni vymozenosti este nedosly. Ono je to kilobajtik ke kilobajtiku a proste to pribyva. A statistiku, kolik lidi co (ne)pouziva, tak si prosim nechte ty vase vycucany promile od cesty ;-)
@RDa
ne ze se tam prihodi cela kopie z /lib/modules</b>
1. ta vychozi volba MODULES=most ale NEprihodi cele /lib/modules
2. i s rootfs na disku muze byt potreba v initrd podpora lan, napr. pro remote unlock luks v kterem ten rootfs je ;-)
jinak to je porad dokola, je nejaka vychozi volba ktera ma sirsi zaber vyuziti a vyroji se banda chytraku ze je to zbytecne, velke atd a ze oni pouzivaji neco s zlomkovou velikosti... to je nejaka uchylka nebo opravdu vam nedochazi ze ten kdo chce neco specifickeho si to snadno muze zmenit protoze vi jak, ale naopak ten co by chtel neco navic nez by byl default casto nebude vedet jak a kde to zmenit... proto byva default zameren na sirsi skupiny uzivatelu vcetne BFU, a PowerUser at si klidne zkompiluje vlastni kernel na miru a misto initrd si switchne z jadra rovnou na rootfs...
Že se zrovna tohle děje tak často, že... navíc to lze celkem snadno vyřešit bootem do fallbackového image, který je mírně větší a jsou v něm fallbackové ovladače (minimálně Arch/Manjaro to tak má) a rebuildem image podle aktuální HW konfigurace. Místo rvaní všeho do prťavého bootu. To tam hlavně zase někdo nepřemýšlel, proto je to pošahané.
Jednak ten bod nemusi byt prtavy (honit se za usetrenymi par megabajty je nesmysl), druhak samozrejme moznost co popisujete je dobra spise tak pro geeka, co se v tom skutecne vyzna - ale mene vhodna pro ne az tak zkuseneho uzivatele. A kupodivu linuxove distribuce necili jen na geegy... ;-) Z pohledu mene zkuseneho uzivatele je pohodlnejsi, kdyz muze ten disk vzit a nabootovat nekde jinde, aniz by u toho pachal nejake harakiri :-)
V nových instalacích je to samozřejmě jedno. Ale uživatelé starších instalací jsou štěstím bez sebe.
Mimochodem i to honění za megabajty občas smysl má. Nedávno si tahkle třeba někdo od Arch Linuxu taky řekl, že to nemá smysl a instalace začala vyžadovat cca 534 MB RAM kvůli tuším rozbalení ramdisku. Chápete, nikoliv 512 MB RAM což je stále zcela běžná konfigurace třeba u malých VPS, ale o hloupých 24 MB RAM víc. Výsledek: Arch Linux na malé VPS dnes už snadno prostě nenainstalujete (pokud to nefixnuli). A to i kdyby jste ho chtěl mít velký třeba jen 80 MB. Přešel jsem na Alpine.
Ale to jen tak pro zajímavost.
Jen pockejte, az na tech hloupych malych VPS narazite na potrebu pouzit nejake moderenejsi KDF... :-) Jasne, take se to da "osekat", ale vzdycky je to neco za neco...
Jednak v tom problém nevidím, ale hlavně problém není ani tak v tom, že Ubuntu bůhvíproč vytváří nesmyslně velké image a následně řeší problémy, které si tak samo způsobilo, ale hlavně v tom, že evidentně vytváří nesmyslně malou boot partition.
Jo, na Manjaru mi to stačí, to to takhle neprasí. Ale když si vymýšlím kraviny, pak tomu musím tu instalaci uzpůsobit. Možná to jen nefunguje na starých instalacích s malou boot partition, ale i tak je to prasárna.
Netuším.
Zapomněl jsem tam uvézt odkaz. Je to vytažené z Internetu.
Auto rozdělení jsem použil před lety jen 1x a se šifrováním nemám zkušenosti. Takže si nedovedu představit všechny případy, ale chápu, proč se volí o trošku větší oddíl(y).
Naopak nechápu, proč se při dnešních možnostech HW o tomto tak mohutně diskutuje. Viz příspěvek výše. Prostě když chci něco jinak, je tu možnost pořešit si to sám.
https://i.stack.imgur.com/suwZd.png
U Windows to také nikdo neřeší. A tam se ztrácí daleko víc místa, pokud se budeme bavit o rozesetém nepořádku na disku po instalaci.
Zapomněl jsem tam uvézt odkaz. Je to vytažené z Internetu.
No tak je to horší než jsem myslel.
Oddíly jsou manuální.
Linux - 4 jádra standard, 4 recovery. Bordel po jiných jsem nekontroloval.
26M /boot/efi/EFI/Microsoft
1,9M /boot/efi/EFI/Boot
4,3M /boot/efi/EFI/ubuntu
32M /boot/efi/EFI
8,1M /boot/efi/BIOS
40M /boot/efi
148K /boot/grub/locale
2,3M /boot/grub/fonts
3,5M /boot/grub/x86_64-efi
8,2M /boot/grub
710M /boot
Oddíl EFI je obsazený 537MB.
Ale zvykejme si! Kontejner OS nás ještě vyškolí.
12. 7. 2023, 11:10 editováno autorem komentáře
Muj boot ma 278MB (2x tam je initrd.img-verze-generic po 117MB) a volne misto mam 270GB, takze ja problem nemam - myslim dopredu a sa.ostatny boot nechci. Kdybych chtel, tak bych daval tak 2GB.
A pro znale, rpi po jednom bootu z niceho nic nenabehlo, poskozeny separatni boot na fat32 a jeste vzdy po bootu ho rucne skript remountne na ro a je to pekny o*r myslet pri updatech, ze ho musim remountnout pro rw. Rpi bezi ze ssd, takze netrpim na vadnou kartu, tim jsem si prosel u rpi 1 pred 10ti lety.