Bug 34481 - паразитная зависимость от parted
: паразитная зависимость от parted
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/extlinux)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2018-01-25 16:40 by
Modified: 2018-03-24 01:32 (History)


Attachments
no-parted.patch (3.10 KB, patch)
2018-03-17 04:39, Leonid Krivoshein
no flags Details | Diff
Тестовый скрипт (1.73 KB, application/x-shellscript)
2018-03-19 01:06, Leonid Krivoshein
no flags Details
comments.patch (3.01 KB, patch)
2018-03-23 01:06, Leonid Krivoshein
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2018-01-25 16:40:43
# rpm -qR extlinux-6.03-alt1.x86_64
libshell
util-linux
parted
...
------- Comment #1 From 2018-01-25 17:03:58 -------
Не паразитная.
------- Comment #2 From 2018-01-29 19:53:57 -------
Ой, а зачем он там?
------- Comment #3 From 2018-01-29 23:02:26 -------
Ребята, ну нельзя же быть такими ленивыми. Ведь даже клонировать к себе
репозиторий не нужно:

http://git.altlinux.org/gears/e/extlinux.git?p=extlinux.git&a=search&h=HEAD&st=grep&s=parted

Если кто-нибудь придумает как получить эту информацию без parted, то выкину его
мгновенно. С другой стороны не вижу, кому она может мешать.
------- Comment #4 From 2018-03-15 15:05:23 -------
(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

Полагаю, список не исчерпывающий.
------- Comment #5 From 2018-03-15 15:17:20 -------
Вижу довольно простое решение: вынести скрипт в 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 :-)
------- Comment #6 From 2018-03-15 15:33:31 -------
(In reply to comment #5)
> и сравнить вывод с волшебным числом 076a27c7 - если совпадает, то это MBR :-)

У меня на MBR показал 99ed8546, на ONIE/GPT 93928b26, на других машинах и
дисках с GUID/GPT: d7b907074d, 40e7b3d0, a997bcd9.

Но если использовать не второй сектор диска и не использовать sha256sum, думаю,
вытащить все данные будет можно самым кошерным способом.
------- Comment #7 From 2018-03-15 15:36:02 -------
Мне тут подсказывают, что шутка про различия MBR и GPT может быть воспринята
всерьез, поэтому вот решение, полностью соответствующее стандарту:

dd bs=8 skip=64 count=1 "if=$dev" | xxd -p

Если выдаст 0000000000000000 - MBR, если 4546492050415254 ("EFI PART") - GPT.
Другие значения являются признаком того, что на диске записано что-то
неизвестное, и во избежание повреждения данных на него лучше ничего не писать.
------- Comment #8 From 2018-03-15 16:05:29 -------
(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), а там совсем другое. На других
системах, где сектора начиная со второго и до начала первого раздела не
используются, там не обязательно будут нули. Только если диск специально
почистили. Но также там может быть код какого-то другого загрузчика.
------- Comment #9 From 2018-03-15 21:33:34 -------
(В ответ на комментарий №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
------- Comment #10 From 2018-03-16 01:00:28 -------
(В ответ на комментарий №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 для решения той же задачи, а уж они есть в любой
системе.
------- Comment #11 From 2018-03-16 01:36:14 -------
(В ответ на комментарий №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+блэкджек+женщины+все_остальные_радости
------- Comment #12 From 2018-03-16 03:30:20 -------
(В ответ на комментарий №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. Я могу улучшить лишь свой пакет и могу попробовать сделать его
более пригодным.
------- Comment #13 From 2018-03-16 03:33:41 -------
Если же вас смущает название пакета, то я могу переименовать его в extloader
например, чтобы дать дорогу богатырям.
------- Comment #14 From 2018-03-16 07:47:50 -------
О чём вы спорите ?
extlinux надо собирать в рамках исходников syslinux. А этот - переименовать что
бы никого не смущал.

syslinux действительно требует обновления, в том числе с точки зрения сборки на
EFI (если он поддерживает EFI, конечно, а не просто GPT).
из пакета syslinux было бы неплохо собрать и бинарь extlinux. Который, как раз,
положить в пакет extlinux.

Лёш, может быть тебе в рамках этих перетрубаций сделать отдельный пакет
extloader, с твоей обвязкой и зависимостью на пакет extlinux ?
------- Comment #15 From 2018-03-16 12:53:44 -------
(В ответ на комментарий №14)
> О чём вы спорите ?

О! Антон, тут твои клиенты. Пользователи хотят большей актуальности,
поддерживаемости и большего функционала от syslinux.

> extlinux надо собирать в рамках исходников syslinux. А этот - переименовать что
> бы никого не смущал.

Да, неправильно вводить людей в заблуждение, что я имею отношение к syslinux.

> syslinux действительно требует обновления, в том числе с точки зрения сборки на
> EFI (если он поддерживает EFI, конечно, а не просто GPT).
> из пакета syslinux было бы неплохо собрать и бинарь extlinux. Который, как раз,
> положить в пакет extlinux.

Это похоже на хороший план ))

> Лёш, может быть тебе в рамках этих перетрубаций сделать отдельный пакет
> extloader, с твоей обвязкой и зависимостью на пакет extlinux ?

Хорошо. Я переименую пакет, но зависимость делать не буду. Во-первых сейчас
зависимость ставить просто не на что. Во-вторых у syslinux и у моего разные
задачи и как следствие циклы обновления. Мне важны новые релизы и фичи
extlinux, а в syslinux важна стабильность.

Я знаю, что так просто syslinux не обновить. Даже если отвлечься, что
обновление скорее всего сломает дистро-пекарей, он просто не пройдёт сборочницу
из-за одного фундаментального изменения, которое произошло в 2012 году. Так
что, я сомневаюсь, что богатыри обновлят его в ближайшей перспективе. Кроме
того, для правильной работы extlinux в syslinux из коробки предётся написать
скрипты опять же.

В целом, переименование пакета это хороший способ для меня спрятаться в кусты
))
------- Comment #16 From 2018-03-16 13:05:28 -------
Хе! А мне и не нужно ничего переименовывать. У нас уже есть пакет
syslinux-extlinux и он собран из syslinux. У меня есть конфликт. Поэтому я вам
мешать не могу никак.
------- Comment #17 From 2018-03-16 14:21:33 -------
Более того, ментейнеры syslinux - zerg и mike.
------- Comment #18 From 2018-03-16 14:42:53 -------
(В ответ на комментарий №15)
> Я знаю, что так просто syslinux не обновить [...] он просто не пройдёт
> сборочницу из-за одного фундаментального изменения, которое произошло
> в 2012 году.
А что там стряслось?

