ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | [FR] merge lzma support | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Michael Shigorin <mike> |
| Component: | mkinitrd | Assignee: | Michael Shigorin <mike> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | aen, evg, kas, led, legion, rider, vsu |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| URL: | http://git.altlinux.org/people/led/packages/?p=mkinitrd.git | ||
| Bug Depends on: | |||
| Bug Blocks: | 15333 | ||
(In reply to comment #0) > Предлагаю смержить поддержку lzma из /people/led/packages/mkinitrd.git А почему он сам не смержил? (In reply to comment #1) > А почему он сам не смержил? Поясни? (In reply to comment #2) > (In reply to comment #1) > > А почему он сам не смержил? > Поясни? Человек сделал какие-то изменения, а продвигаешь их ты. Следовательно, вопросы по этим изменениям задавать тебе? Я продвигаю потому, что возникла идея реализовать загрузку тонких клиентов с дискетки как единственного доступного для многих старых железок варианта, кроме HDD. Между прочим, может пригодиться по школам, если вдруг туда попадёт. Также потому, что по опыту продвижения более ранних патчей (то висяки, то молчаки) человек уже сделал свои выводы и отговаривать его второй год подряд мне сложнее, чем поработать прокси. Вопросы задавай здесь обоим, на то и подписаны. В данном разе не понял, что именно куда Саша не смержил. На всякий -- вот контекст: |2009-09-16 [01:32:42] <Led> а можешь сказать сколько сейчас составляют размер vmlinuz-tmc-tc и initrd.img к нему в килобайтах? [12:03:53] <mike> 1334 initrd-2.6.27-tmc-tc-alt5.img 1110 vmlinuz-2.6.27-tmc-tc-alt5 [12:48:19] <Led> ок [12:48:54] <Led> в принципе, вариант загрузки с дискеты может и получиться [12:49:13] <mike> vmlinuz с кастомным минимальным initrd? [12:52:32] <Led> немного почистить initrd и патч на ядро, для поддержки сжатия vmlinuz и initrd lzma вместо gzip [12:53:35] <mike> фигассе немного :) 20% оставить можно при текущем раскладе [12:54:04] <mike> хотя... давненько я в него не заглядывал [12:54:33] <Led> 20-25% процентов даёт lzma по сравнению с gzip [...] [12:57:35] <mike> К тому же 1440К - это понты. Без особых ухищрений дискета форматируется в 1.7-1.8M [...] [12:58:19] <mike> ммм... тоже да, 1722 держали скорее все, которые не сыпались от 1440 [12:58:50] <Led> почистить - в плане "не все существующие в природе Ethernet-адаптеры включать в initrd" Отвлёкся от psi-шного лога -- [12:57:35] <Led> ... Дим, смержишь или что не так? At this time, I'm reluctant to add any enhancements to this monolithic mkinitrd. Please have a look at another implementations that have modular architecture, e.g. make-initrd by Alexey Gladkov and Kirill Shutemov. (In reply to comment #6) > At this time, I'm reluctant to add any enhancements to this monolithic > mkinitrd. Это проверено два года уж как. > Please have a look at [an]other implementations that have modular architecture, > e.g. make-initrd by Alexey Gladkov and Kirill Shutemov. Мы оба в курсе, но существующий (и решающий несрочную именно прямщас, но нужную вообще-то задачу) патч -- пока для mkinitrd. К make-initrd есть другая претензия, которую осмысленно высказывать FR-ом на тот пакет -- сборка с glibc статиком, со слов led@. Почитай #c4 -- хорош ли твой совет или "* только для дискеток 2.88M"? Если хочешь, добавь меня в ACL mkinitrd -- сделаю сам и отвечать буду тоже сам. (В ответ на комментарий №7) > К make-initrd есть другая претензия, которую осмысленно высказывать FR-ом на > тот пакет -- сборка с glibc статиком, со слов led@. Не верь этим словам. make-initrd использует glibc и системные утилиты, но статически собранных утилит он не использует ... разумеется если конечно у тебя coreutils не собраны статически. (In reply to comment #7) > (In reply to comment #6) > > At this time, I'm reluctant to add any enhancements to this monolithic > > mkinitrd. > Это проверено два года уж как. За два года могло испортиться. :) > > Please have a look at other implementations that have modular architecture, > > e.g. make-initrd by Alexey Gladkov and Kirill Shutemov. > Мы оба в курсе, но существующий (и решающий несрочную именно прямщас, но нужную > вообще-то задачу) патч -- пока для mkinitrd. > > К make-initrd есть другая претензия, которую осмысленно высказывать FR-ом на > тот пакет -- сборка с glibc статиком, со слов led@. Почитай #c4 -- хорош ли > твой совет или "* только для дискеток 2.88M"? Статической glibc я там не наблюдаю: $ rpmquery -pR make-initrd-0.1.6-alt3.src.rpm kinit-utils-1.5.15-alt2.src.rpm |grep -v ^rpmlib libcap-devel zlib-devel > Если хочешь, добавь меня в ACL mkinitrd -- сделаю сам и отвечать буду тоже сам. А если оно приедет ко мне на сервер, кто будет отвечать? :) (In reply to comment #8) > > К make-initrd есть другая претензия, которую осмысленно высказывать FR-ом на > > тот пакет -- сборка с glibc статиком, со слов led@. > Не верь этим словам. 2 led: тогда уточняй, что я не так понял или ты не так сформулировал. > make-initrd использует glibc и системные утилиты, но статически собранных > утилит он не использует ... Возможно, Саша хотел сказать просто "glibc" (в противоположность dietlibc/klibc). (In reply to comment #9) > > Если хочешь, добавь меня в ACL mkinitrd -- сделаю сам и отвечать > > буду тоже сам. > А если оно приедет ко мне на сервер, кто будет отвечать? :) root@localhost, разумеется. :) Но вообще я верю пакетам led@, он на себе их проверяет обычно перед тем, как выдавать. Тем более такие. 2 rider: между прочим, на кластерных узлах NBD root -- тоже один из вариантов. Поможешь с тестированием, если есть такой же интерес? (В ответ на комментарий №10) > Возможно, Саша хотел сказать просто "glibc" (в противоположность > dietlibc/klibc). В make-initrd для простейшей загрузки (простейшей == поддерживаемой mkinitrd) не используется ничего заточенного на glibc. Но переход на glibc был сознательным. Он несёт больше плюсов, чем минусов... вроде увеличения размера initrd. (В ответ на комментарий №11) > (В ответ на комментарий №10) > > Возможно, Саша хотел сказать просто "glibc" (в противоположность > > dietlibc/klibc). > > В make-initrd для простейшей загрузки (простейшей == поддерживаемой mkinitrd) > не используется ничего заточенного на glibc. Но переход на glibc был > сознательным. Он несёт больше плюсов, чем минусов... вроде увеличения размера > initrd. Никто не оспаривает этих "плюсов". Поскажите как заюзать эти "плюсы" для изначально обозначенной задачи: "Предполагается применить для втискивания vmlinuz+initrd для тонких клиентов на /dev/fd0u{1440,1722}". А также, как с помощью make-initrd получать необходимый initrd.img автоматически при установке ядра. (В ответ на комментарий №10) > > 2 rider: между прочим, на кластерных узлах NBD root -- тоже один из вариантов. > Поможешь с тестированием, если есть такой же интерес? мы сейчас рассматриваем вариант с make-initrd, а не с mkinitrd. Впрочем, выбор будет зависить от разных факторов - в нашем случае можно вообще без mkinitrd обойтись - есть и другие хорошие инструменты для создания initramfs-образа. Да, собственно я хотел сказать - потестирую в make-initrd, если будет такое изменение приложено. (В ответ на комментарий №12) > Никто не оспаривает этих "плюсов". Поскажите как заюзать эти "плюсы" для > изначально обозначенной задачи: "Предполагается применить для втискивания > vmlinuz+initrd для тонких клиентов на > /dev/fd0u{1440,1722}". Не считаю нужным что-то подсказывать по этой вашей задаче т.к. задача поставлена не мной и не передо мной. Я встрял сюда со своим оффтопиком, чтобы не складывалось неправильного представления о другом проекте. > А также, как с помощью make-initrd получать необходимый initrd.img > автоматически при установке ядра. Содержимое "необходимого" образа зависит от необходимости. Как создать образ initrd.img через make-initrd написано в документации. (In reply to comment #6) > At this time, I'm reluctant to add any enhancements to this monolithic > mkinitrd. Насколько понимаю, это было шаблонное сообщение -- можно забирать mkinitrd и делать с ним то, что требуется? Если да, то просьба привести ACL в соответствие с Assignee: этой баги: mkinitrd vsu ldv OK, я самоудалился: $ git.alt acl sisyphus mkinitrd show mkinitrd vsu mkinitrd-1:3.0.12-alt1 -> sisyphus: * Sun Nov 04 2012 Led <led@altlinux> 1:3.0.12-alt1 - 3.0.12: + mkinitrd: find modules in modules.alias if modules.pcimap not exists + mkinitrd: added modules.builtin and modules.order to tree + mkinitrd: added kmod support + mkinitrd: copy /lib/udev/dm_export only if it exists + mkinitrd: added support xz and lzo compressing + mkinitrd: added --with-nbd + scripts/local: use fs type 'auto' if unknown + init: added support parameters for loading modules + init: added 'modules=' kernel parameter support + rewrote script 'dhcp' to 'ip' + added support 'netdev' kernel parameter + added scripts/nbd_* + mkinitrd: added --root and --rootfs options + added support boot from nbd (ALT#15466) + mkinitrd: added support list file for --preload|--with|--extra (ALT#11375) + mkinitrd: removed unsupported image types + mkinitrd: added support /etc/sysconfig/mkinitrd config + mkinitrd: added lzma, xz, lzo and bzip2 compression (ALT#21588) + applied patch from http://bugzilla.altlinux.org/show_bug.cgi?id=19388 for LVM2 support in initrd |
Предлагаю смержить поддержку lzma из /people/led/packages/mkinitrd.git -- в нём поддерживается --compressor {gzip|bzip2|lzma}, по-умолчанию (без указания --compressor) используется gzip, а с этим ключём - любой из перечисленных компрессоров (если он поддерживается соответствующим ядром, что проверяется при генерации initrd). Предполагается применить для втискивания vmlinuz+initrd для тонких клиентов на /dev/fd0u{1440,1722}.