Диета для Arch Linux. Запускаем Arch на компьютерах с малым объемом памяти

В пре­дыду­щих стать­ях «дието­логии» — «Linux на диете» и «Но­вая диета для Linux» — мы порабо­тали над сни­жени­ем тре­бова­ний к опе­ратив­ной памяти Bodhi Linux и дос­тигли в этом опре­делен­ных успе­хов. Но круг пок­лонни­ков Bodhi не так велик. Поэто­му давай пос­мотрим, каков аппе­тит у гораз­до более близ­кого сер­дцу хакера Arch Linux.

Как ты зна­ешь, Arch Linux заг­ружа­ется в тек­сто­вую кон­соль, пос­ле чего дает поль­зовате­лю пол­ней­шую сво­боду дей­ствий. Навер­ное, 512 Мбайт ОЗУ для такой сре­ды будет более чем дос­таточ­но? Давай про­верим.

Итак, выс­тавля­ем в свой­ствах вир­туаль­ной машины объ­ем опе­ратив­ной памяти 512 Мбайт, заг­ружа­ем об­раз archlinux-2024.06.01-x86_64.iso, под­клю­чаем, запус­каем, получа­ем...

«Ага‑а-а!» — ска­зали бы тут угрю­мые рус­ские мужики, валив­шие в далеком сибир­ском лесу вековые кед­ры дву­руч­ными пилами. И здесь нас встре­тила ста­рая доб­рая ошиб­ка: Initramfs unpacking failed: write error. Прав­да, вмес­то kernel panic мы получи­ли ава­рий­ную коман­дную стро­ку, но она не работа­ет. Как понят­но из пос­ледне­го сооб­щения, обо­лоч­ка sh не смог­ла свя­зать­ся с тер­миналом tty.

По­хоже, нам есть чем занять­ся! Прис­тупим. В качес­тве рабочей опе­раци­онной сис­темы я по при­выч­ке вос­поль­зовал­ся Bodhi Linux 6.0, что в ито­ге при­вело к... Но обо всем по поряд­ку.

Измеряем и разбираем

Для начала еще раз попыта­емся запус­тить Arch Linux, ука­зав в парамет­рах ядра опцию debug console=ttyS0, что­бы отла­доч­ные события шли в пос­ледова­тель­ный порт, который у вир­туаль­ной машины мож­но при­вязать к фай­лу. Боль­ше все­го нас сей­час инте­ресу­ет рас­пре­деле­ние опе­ратив­ной памяти.

Из сооб­щения вид­но, что пос­ле заг­рузки ядра с упа­кован­ным обра­зом минималь­ной фай­ловой сис­темы (МФС) и резер­вирова­ния слу­жеб­ных областей для работы оста­лось 320 340 Кбайт опе­ратив­ной памяти. Не то что­бы сов­сем уж мало, но с уче­том упа­кован­ного раз­мера обра­за МФС в 143 796 Кбайт исчерпа­ние памяти не выг­лядит чем‑то уди­витель­ным.

Для даль­нейшей работы с содер­жимым дис­три­бутив­ного обра­за удоб­но извлечь его в отдель­ный каталог isofs. Если он при­мон­тирован в точ­ке /media/ARCH_202406, это мож­но сде­лать коман­дой

Те­перь пос­мотрим, что собой пред­став­ляет упа­кован­ный образ МФС, который находит­ся в фай­ле isofs/arch/boot/x86_64/initramfs-linux.img.

По­нят­но, сна­чала идет неупа­кован­ный архив CPIO. Рас­паку­ем‑ка его в каталог initrd_1 и пос­мотрим, что в нем.

Ока­зыва­ется, он содер­жит мик­рокод про­цес­соров AMD и Intel в катало­ге kernel, а так­же модули ядра и дво­ичные фай­лы устрой­ств в катало­гах usr/lib/modules и usr/lib/firmware соот­ветс­твен­но. При­чем, судя по суф­фиксам .zst, боль­шинс­тво фай­лов уже сжа­ты алго­рит­мом ZSTD, что сущес­твен­но сни­жает наши воз­можнос­ти опти­миза­ции. Давай пос­мотрим, какой объ­ем занима­ют фай­лы это­го бло­ка МФС.

Хо­рошо, теперь гля­нем, что еще есть в обра­зе МФС.

А это что за новость?! Какая еще data? Надо разоб­рать­ся:

Ну­ли?! Видимо, сбор­щики обра­за МФС решили выров­нять начала бло­ков. Это, конеч­но, хорошо, но где же начина­ется сле­дующий блок?

По­нят­но, теперь мы можем сно­ва попытать­ся опре­делить тип сле­дующе­го бло­ка:

Ага, вто­рой блок пред­став­ляет собой архив CPIO, сжа­тый алго­рит­мом XZ. Рас­паку­ем и пос­мотрим, что в нем:

А в нем, как нет­рудно догадать­ся, оставша­яся часть МФС: ути­литы и биб­лиотеч­ные модули, фай­лы с нас­трой­ками и сце­нарий init, запус­каемый ядром пос­ле ини­циали­зации. Занима­ет все это в рас­пакован­ном виде 45 Мбайт.

И что теперь с этим делать?

Итак, образ МФС мы рас­пакова­ли. Теперь надо решить, что с ним делать даль­ше. Фокус с при­мене­нием алго­рит­мов сжа­тия тут не прой­дет, потому что всё уже сжа­ли до нас. Мож­но было бы уда­лить некото­рые ненуж­ные драй­веры, но не хотелось бы нарушать задум­ку соз­дателей дис­три­бути­ва. Раз они помес­тили драй­веры виде­оадап­теров в МФС, зна­чит, они тут нуж­ны... Или нет?

По­годи‑ка, а что там у нас было во вре­мя самой пер­вой попыт­ки заг­рузить Arch Linux на 512 Мбайт? Нерабо­тающая кон­соль? А отку­да взя­лась кон­соль, если при рас­паков­ке МФС про­изош­ла ошиб­ка? Получа­ется, что ошиб­ку рас­паков­ки МФС ядро не счи­тает кри­тичес­кой, стол­кнув­шись с такой ситу­ацией, оно не панику­ет, а пыта­ется работать даль­ше как ни в чем не бывало. Вот как выг­лядит жур­нал заг­рузки с вклю­чен­ными отла­доч­ными сооб­щени­ями:

По­луча­ется, из‑за того, что файл биб­лиоте­ки libmount.so.1 не попал в ту часть МФС, которая успе­ла рас­паковать­ся, сце­нарий init не смог при­мон­тировать вир­туаль­ные фай­ловые сис­темы, вклю­чая /proc, потом не смог обра­ботать парамет­ры ядра /proc/cmdline, и пош­ло‑поеха­ло. Как в сти­хот­ворении Мар­шака: «Враг всту­пает в город, плен­ных не щадя, отто­го, что в куз­нице не было гвоз­дя».

Ес­ли бы все необ­ходимое для работы сце­нария init и перек­лючения на пол­ноцен­ную кор­невую фай­ловую сис­тему рас­пакова­лось, а драй­веры виде­оадап­тера — нет, то мы этой пос­ледней неп­рият­ности, воз­можно, даже и не замети­ли бы?