> Так что, я сомневаюсь, что богатыри обновлят его в ближайшей перспективе. 
Особенно шикарно это прозвучало сегодня, когда что-то еле поднялся...
------- Comment #19 From 2018-03-16 17:10:25 -------
(В ответ на комментарий №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. Дима говорил,
что если рассматривать эти файлы, как файлы другой природы, то их тоже надо
будет игнорировать. Вопрос только по какому принципу.

> > Так что, я сомневаюсь, что богатыри обновлят его в ближайшей перспективе. 
> Особенно шикарно это прозвучало сегодня, когда что-то еле поднялся...

Тогда я бы хотел, чтобы это звучало, как пожелание богатырского здоровья.
------- Comment #20 From 2018-03-16 17:47:02 -------
> > Тут стоит дополнить: об этом мало кто знает. Раньше дистрибутивы предлагали
> > выбор между 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
------- Comment #21 From 2018-03-16 20:30:46 -------
(В ответ на комментарий №20)
> Для меня открылось, что Сизиф -- это место для "своих личных"
> пакетов.

Это можно сказать о практически всех моих пакетах :) 

> Если серьёзно, Алексей обозначил статус пакета "extlinux" в Сизифе и
> теперь понятно, почему в "его личных" пакетах "паразитных" зависимостей быть не
> может. :)

Я этого говорил. Я также не говорил, что "моими личными" пакетами не могут
пользоваться другие и их нельзя менять в сторону большего удобства.

> > Если кто-нибудь придумает как получить эту информацию
> > без parted, то выкину его мгновенно.
> > С другой стороны не вижу, кому она может мешать.
> > Что вы хотите получить ?
> > Вы где это хотите использовать ?
> > Чего вы хотите от меня ?
> > Если же вас смущает название пакета, то я могу переименовать его в extloader
> > Хорошо. Я переименую пакет
> > В целом, переименование пакета это хороший способ для меня спрятаться в кусты
> > Хе! А мне и не нужно ничего переименовывать. У нас уже есть пакет
> > Про троллинг я говорил о себе и моих вопросах :)
> 
> :D

Эм ... я уже старинкий и уже подзабыл почему этот пакет так назван и какой
пакет был форкнут :)
А вместе с тем эта работа уже была когда-то проделана и даже конфликты
расставлены.
------- Comment #22 From 2018-03-17 04:39:51 -------
Created an attachment (id=7432) [details]
no-parted.patch

Ввиду некоторого недопонимания, выложу сюда сделанное, вдруг кому пригодится.
Не выкидывать же! Но я этот код не проверял ни в каком режиме, даже не пробовал
пакет пересобрать. Там могут быть ошибки, в т.ч. в адресной арифметике.
------- Comment #23 From 2018-03-17 21:22:38 -------
(В ответ на комментарий №22)
> Ввиду некоторого недопонимания, выложу сюда сделанное, вдруг кому пригодится.
> Не выкидывать же! Но я этот код не проверял ни в каком режиме, даже не пробовал
> пакет пересобрать. Там могут быть ошибки, в т.ч. в адресной арифметике.

