# rpm -qR extlinux-6.03-alt1.x86_64 libshell util-linux parted ...
Не паразитная.
Ой, а зачем он там?
Ребята, ну нельзя же быть такими ленивыми. Ведь даже клонировать к себе репозиторий не нужно: http://git.altlinux.org/gears/e/extlinux.git?p=extlinux.git&a=search&h=HEAD&st=grep&s=parted Если кто-нибудь придумает как получить эту информацию без parted, то выкину его мгновенно. С другой стороны не вижу, кому она может мешать.
(In reply to comment #3) > С другой стороны не вижу, кому она может мешать. parted тянет за собой много добра, т.к. сама является надстройкой над уймой более низкоуровневых утилит, а установка минималистичного загрузчика порою требуется для всяких встраиваемых решений и компактных образов. В результате вижу, что даже наши пользователи, вместо использования штатных syslinux/extlinux, качают ИХ из апстрима (!!!), а не из нашей репы (справедливости ради: не только по этой причине, но ещё и из-за старой версии). Кроме того, дистрибутивно-полезно начать замену остановившегося в развитии lilo на syslinux (к примеру, для той же JeOS). И не только lilo, кстати, но и в ряде случаев мы уже смело можем менять "ОС GRUB2" на него, заодно отказавшись от конгломерата с elilo и refind'а. > Если кто-нибудь придумает как получить эту информацию без parted, то выкину его мгновенно. Но я не знаю, чем ЛУЧШЕ заменить parted. Сходу нашлось несколько вариантов, а что "легковесней", решайте сами... 1. Определение способа разметки диска # Можно получить gpt/dos (не msdos): # sfdisk -d /dev/sda | head -n1 label: dos или label: gpt # Скорее всего, зависит от версии fdisk, встречал пустой вывод на GPT # LANG=C fdisk -l /dev/sda | grep -E '^Disklabel type: ' Disklabel type: dos # Весьма надёжный способ # LANG=C gdisk -l /dev/sda 2>/dev/null | grep -A4 -E '^Partition table scan:' # Такой вывод будет на машинах с MBR: Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present # А такой вывод будет на машинах с GPT: Partition table scan: MBR: protective BSD: not present APM: not present GPT: present # Достаточно надёжный способ определения MBR, для GPT вывод будет пустой # LANG=C sgdisk -p /dev/sda | grep -A1 'Found invalid GPT and valid MBR' Found invalid GPT and valid MBR; converting MBR to GPT format in memory. # Это будет единственный раздел на диске, не загрузочный! # LANG=C fdisk -l /dev/sda | tail -n1 | grep -qE " ee EFI GPT$" 2. Определение флага загрузки для раздела (MBR only) # Здесь /dev/sda1 -- это м.б. "${device}${partition}" # sfdisk -d /dev/sda | grep "/dev/sda1 " | grep -qE ", bootable$" # То же самое, но раздел загрузочный, если "$bootflag" = "*" # bootflag=$(LANG=C fdisk -l /dev/sda | grep "/dev/sda1 " | awk '{print $2;}') 3. Определение флага загрузки для раздела (GPT only, хотя смысла в этом мало) # sgdisk -A $partition:show /dev/sda | grep -q 'legacy BIOS bootable' # sgdisk -A $partition:show /dev/sda | grep -qE "^$partition\:2\:" 4. Посмотреть все доступные флаги разделов можно так # sgdisk -A list 0: system partition 1: hide from EFI 2: legacy BIOS bootable 60: read-only 62: hidden 63: do not automount Полагаю, список не исчерпывающий.
Вижу довольно простое решение: вынести скрипт в subpackage. То есть: # rpm -ql extlinux /boot/boot /boot/extlinux.conf.sample /etc/extlinux.conf.sample /sbin/extlinux /usr/share/extlinux/altmbr.bin /usr/share/extlinux/gptmbr.bin /usr/share/extlinux/mbr.bin /usr/share/man/man1/extlinux.1.xz Все остальное - в какой-нибудь extlinux-support, и уже он пусть зависит от чего угодно. Можно, наверное, даже обозвать вышеперечисленный набор extlinux-base, а в пакете extlinux написать Requires: extlinux-base = %version-%release, extlinux-support = %version-%release А уж отличить MBR от GPT - совсем детская задача: dd bs=512 skip=1 count=1 "if=$dev" | sha256sum | sed -re 's,(^.{8}).*,\1,g' и сравнить вывод с волшебным числом 076a27c7 - если совпадает, то это MBR :-)
(In reply to comment #5) > и сравнить вывод с волшебным числом 076a27c7 - если совпадает, то это MBR :-) У меня на MBR показал 99ed8546, на ONIE/GPT 93928b26, на других машинах и дисках с GUID/GPT: d7b907074d, 40e7b3d0, a997bcd9. Но если использовать не второй сектор диска и не использовать sha256sum, думаю, вытащить все данные будет можно самым кошерным способом.
Мне тут подсказывают, что шутка про различия MBR и GPT может быть воспринята всерьез, поэтому вот решение, полностью соответствующее стандарту: dd bs=8 skip=64 count=1 "if=$dev" | xxd -p Если выдаст 0000000000000000 - MBR, если 4546492050415254 ("EFI PART") - GPT. Другие значения являются признаком того, что на диске записано что-то неизвестное, и во избежание повреждения данных на него лучше ничего не писать.
(In reply to comment #7) > dd bs=8 skip=64 count=1 "if=$dev" | xxd -p Тогда уж лучше так, поскольку base64 есть даже в busybox, в отличие от xxd: magic="$(dd bs=8 skip=64 count=1 "if=$dev" | base64)" if [ "$magic" = "RUZJIFBBUlQ=" ]; then # GUID/GPT code here... fi > Если выдаст 0000000000000000 - MBR, если 4546492050415254 ("EFI PART") - GPT. > Другие значения являются признаком того, что на диске записано что-то > неизвестное, и во избежание повреждения данных на него лучше ничего не писать. Для GPT -- да, для MBR -- нет. Например, на всех машинах с grub2 второй сектор диска начинается с core2.img (stage1.5), а там совсем другое. На других системах, где сектора начиная со второго и до начала первого раздела не используются, там не обязательно будут нули. Только если диск специально почистили. Но также там может быть код какого-то другого загрузчика.
(В ответ на комментарий №4) > (In reply to comment #3) > > С другой стороны не вижу, кому она может мешать. > > parted тянет за собой много добра, т.к. сама является надстройкой над уймой > более низкоуровневых утилит, а установка минималистичного загрузчика порою > требуется для всяких встраиваемых решений и компактных образов. В результате > вижу, что даже наши пользователи, вместо использования штатных > syslinux/extlinux, качают ИХ из апстрима (!!!), а не из нашей репы > (справедливости ради: не только по этой причине, но ещё и из-за старой версии). > Кроме того, дистрибутивно-полезно начать замену остановившегося в развитии lilo > на syslinux (к примеру, для той же JeOS). И не только lilo, кстати, но и в ряде > случаев мы уже смело можем менять "ОС GRUB2" на него, заодно отказавшись от > конгломерата с elilo и refind'а. Очень эмоционально и я очень такому участию, но вы не перепутали пакеты (это не троллинг) ? Я объясню. Дело в том, что есть пакет syslinux[1], который поддерживается некоторым числом мантейнеров (в которое я не вхожу). Он для всех для дистрибутивов, для сетевой загрузки ... я на самом деле не знаю кто и как им пользуется. И есть extlinux[2], который является загрузчиком моей системы. Именно поэтому это только extlinux без остальных pxelinux, isolinux etc. Я его использую, обновляю и поддерживаю. Я же написал простейшую скриптовую обвязку для генерации конфигов и прочего. Я также понимаю, что это моё решение не применяется в дистрибутивах так как не является универсальным (это только локальный ext-like раздел). В дистрибутивах используется grub2 как универсальный загрузчик, где есть поддержка lvm, raid и хрен знает ещё чего. Может вы хотите не этот корманный проект, а syslinux[1] в котором в некоторой степени запаковано почти тоже самое ? Поймите меня правильно, я не против внести изменения и дорабатывать пакет, но мне хочется понимать во имя чего. Что вы хотите получить ? Вы где это хотите использовать ? Какие юскейсы ? так как для моего профиля использования (десктопная система) наличие parted не является проблемой и это не является ошибкой потому что я использовал его сознательно. [1] http://git.altlinux.org/gears/s/syslinux.git [2] http://git.altlinux.org/gears/e/extlinux.git
(В ответ на комментарий №9) > вы не перепутали пакеты (это не троллинг) ? Точно не троллинг. Не перепутал, родительский-то проект один. Но почему-то думал, что Вы поддерживаете оба пакета, и главная моя ошибка, что смешал всё в одну кучу. Просто в этом случае их сложно разделить. Когда работаем с FAT, тогда syslinux, когда BIOS/EFI машины поддерживает и нужен ext2/3/4, тогда extlinux, когда нужна загрузка с ISO-образа, тогда isolinux, кто-то ещё использует pxelinux. Лично я тоже активно раньше использовал extlinux, в т.ч. на загрузочных флэшках и rescue-разделах HDD. Причём без parted, хотя кому-то удобнее именно этот инструмент. Начиная с 6 версии syslinux/extlinux поддерживают EFI, не только MBR. Не во всех, но во многих случаях это позволяет отказаться от огромной кучи ненужного в _компактных системах_ барахла. Про это и другие юзэкейсы я выше написал. Было бы очень неплохо сделать хотя бы так, как выше предложил Gremlin from Kremlin. Тем более, сами говорите, что тянете parted только для собственной скриптовой обвязки, а у нас тут постоянно горячие споры про "паразитные зависимости" и "форки, не удовлетворяющие общей концепции дистрибутива". Мы не можем усидеть на двух стульях при таком подходе, когда одни говорят, "мы делаем только десктопные решения", другие "сделайте нам компактный образ для свича", а третьи настаивают, чтобы это не былом "форком". > Я также понимаю, что это моё решение не применяется в дистрибутивах > так как не является универсальным (это только локальный ext-like раздел). Но extlinux люди используют. Есть пример проекта с примерно 16 тыс машин по всей стране, в том числе, в местах, где с Интернетом совсем труба. Образы они собирают сами на базе наших бранчей и m-p. Размер образа для них очень критичен (обновления централизованы). И эти люди качают статически линкуемые бинари с оффсайта проекта. Эмоции были только, когда увидел это своими глазами. :) И это ни единственный пример за последние пол года. > Что вы хотите получить ? Обновить syslinux&Ко до 6.0.3 (это ясно, не к Вам, и не здесь), и собственно избавить сабж от parted хоть каким-то компромиссным для всех способом. Потому что в таком виде и мне сложно дать пакету широкое применение в реализуемом сейчас деплойном решении (речь не о десктопах, конечно). Сегодня как раз ваял код, где обошёлся dd и base64 для решения той же задачи, а уж они есть в любой системе.
(В ответ на комментарий №4) > Кроме того, дистрибутивно-полезно начать замену остановившегося в развитии > lilo на syslinux (к примеру, для той же JeOS). Здесь точно ошибся: на extlinux, в основном. Хотя, в ряде случаев должен быть обходной манёвр для отдельного FAT-раздела с EFI/syslinux. > И не только lilo, кстати, но и в ряде случаев мы уже смело можем менять > "ОС GRUB2" на него, заодно отказавшись от конгломерата с elilo и refind'ом. Тут стоит дополнить: об этом мало кто знает. Раньше дистрибутивы предлагали выбор между lilo и grub. Сейчас от такой практики, в основном, ушли, а lilo перестал развиваться. Но у lilo появилась полноценная, развиваемая замена. Это extlinux, но где-то вместо него предпочтительно использовать syslinux. Так вот, это относительно крошечное решение сравнительно недавно стало поддерживать не только LegacyBIOS/MBR, но и GUID/GPT. А значит мы, не во всех, но в большинстве случаев можем вполне обоснованно вернуть людям выбор: а) extlinux либо syslinux с куда более простой установкой и конфигурацией б) grub2+refind+elilo+блэкджек+женщины+все_остальные_радости
(В ответ на комментарий №10) > Точно не троллинг. Про троллинг я говорил о себе и моих вопросах :) > Не перепутал, родительский-то проект один. Апстримный проект один, но ирония в том, что в сизифе есть два пакета с одним кодом. Мне с моим пакетом не интересно собирать остальные части проекта syslinux. Да и не даст мне никто этого по очевидной причине. > Просто в этом случае их сложно разделить. Когда работаем с FAT, > тогда syslinux, когда BIOS/EFI машины поддерживает и нужен ext2/3/4, тогда > extlinux, когда нужна загрузка с ISO-образа, тогда isolinux, кто-то ещё > использует pxelinux. Так вот чтобы было комплексное решение, как вы хотите, нужно обновлять и допиливать пакет syslinux, который уже протух на 10 релизов. > Начиная с 6 версии syslinux/extlinux поддерживают EFI, не только MBR. Не во > всех, но во многих случаях это позволяет отказаться от огромной кучи ненужного > в _компактных системах_ барахла. Про это и другие юзэкейсы я выше написал. Вы выше писали про создание замены lilo, чем проект extlinux и пой пакет тем более не являются. Так что мне понятна ваша точка зрения на проект syslinux, но я всё ещё не услышал юскейсов для _моего_ пакета extlinux. > Было > бы очень неплохо сделать хотя бы так, как выше предложил Gremlin from Kremlin. Обоснуйте пожалуйста. > Тем более, сами говорите, что тянете parted только для собственной скриптовой > обвязки Для меня эта обвязка важна. Она у меня работает годами. Если по какой-то причине она вам не нравится, то нет проблем: сделайте патч с адекватной заменой и я приложу его. > а у нас тут постоянно горячие споры про "паразитные зависимости" и > "форки, не удовлетворяющие общей концепции дистрибутива". Мы не можем усидеть > на двух стульях при таком подходе, когда одни говорят, "мы делаем только > десктопные решения", другие "сделайте нам компактный образ для свича", а третьи > настаивают, чтобы это не былом "форком". Это всё хорошо и правильно, но я больше не делаю дистрибутивы альта, не создаю и не внедряю решения на его основе. Я не понимаю зачем вы взываете к сознательности дистрибутивостроителя во мне )) > Но extlinux люди используют. Вы имеете в виду мой пакет ?! > Обновить syslinux&Ко до 6.0.3 (это ясно, не к Вам, и не здесь), и собственно > избавить сабж от parted хоть каким-то компромиссным для всех способом. Ещё раз, вы валите всё в кучу. Мой пакет не собирается из syslinux[1]. Обновляйте его как хотите. Поставьте конфликт на мой пакет и будет счастье. Это _разные_ пакеты в сизифе, у них разные мантейнеры и видинье и они имеют разные циклы обновления. [1] http://git.altlinux.org/gears/s/syslinux.git > Потому > что в таком виде и мне сложно дать пакету широкое применение в реализуемом > сейчас деплойном решении (речь не о десктопах, конечно). Так не давайте. Я чего-то не понимаю. Я разве у вас этого просил ? > Сегодня как раз ваял > код, где обошёлся dd и base64 для решения той же задачи, а уж они есть в любой > системе. Отлично! Если вы хотите использовать именно этот пакет, то жду патч с заменой parted. (В ответ на комментарий №11) > Тут стоит дополнить: об этом мало кто знает. Раньше дистрибутивы предлагали > выбор между lilo и grub. Я знаю, поверьте. > Сейчас от такой практики, в основном, ушли, а lilo > перестал развиваться. Но у lilo появилась полноценная, развиваемая замена. Это > extlinux, но где-то вместо него предпочтительно использовать syslinux. Проект syslinux не является заменой lilo. Тем более полноценной. У них настолько разные философии, что общего у них разве что начальный загрузчик. В качестве примера, попробуйте использовать syslinux на RAID. > А значит мы, не во всех, но в большинстве > случаев можем вполне обоснованно вернуть людям выбор: > > а) extlinux либо syslinux с куда более простой установкой и конфигурацией > б) grub2+refind+elilo+блэкджек+женщины+все_остальные_радости Эти варианты не сопоставимы по фичам. Вы всё время упоминаете extlinux либо syslinux (я думаю, что вы говорите о пакетах в сизифе) и о наведении некоего порядка. Но это всё относится к пакету syslinux и к ваши просьбы должны быть обращены к тем богатырям, которые его мантейнят. Про глобальное счастье с свежим syslinux это к ним. Вот эти герои: $ giter acl sisyphus syslinux show syslinux zerg mike Они могут также дособрать extlinux в виде подпакета. Чего вы хотите от меня ? Я не могу (и пока не хочу) дособирать остальные программы проекта syslinux из своего srpm. Я могу улучшить лишь свой пакет и могу попробовать сделать его более пригодным.
Если же вас смущает название пакета, то я могу переименовать его в extloader например, чтобы дать дорогу богатырям.
О чём вы спорите ? extlinux надо собирать в рамках исходников syslinux. А этот - переименовать что бы никого не смущал. syslinux действительно требует обновления, в том числе с точки зрения сборки на EFI (если он поддерживает EFI, конечно, а не просто GPT). из пакета syslinux было бы неплохо собрать и бинарь extlinux. Который, как раз, положить в пакет extlinux. Лёш, может быть тебе в рамках этих перетрубаций сделать отдельный пакет extloader, с твоей обвязкой и зависимостью на пакет extlinux ?
(В ответ на комментарий №14) > О чём вы спорите ? О! Антон, тут твои клиенты. Пользователи хотят большей актуальности, поддерживаемости и большего функционала от syslinux. > extlinux надо собирать в рамках исходников syslinux. А этот - переименовать что > бы никого не смущал. Да, неправильно вводить людей в заблуждение, что я имею отношение к syslinux. > syslinux действительно требует обновления, в том числе с точки зрения сборки на > EFI (если он поддерживает EFI, конечно, а не просто GPT). > из пакета syslinux было бы неплохо собрать и бинарь extlinux. Который, как раз, > положить в пакет extlinux. Это похоже на хороший план )) > Лёш, может быть тебе в рамках этих перетрубаций сделать отдельный пакет > extloader, с твоей обвязкой и зависимостью на пакет extlinux ? Хорошо. Я переименую пакет, но зависимость делать не буду. Во-первых сейчас зависимость ставить просто не на что. Во-вторых у syslinux и у моего разные задачи и как следствие циклы обновления. Мне важны новые релизы и фичи extlinux, а в syslinux важна стабильность. Я знаю, что так просто syslinux не обновить. Даже если отвлечься, что обновление скорее всего сломает дистро-пекарей, он просто не пройдёт сборочницу из-за одного фундаментального изменения, которое произошло в 2012 году. Так что, я сомневаюсь, что богатыри обновлят его в ближайшей перспективе. Кроме того, для правильной работы extlinux в syslinux из коробки предётся написать скрипты опять же. В целом, переименование пакета это хороший способ для меня спрятаться в кусты ))
Хе! А мне и не нужно ничего переименовывать. У нас уже есть пакет syslinux-extlinux и он собран из syslinux. У меня есть конфликт. Поэтому я вам мешать не могу никак.
Более того, ментейнеры syslinux - zerg и mike.
(В ответ на комментарий №15) > Я знаю, что так просто syslinux не обновить [...] он просто не пройдёт > сборочницу из-за одного фундаментального изменения, которое произошло > в 2012 году. А что там стряслось? > Так что, я сомневаюсь, что богатыри обновлят его в ближайшей перспективе. Особенно шикарно это прозвучало сегодня, когда что-то еле поднялся...
(В ответ на комментарий №18) > (В ответ на комментарий №15) > > Я знаю, что так просто syslinux не обновить [...] он просто не пройдёт > > сборочницу из-за одного фундаментального изменения, которое произошло > > в 2012 году. > А что там стряслось? Switched from the COM32 object format to ELF as it is a much more powerful format that allows undefined symbols to be resolved at runtime and dynamic loading of module dependencies, which means modules now become shared object files instead of statically linked binaries - reducing both disk space and runtime memory consumption. Эти файлы выполняются не в живой системе, а в загрузчике и их ELF файлы просто файлы и ни о какой правильной линковке речи не идёт т.к. им там это не нужно. i586: NEW bad_elf_symbols detected: extlinux.rpm /boot/extlinux/cat.c32 U _fread extlinux.rpm /boot/extlinux/cat.c32 U _fwrite extlinux.rpm /boot/extlinux/chain.c32 U lfree extlinux.rpm /boot/extlinux/chain.c32 U lmalloc extlinux.rpm /boot/extlinux/chain.c32 U syslinux_force_text_mode extlinux.rpm /boot/extlinux/cmd.c32 U com32_cmdline extlinux.rpm /boot/extlinux/cptime.c32 U __ms_timer extlinux.rpm /boot/extlinux/cptime.c32 U _fread Наша сборочница видит ELF и проверяет символы. Она просто не пропустит такие ELF'ы. Мы с ldv не нашли способа, как научить её их правильно обарабатывать. Насколько помню мы смогли найти почти все символы, кроме com32_cmdline, который представляется внутри бинарника extlinux. Сейчас в сборочнице действует исключение для файлов в /boot и такое исключение меня вполне устраивает, но вот для syslinux этот вариант не подойдёт т.к. syslinux хранит файлы не в /boot. Дима говорил, что если рассматривать эти файлы, как файлы другой природы, то их тоже надо будет игнорировать. Вопрос только по какому принципу. > > Так что, я сомневаюсь, что богатыри обновлят его в ближайшей перспективе. > Особенно шикарно это прозвучало сегодня, когда что-то еле поднялся... Тогда я бы хотел, чтобы это звучало, как пожелание богатырского здоровья.
> > Тут стоит дополнить: об этом мало кто знает. Раньше дистрибутивы предлагали > > выбор между lilo и grub. > Я знаю, поверьте. Имелось ввиду совсем другое! Отвечаю абзацем ниже (заодно Антону): > syslinux действительно требует обновления, в том числе с точки зрения сборки > на EFI (если он поддерживает EFI, конечно, а не просто GPT). > из пакета syslinux было бы неплохо собрать и бинарь extlinux. http://www.rodsbooks.com/efi-bootloaders/ - на эту информацию ориентировались при создании альтовых решений, совместимых с EFI. Не так давно информация в первоисточнике была актуализирована и при более внимательном рассмотрении открываются возможности, которые мы в текущей ситуации использовать не можем. В качестве примера приведу три типовых юзэкейса: 1. Универсальная загрузочная флэшка FAT32 (разметка MBR, единственный активный раздел), которая может грузить уйму систем, ядер, initrd. Никаких ISO-Hybrid, просто syslinux-загрузчик + меню + разложенные по папочкам образы. С версией 6+ это будет работать не только на BIOS, но и на EFI. Если кто не в курсе, для EFI совершенно необязательна GPT, эта разметка нужна только для дисков >2Тб. 2. Выкинуть из нашего JeOS lilo и заменить его на extlinux. Кому нужен блэкжек и прочие радости, ставят не JeOS или руками до-устанавливают grub2&Ко. Для EFI-систем вместо extlinux ставим syslinux с тем же меню и той же версии. Считайте, это будет как отдельный /boot раздел. И наш JeOS становится более универсальным. Пока же мы можем предложить минимальную систему только для Legacy-BIOS загрузки. 3. Для большинства по крайней мере серверных систем не требуется ни плимут, ни графическое меню загрузчика, ни "ОС grub2", достаточно ванильного extlinux (либо syslinux на отдельном разделе FAT32 для систем с EFI). Вопреки устаревших убеждений, он прекрасно грузится и с аппаратных рейдов, и с программного зеркала md (raid-1). (In reply to comment #14) > О чём вы спорите ? Да какой же это спор! Напротив, я очень благодарен Алексею Гладкову за эту важную и познавательную дискуссию на тему плачевного состояния загрузчиков syslinux/extlinux в ALT Linux. Теперь я знаю, что пакеты в Сизифе с одной и той же функциональностью под разными названиями, равно как и "форки" -- это норма для Сизифа. Для меня открылось, что Сизиф -- это место для "своих личных" пакетов. Если серьёзно, Алексей обозначил статус пакета "extlinux" в Сизифе и теперь понятно, почему в "его личных" пакетах "паразитных" зависимостей быть не может. :) Ну, и без троллинга не обошлось: > Если кто-нибудь придумает как получить эту информацию > без parted, то выкину его мгновенно. > С другой стороны не вижу, кому она может мешать. > Что вы хотите получить ? > Вы где это хотите использовать ? > Чего вы хотите от меня ? > Если же вас смущает название пакета, то я могу переименовать его в extloader > Хорошо. Я переименую пакет > В целом, переименование пакета это хороший способ для меня спрятаться в кусты > Хе! А мне и не нужно ничего переименовывать. У нас уже есть пакет > Про троллинг я говорил о себе и моих вопросах :) :D
(В ответ на комментарий №20) > Для меня открылось, что Сизиф -- это место для "своих личных" > пакетов. Это можно сказать о практически всех моих пакетах :) > Если серьёзно, Алексей обозначил статус пакета "extlinux" в Сизифе и > теперь понятно, почему в "его личных" пакетах "паразитных" зависимостей быть не > может. :) Я этого говорил. Я также не говорил, что "моими личными" пакетами не могут пользоваться другие и их нельзя менять в сторону большего удобства. > > Если кто-нибудь придумает как получить эту информацию > > без parted, то выкину его мгновенно. > > С другой стороны не вижу, кому она может мешать. > > Что вы хотите получить ? > > Вы где это хотите использовать ? > > Чего вы хотите от меня ? > > Если же вас смущает название пакета, то я могу переименовать его в extloader > > Хорошо. Я переименую пакет > > В целом, переименование пакета это хороший способ для меня спрятаться в кусты > > Хе! А мне и не нужно ничего переименовывать. У нас уже есть пакет > > Про троллинг я говорил о себе и моих вопросах :) > > :D Эм ... я уже старинкий и уже подзабыл почему этот пакет так назван и какой пакет был форкнут :) А вместе с тем эта работа уже была когда-то проделана и даже конфликты расставлены.
Created attachment 7432 [details] no-parted.patch Ввиду некоторого недопонимания, выложу сюда сделанное, вдруг кому пригодится. Не выкидывать же! Но я этот код не проверял ни в каком режиме, даже не пробовал пакет пересобрать. Там могут быть ошибки, в т.ч. в адресной арифметике.
(В ответ на комментарий №22) > Ввиду некоторого недопонимания, выложу сюда сделанное, вдруг кому пригодится. > Не выкидывать же! Но я этот код не проверял ни в каком режиме, даже не пробовал > пакет пересобрать. Там могут быть ошибки, в т.ч. в адресной арифметике. Эм ... ну ладно.
(В ответ на комментарий №23) > Эм ... ну ладно. Просто вчера не было времени тестировать. Да и не понимаю пока, как это лучше сделать. "Выкусил" из скрипта всё необходимое и проверял на трёх виртуалках с EFI и MBR. По MBR в первом приближении вопросов не возникло, там всё чётко. По EFI не могу гарантировать. И сам до сих пор логику не понимаю. Стандартные тулзы про legacy-boot ничего не знают и не пишут. Либо я всё время попадаю в байт, где бит #1 установлен, либо любая GPT-партиция #8300 заведомо legacy-boot... Видимо придётся продолжить тестировать, сверяясь по выводу parted. Если нужно, могу скинуть "выкушенный" скрипт или сюда его приложить. Ну и собраться пакет с этими изменениями конечно собрался (task #202375). Вопрос только в том, как это ПРАВИЛЬНО проверять.
Полностью рабочий и с MBR, и с GPT код можно посмотреть теперь в task #202381. А в выше приложенном к сабжу патче были ошибки.
(В ответ на комментарий №25) > Полностью рабочий и с MBR, и с GPT код можно посмотреть теперь в task #202381. > А в выше приложенном к сабжу патче были ошибки. У меня всё правильно определило. Спасибо, но к вашему коду есть несколько вопросов. Это башизм: ``` +[ "$magic" = $'\x55\xAA' ] || ``` Вы уверены, что хотите привязать к пакету bash ?
(В ответ на комментарий №26) > Вы уверены, что хотите привязать к пакету bash ? Напротив, чем меньше зависимостей, тем лучше. Вообще удивился, почему `ls -l /bin/sh` говорит, что это ELF, а не симлинк, а этот ELF говорит, что он bash 3 версии. :) > +[ "$magic" = $'\x55\xAA' ] || Наверняка можно выкрутиться. Чем-нибудь таким заменить: +[ "$magic" = "$(printf '\x55\xAA')" ] || Если не катит, тогда вернуть, как предлагалось выше с base64. Куда интереснее, что именно эта конструкция не вызывает никаких отторжений у Mellanox'овского busybox'а. На нём тоже проверял, хотя и позже. Но там три конструкции пришлось поменять: 1) status=none пришлось вернуть на уродливый 2>/dev/null для всех dd; 2) s/readlink -ev/readlink -fv/ в sysfs_path=... 3) dd...|hexdump '-e"%x"' в read_entry() оказался нерабочим. Заработало так: local x="$(dd if="$dev" bs=1 skip=$offset count=1 2>/dev/null)" printf "%u" "'$x" Но это очень куцый busybox с не пойми чем внутри, для тестов вполне пригоден. По крайней мере, версию bash он не выводит, что наводит на мысль, что это всё-таки POSIX-shell.
(В ответ на комментарий №27) > > +[ "$magic" = $'\x55\xAA' ] || > > Наверняка можно выкрутиться. Чем-нибудь таким заменить: > > +[ "$magic" = "$(printf '\x55\xAA')" ] || Так лучше. Хочу ещё отметить, что вся арифметика тоже не posix-овая у вас. Я могу это исправить, когда патч буду прикладывать. > Но это очень куцый busybox с не пойми чем внутри, для тестов вполне пригоден. > По крайней мере, версию bash он не выводит, что наводит на мысль, что это > всё-таки POSIX-shell. Чтобы быть увереннее проверьте с dash. Апстримный busybox содержит именно его.
Created attachment 7435 [details] Тестовый скрипт Этим скриптом ещё раз протестировал на всех конфигурациях. Видимо, башизмов не осталось, раз работает без изменений. :) В busybox dash не оказалось, там пришлось поменять шабанг. Но всё равно будет интересно увидеть в конечном виде Ваши исправления.
(В ответ на комментарий №29) > Этим скриптом ещё раз протестировал на всех конфигурациях. Видимо, башизмов не > осталось, раз работает без изменений. :) В busybox dash не оказалось, там > пришлось поменять шабанг. Но всё равно будет интересно увидеть в конечном виде > Ваши исправления. Посмотрите пожалуйста: http://git.altlinux.org/people/legion/packages/extlinux.git?p=extlinux.git;a=shortlog;h=refs/heads/rpm
(В ответ на комментарий №30) > (В ответ на комментарий №29) > > Но всё равно будет интересно увидеть в конечном виде Ваши исправления. > > Посмотрите пожалуйста: Всё классно, только не нашёл там кнопки "Like"! :) Честно удивился, когда Вы согласились принять ЭТО. Понятно, что и на шеле можно писать, как на ассемблере, но читабельность и понимание таким кодом мы ухудшаем. Поэтому я думал, что Вам будет сподручней разделить пакет, как предлагали Gremlin и Антон. Возник ещё вопрос по строке, которая там была раньше: dev="$(sed -n -e 's,^DEVNAME=,/dev/,p' "${sysfs_path%/*}/uevent")" Будет ли здесь значение ожидаемым в системе, где нет udev? Скорее да, но на всякий случай...
(В ответ на комментарий №31) > Всё классно, только не нашёл там кнопки "Like"! :) Честно удивился, когда Вы > согласились принять ЭТО. Понятно, что и на шеле можно писать, как на > ассемблере, но читабельность и понимание таким кодом мы ухудшаем. Да, читабильность несколько упала, но разобраться можно. Если кто-то не сможет, то знает кого благодарить. git всё помнит. Конечно, если бы был развёрнутый комментарий, то было бы лучше. Если вы напишите, то я буду очень благодарен! :) Но в крайнем случае у меня есть старый вариант в git'е :) > Поэтому я > думал, что Вам будет сподручней разделить пакет, как предлагали Gremlin и > Антон. Для меня пакет extlinux без скриптов настройки. > Возник ещё вопрос по строке, которая там была раньше: > > dev="$(sed -n -e 's,^DEVNAME=,/dev/,p' "${sysfs_path%/*}/uevent")" > > Будет ли здесь значение ожидаемым в системе, где нет udev? Скорее да, но на > всякий случай... Будет. Это никакого отношения к udev не имеет. Это sysfs.
(В ответ на комментарий №32) > Конечно, если бы был развёрнутый > комментарий, то было бы лучше. Если вы напишите, то я буду очень благодарен! Моего английского боятся и не понимают! :) Но попробую... Change to tear off the "parted" package and its dependencies. The same actions are performed in several direct disk read operations. First, 2-bytes MBR-signature at address 510 (end of the first sector) is read. It should be read as 0x55, 0xAA. Then 8-bytes GPT-signature "EFI PART" is checked at the beginning of the second sector of the disk. MBR partition table starts at offset 446, each element of the table occupying 16 bytes. The 0th byte of the element must have 0x80 value for the boot partition. The GPT-header begins in the second sector of the disk. 4 bytes from offset 80 (0x50) at the header start contain the number of table elements in little-endian, the next 4 bytes from offset 84 (0x54) contain the size of a single partition entry, usually 128 bytes. These two numbers are obtained by the function read_gpt(). GPT partition table begins in the third sector of the disk. If the bit "2" of the byte of the table element at offset 48 is set, the partition is marked as bootable in the Legacy BIOS. This "attributes" byte is obtained by the function read_entry(). Только не спрашивайте, что значит атрибут legacy_bios_bootable! Сам этого не понимаю и даже по-русски не знаю, как объяснить! EFI (а только она и умеет работать с GPT) этот атрибут не использует для определения, откуда грузить систему. Legacy BIOS не может брать информацию из GPT, и в этом случае MBR там фейковый (защитный). Утилиты конвертации типа sgdisk этот бит теряют. Я так понял, если прошивка машины поддерживает и переведена из режима EFI в Legacy режим, теоретически есть шанс с такого диска загрузиться в Legacy-режиме. Но я в этом не уверен, нужно вычитывать спецификацию UEFI, которая определяет и формат GUID/GPT.
(В ответ на комментарий №32) > Если кто-то не сможет, то знает кого благодарить. git всё помнит. Пока сочинял комментарий, возникло сомнение по этой строке: magic="$(dd if="$dev" bs=8 skip=64 count=1 2>/dev/null)" Это рабочий вариант, если размер логического сектора равен 512 байтам. В 99.9% случаев это так. Мне ещё не попадалось AF-дисков Native4K, но думаю и там логический сектор будет 512 байт. Тем не менее, надёжнее переписать так: magic="$(dd if="$dev" bs=1 skip=$sector_size count=8 2>/dev/null)" Иначе и в функциях вместо $sector_size можно было бы использовать константу 512.
http://git.altlinux.org/people/legion/packages/extlinux.git?p=extlinux.git;a=commit;h=9b9986cbe7f2863199ced92ab49a7706bc857abc Looks good ?
Created attachment 7446 [details] comments.patch (В ответ на комментарий №35) > Looks good ? Смотрится отлично, хотя вот это предложение не очень понятно: MBR partition table starts at the function read_gpt(). Поэтому предлагаю (на Ваше усмотрение) такой вариант...
Applied. Thanks!
Вы ещё говорили про EFI. Хотите его тоже добавить ?
(В ответ на комментарий №38) > Вы ещё говорили про EFI. Хотите его тоже добавить ? По моим (возможно устаревшим) убеждениям, extlinux для другого, а для EFI нужен syslinux. Наиболее корректно попытался описать вероятное использование в сообщении #20. Если всё-таки я заблуждаюсь, и extlinux можно задействовать для загрузки с GUID/GPT ESP или FAT32-раздела в Legacy BIOS, то обеими руками буду "ЗА". Но, на всякий случай, чтобы не дублировать и тратить зря силы, попросил Гремлина и он уже занимается (разбирается) с апстримным syslinux в том варианте, который Вы обсуждали с Антоном выше. Версию с gfxboot не трогаем, всё остальное надо сделать по-человечески и назвать как-нибудь типа syslinux-vanilla или syslinux-base.
(В ответ на комментарий №39) > По моим (возможно устаревшим) убеждениям, extlinux для другого, а для EFI нужен > syslinux. Код один. Есть три цели в Makefile: bios efi32 efi64 Сейчас я собираю только bios. > Наиболее корректно попытался описать вероятное использование в > сообщении #20. Если всё-таки я заблуждаюсь, и extlinux можно задействовать для > загрузки с GUID/GPT ESP или FAT32-раздела в Legacy BIOS, то обеими руками буду > "ЗА". Но, на всякий случай, чтобы не дублировать и тратить зря силы, попросил > Гремлина и он уже занимается (разбирается) с апстримным syslinux в том > варианте, который Вы обсуждали с Антоном выше. Версию с gfxboot не трогаем, всё > остальное надо сделать по-человечески и назвать как-нибудь типа > syslinux-vanilla или syslinux-base. OK.
(В ответ на комментарий №37) > Applied. Thanks! Так это Вам спасибо! (В ответ на комментарий №38) > Вы ещё говорили про EFI. Хотите его тоже добавить ? С одной стороны, есть утверждение, что начиная с 4-й версии syslinux и extlinux это одно и то же. Не берусь судить, правда ли это. С другой стороны, для относительно новых ядер, собранных с CONFIG_EFI_STUB=y, загрузчик в EFI не нужен, ядро может само выступать в его роли. Поскольку наше ядро собрано с этой опцией, вариант без дополнительного загрузчика для EFI-систем очень даже привлекательно выглядит. Для Legacy BIOS и pure-linux-fs -- extlinux.
