Live-загрузка и установка с переносного жесткого диска с NTFS

[neobht]

Ничего себе!!! Больше полгода теме, а все эксперименты.

Вот лучшее решение: http://neobht.github.io/uird/

[sb]

Если же речь о BIOS/Legacy-загрузке, многие переехали на syslinux6, тогда как в Альте syslinux4 с gfxboot и собственными патчами.

Имеется какая-то принципиальная позиция, почему именно эти инструменты используются или это просто исторически сложившаяся практика использования данных инструментов с нехваткой ресурсов на проверку и переезд на нечто более перспективное (так ли это?) или менее затратное в плане поддержки ?

[Mr.Madguy]

Имеется какая-то принципиальная позиция, почему именно эти инструменты используются или это просто исторически сложившаяся практика использования данных инструментов с нехваткой ресурсов на проверку и переезд на нечто более перспективное (так ли это?) или менее затратное в плане поддержки ?

Я думаю тут логика в стиле если все и так работает, то зачем что то менять? Я сам, если честно, не понял, при чем тут вообще загрузчик. Все эти проблемы с загрузкой возникают как раз из за того, что все стадии загрузки работают независимо друг от друга. Как только загружается ядро, ему сразу становится плевать на то, что там до него творил загрузчик. Так например ядро не видит loop-устройства загрузчика и потому нельзя например загрузить вторую стадию с виртуального ISO-диска. Ядро должно уметь грузить вторую стадию напрямую с ISO-шника. Именно поэтому мне это решение и не нравится. Вся эта матрешка RAM-дисков только зря тратит память и время на загрузку. Именно поэтому я предпочитаю просто распаковывать ISO-шник и грузить сразу ядро и initrd.

[klark973]

Имеется какая-то принципиальная позиция, почему именно эти инструменты используются или это просто исторически сложившаяся практика [...]?

Работало -- не трогали. Всем нужен был gfxboot, он и был в обеих режимах. С syslinux4 теперь проблем нет -- он собирается последними gcc, так что риск его выкидывания из Сизифа ушёл. К syslinux6 мейнтейнеры тоже примеряются -- это весьма не простой пакет для нашей сборочницы, другое дело, что полезен он лишь для локальной загрузки на x86, в том числе, в EFI. Проблема загрузчиков встала по трём причинам: 1) к p9 существенно выросло число поддерживаемых архитектур, 2) обнаружились конкретные проблемы с Refind+elilo на вполне конкретных единичных железках в режиме EFI, 3) апстрим elilo давно умер, он использовался как трамплин для загрузки не подписанных ядер в SecureBoot.

[sb]

Спасибо за разъяснения, картина прояснилась

[Mr.Madguy]

Блин. Что то никак не получается скомпилировать Newt. Он ругается на архитектуру и вообще выкидывает много ошибок. Я вообще что то не пойму. Такое ощущение складывается, что под 64 бита не все пакеты доступны. Для того, чтобы устранить ошибку с libresolv.a пришлось ставить 32х битные пакеты. Аналогично и с libnewt и libslang. Вроде 64х битная версия initrd отличается от 32х битной. Как ее скомпилировать то?

[Mr.Madguy]

Под 64 бита собрать не смог. Под 32 бита с горем пополам собрал, т.к. там крайне мало места на RAM-диске и его вот прямо в обрез. Но проблема в том, что после вызова make-initrd получился файл размером всего 5Мб, в то время как должен был получится около 42Мб. Т.е. какие то модули туда не скопировались. Может надо конфиг make-initrd поменять? Где взять правильный для Starterkit'ов?

[Mr.Madguy]

Короче не получилось.

Во первых, результат работы make-initrd - это не то, что мне нужно. Нужный результат получается при работе утилиты mki-build-propagator. Но как заставить эту штуку собрать мне отдельно full.cz без всего остального - это очень большой вопрос.

Во вторых, я еще раз внимательно перечитал маны и понял, что никакой фикс там не нужен. Все должно и так работать. Проблема не в propagator. Она в чем то другом. "modprobe ntfs" якобы завершается успехом. А вот mount возвращает ошибку, которая означает "файловая система не сконфигурирована в ядре". Как не сконфигурирована, если modprobe только что завершился успехом? Вот в этом то и вопрос. Может модуль ядра с поддержкой ntfs какой-то битый?

[klark973]

"modprobe ntfs" якобы завершается успехом. А вот mount возвращает ошибку, которая означает "файловая система не сконфигурирована в ядре". Как не сконфигурирована, если modprobe только что завершился успехом? Вот в этом то и вопрос. Может модуль ядра с поддержкой ntfs какой-то битый?

А как же модули NLS? lsmod|grep nls что при этом показывает? И опять же, ntfs -- это старый ядрёный модуль read-only, не факт, что он будет хорошо работать с NTFS v3.1+ (начиная с Windows Vista). Для более новой полной поддержки требуется fuse и ntfs-3g.

[Mr.Madguy]

А как же модули NLS? lsmod|grep nls что при этом показывает? И опять же, ntfs -- это старый ядрёный модуль read-only, не факт, что он будет хорошо работать с NTFS v3.1+ (начиная с Windows Vista). Для более новой полной поддержки требуется fuse и ntfs-3g.