Эм ... ну ладно.
------- Comment #24 From 2018-03-18 00:55:06 -------
(В ответ на комментарий №23)
> Эм ... ну ладно.

Просто вчера не было времени тестировать. Да и не понимаю пока, как это лучше
сделать. "Выкусил" из скрипта всё необходимое и проверял на трёх виртуалках с
EFI и MBR. По MBR в первом приближении вопросов не возникло, там всё чётко. По
EFI не могу гарантировать. И сам до сих пор логику не понимаю. Стандартные
тулзы про legacy-boot ничего не знают и не пишут. Либо я всё время попадаю в
байт, где бит #1 установлен, либо любая GPT-партиция #8300 заведомо
legacy-boot... Видимо придётся продолжить тестировать, сверяясь по выводу
parted. Если нужно, могу скинуть "выкушенный" скрипт или сюда его приложить. Ну
и собраться пакет с этими изменениями конечно собрался (task #202375). Вопрос
только в том, как это ПРАВИЛЬНО проверять.
------- Comment #25 From 2018-03-18 15:44:46 -------
Полностью рабочий и с MBR, и с GPT код можно посмотреть теперь в task #202381.
А в выше приложенном к сабжу патче были ошибки.
------- Comment #26 From 2018-03-18 17:21:48 -------
(В ответ на комментарий №25)
> Полностью рабочий и с MBR, и с GPT код можно посмотреть теперь в task #202381.
> А в выше приложенном к сабжу патче были ошибки.

У меня всё правильно определило. Спасибо, но к вашему коду есть несколько
вопросов. Это башизм:

```
+[ "$magic" = $'\x55\xAA' ] ||
```

Вы уверены, что хотите привязать к пакету bash ?
------- Comment #27 From 2018-03-18 18:55:08 -------
(В ответ на комментарий №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.
------- Comment #28 From 2018-03-18 20:53:16 -------
(В ответ на комментарий №27)
> > +[ "$magic" = $'\x55\xAA' ] ||
> 
> Наверняка можно выкрутиться. Чем-нибудь таким заменить:
> 
> +[ "$magic" = "$(printf '\x55\xAA')" ] ||

Так лучше.

Хочу ещё отметить, что вся арифметика тоже не posix-овая у вас. Я могу это
исправить, когда патч буду прикладывать.

> Но это очень куцый busybox с не пойми чем внутри, для тестов вполне пригоден.
> По крайней мере, версию bash он не выводит, что наводит на мысль, что это
> всё-таки POSIX-shell.

Чтобы быть увереннее проверьте с dash. Апстримный busybox содержит именно его.
------- Comment #29 From 2018-03-19 01:06:12 -------
Created an attachment (id=7435) [details]
Тестовый скрипт

Этим скриптом ещё раз протестировал на всех конфигурациях. Видимо, башизмов не
осталось, раз работает без изменений. :) В busybox dash не оказалось, там
пришлось поменять шабанг. Но всё равно будет интересно увидеть в конечном виде
Ваши исправления.
------- Comment #30 From 2018-03-22 00:49:27 -------
(В ответ на комментарий №29)
> Этим скриптом ещё раз протестировал на всех конфигурациях. Видимо, башизмов не
> осталось, раз работает без изменений. :) В busybox dash не оказалось, там
> пришлось поменять шабанг. Но всё равно будет интересно увидеть в конечном виде
> Ваши исправления.

Посмотрите пожалуйста:

http://git.altlinux.org/people/legion/packages/extlinux.git?p=extlinux.git;a=shortlog;h=refs/heads/rpm
------- Comment #31 From 2018-03-22 02:06:37 -------
(В ответ на комментарий №30)
> (В ответ на комментарий №29)
> > Но всё равно будет интересно увидеть в конечном виде Ваши исправления.
> 
> Посмотрите пожалуйста:

Всё классно, только не нашёл там кнопки "Like"! :) Честно удивился, когда Вы
согласились принять ЭТО. Понятно, что и на шеле можно писать, как на
ассемблере, но читабельность и понимание таким кодом мы ухудшаем. Поэтому я
думал, что Вам будет сподручней разделить пакет, как предлагали Gremlin и
Антон.

Возник ещё вопрос по строке, которая там была раньше:

dev="$(sed -n -e 's,^DEVNAME=,/dev/,p' "${sysfs_path%/*}/uevent")"

Будет ли здесь значение ожидаемым в системе, где нет udev? Скорее да, но на
всякий случай...
------- Comment #32 From 2018-03-22 02:27:14 -------
(В ответ на комментарий №31)
> Всё классно, только не нашёл там кнопки "Like"! :) Честно удивился, когда Вы
> согласились принять ЭТО. Понятно, что и на шеле можно писать, как на
> ассемблере, но читабельность и понимание таким кодом мы ухудшаем.

Да, читабильность несколько упала, но разобраться можно. Если кто-то не сможет,
то знает кого благодарить. git всё помнит. Конечно, если бы был развёрнутый
комментарий, то было бы лучше. Если вы напишите, то я буду очень благодарен! :)

Но в крайнем случае у меня есть старый вариант в git'е :)

> Поэтому я
> думал, что Вам будет сподручней разделить пакет, как предлагали Gremlin и
> Антон.

Для меня пакет extlinux без скриптов настройки.

> Возник ещё вопрос по строке, которая там была раньше:
> 
> dev="$(sed -n -e 's,^DEVNAME=,/dev/,p' "${sysfs_path%/*}/uevent")"
> 
> Будет ли здесь значение ожидаемым в системе, где нет udev? Скорее да, но на
> всякий случай...

Будет. Это никакого отношения к udev не имеет. Это sysfs.
------- Comment #33 From 2018-03-22 03:43:02 -------
(В ответ на комментарий №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.
------- Comment #34 From 2018-03-22 04:00:38 -------
(В ответ на комментарий №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.
------- Comment #36 From 2018-03-23 01:06:22 -------
Created an attachment (id=7446) [details]
comments.patch

(В ответ на комментарий №35)
> Looks good ?

Смотрится отлично, хотя вот это предложение не очень понятно:
MBR partition table starts at the function read_gpt().

Поэтому предлагаю (на Ваше усмотрение) такой вариант...
------- Comment #37 From 2018-03-23 11:59:48 -------
Applied. Thanks!
------- Comment #38 From 2018-03-23 12:13:40 -------
Вы ещё говорили про EFI. Хотите его тоже добавить ?
------- Comment #39 From 2018-03-23 22:59:13 -------
(В ответ на комментарий №38)
> Вы ещё говорили про EFI. Хотите его тоже добавить ?

По моим (возможно устаревшим) убеждениям, extlinux для другого, а для EFI нужен
syslinux. Наиболее корректно попытался описать вероятное использование в
сообщении #20. Если всё-таки я заблуждаюсь, и extlinux можно задействовать для
загрузки с GUID/GPT ESP или FAT32-раздела в Legacy BIOS, то обеими руками буду
"ЗА". Но, на всякий случай, чтобы не дублировать и тратить зря силы, попросил
Гремлина и он уже занимается (разбирается) с апстримным syslinux в том
варианте, который Вы обсуждали с Антоном выше. Версию с gfxboot не трогаем, всё
остальное надо сделать по-человечески и назвать как-нибудь типа
syslinux-vanilla или syslinux-base.
------- Comment #40 From 2018-03-24 01:27:51 -------
(В ответ на комментарий №39)
> По моим (возможно устаревшим) убеждениям, extlinux для другого, а для EFI нужен
> syslinux.

Код один. Есть три цели в Makefile: bios efi32 efi64
Сейчас я собираю только bios.

> Наиболее корректно попытался описать вероятное использование в
> сообщении #20. Если всё-таки я заблуждаюсь, и extlinux можно задействовать для
> загрузки с GUID/GPT ESP или FAT32-раздела в Legacy BIOS, то обеими руками буду
> "ЗА". Но, на всякий случай, чтобы не дублировать и тратить зря силы, попросил
> Гремлина и он уже занимается (разбирается) с апстримным syslinux в том
> варианте, который Вы обсуждали с Антоном выше. Версию с gfxboot не трогаем, всё
> остальное надо сделать по-человечески и назвать как-нибудь типа
> syslinux-vanilla или syslinux-base.

OK.
------- Comment #41 From 2018-03-24 01:32:55 -------
(В ответ на комментарий №37)
> Applied. Thanks!

Так это Вам спасибо!

(В ответ на комментарий №38)
> Вы ещё говорили про EFI. Хотите его тоже добавить ?

С одной стороны, есть утверждение, что начиная с 4-й версии syslinux и extlinux
это одно и то же. Не берусь судить, правда ли это. С другой стороны, для
относительно новых ядер, собранных с CONFIG_EFI_STUB=y, загрузчик в EFI не
нужен, ядро может само выступать в его роли. Поскольку наше ядро собрано с этой
опцией, вариант без дополнительного загрузчика для EFI-систем очень даже
привлекательно выглядит. Для Legacy BIOS и pure-linux-fs -- extlinux.