А при чем тут NLS? Может NFS? Он вызывается через запуск "/bin/nfsmount". Я в общем то так и хотел попробовать пофиксить propagator, т.к. мне показалось, что возможности команды mount шире, чем сишного аналога. Но повнимательнее вчитался в маны и вроде функционал у них аналогичный. Ну короче смысл в том, что эта проблема скорее всего лежит в области правильного конфигурирования initrd. Список модулей, которые пишутся в full.cz, насколько я понимаю, можно посмотреть тут http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=blob;f=profiles/modules;h=0c48043e1973e9478f280ec4d6ca362b448e971a;hb=49c00b2a2a5773891f50e96026cb1d9540edacaf. Если добавить туда ntfs-3g и fuse, то скорее всего придется таки фиксить propagator и менять там ntfs на ntfs-3g.

[klark973]

А при чем тут NLS?

Native Language Support. Требуется для некоторых файловых систем типа FAT и NTFS.

Код: [Выделить]

bmt:~# lsmod |grep nls
bmt:~# modprobe vfat
bmt:~# lsmod |grep nls
bmt:~# mount /boot/efi
bmt:~# lsmod |grep nls
nls_utf8               16384  1
nls_cp866              20480  1


Список модулей, которые пишутся в full.cz, насколько я понимаю, можно посмотреть тут

Нет, не тут. Через mkmodpack из пропагатора и через mkimage (tools/mki-build-propagator) список скармливается из самого профиля m-p (sub.in/stage1). При сборке с DEBUG=1 видно более точно, что откуда и куда...

Вот лучшее решение: http://neobht.github.io/uird/

Вот и я думаю, не стоит мучиться. Надо взять CLB (Colaboot), описание есть на ВиКи.

[Mr.Madguy]

А при чем тут NLS?

Native Language Support. Требуется для некоторых файловых систем типа FAT и NTFS.

Код: [Выделить]

bmt:~# lsmod |grep nls
bmt:~# modprobe vfat
bmt:~# lsmod |grep nls
bmt:~# mount /boot/efi
bmt:~# lsmod |grep nls
nls_utf8               16384  1
nls_cp866              20480  1


Список модулей, которые пишутся в full.cz, насколько я понимаю, можно посмотреть тут

Нет, не тут. Через mkmodpack из пропагатора и через mkimage (tools/mki-build-propagator) список скармливается из самого профиля m-p (sub.in/stage1). При сборке с DEBUG=1 видно более точно, что откуда и куда...

Вот лучшее решение: http://neobht.github.io/uird/

Вот и я думаю, не стоит мучиться. Надо взять CLB (Colaboot), описание есть на ВиКи.

Ну надо будет попробовать. Это же надо делать во время загрузки. А там я не совсем уверен, что правильные результаты выдаются. По крайней мере modprobe ntfs у меня там не срабатывал.

А так я просто уже эти сурцы излазил вдоль и поперек. И, насколько я понимаю:
http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=blob;f=profiles/Makefile.in;h=6cc77864443596e1a57a3b0b7979995b37682f54;hb=49c00b2a2a5773891f50e96026cb1d9540edacaf

Код: [Выделить]

  67 GLOBAL_PROPAGATOR_MAR_MODULES ?= ./modules
  68 PROPAGATOR_MAR_MODULES = $(GLOBAL_PROPAGATOR_MAR_MODULES)
http://git.altlinux.org/gears/m/mkimage.git?p=mkimage.git;a=blob;f=tools/mki-build-propagator;h=365d359ca800633b16fe6f1ef8d6ffe6dac482a6;hb=4757004728dbd1fd8835c5759cec51925e22db95

Код: [Выделить]

  17 mar_modules="${PROPAGATOR_MAR_MODULES:?Mar morules required}"
  40 if type mkmodpack >/dev/null 2>&1; then
  41         mkmodpack -p '/.in/${mar_modules##*/}' -o /tmp/modules -k "\$kver"
  42 else
  43         mkmar -r / -p '/.in/${mar_modules##*/}' -o /tmp/modules -k "\$kver"
  44 fi


[klark973]

Код очень похожий, если не такой же. Но я уже сказал, где его правильно искать. Причём тут boyarsh?

[Mr.Madguy]

Код очень похожий, если не такой же. Но я уже сказал, где его правильно искать. Причём тут boyarsh?

Я не буду спорить, т.к. пока что слабоват в скриптах и понимаю их больше интуитивно. Просто full.cz делается именно в mki-build-propagator. Насколько я понимаю, данный код читает паттерны из modules и скармливает их mkmodpack из propagator с опцией -p, т.е. pattern, который кладет модули в /tmp/modules. А потом идет какой то страшный код, который cat'ом льет в full.cz initfs, все модули из /tmp/modules, а потом еще доливает туда все содержимое папки /initfs в формате cpio, походу делая подстановки sed'ом и еще и запаковывает все это gzip'ом. Все это конечно очень далеко от результата работы make-initrd.

А boyarsh это автор основного профиля для mkimage.

[klark973]

Просто full.cz делается именно в mki-build-propagator. Насколько я понимаю, данный код читает паттерны из modules и скармливает их mkmodpack из propagator с опцией -p, т.е. pattern, который кладет модули в /tmp/modules. А потом идет какой то страшный код, который cat'ом льет в full.cz initfs, все модули из /tmp/modules, а потом еще доливает туда все содержимое папки /initfs в формате cpio, походу делая подстановки sed'ом и еще и запаковывает все это gzip'ом.

Именно такая логика -- это отдельный cpio с болванкой ядерных модулей для универсальных загрузочных носителей.

Все это конечно очень далеко от результата работы make-initrd.

make-initrd ещё отдельный cpio добавляет со своей логикой.

А boyarsh это автор основного профиля для mkimage.

Нет, это главный мейнейнер ядра. Он использует deprecated m-p-d до сих пор вместо m-p. Правильный ответ об авторстве mkimage подскажет rpm -q --changelog mkimage или что тогда значит основной профиль?