boot manager for GPT

Alex Korchmar написал(а) к Victor Sudakov в May 18 12:42:40 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS> Так я могу его поставить прямо с LiveCD debian8, нет?
возьми и проверь, мне-то он зачем?

я даже не имею понятия, как именно этот уродец нынче ставится.

> Alex

--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Alex Korchmar в May 18 23:24:10 по местному времени:

Dear Alex,

05 May 18 12:42, Alex Korchmar wrote to me:
AK> Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS>> Так я могу его поставить прямо с LiveCD debian8, нет?
AK> возьми и проверь, мне-то он зачем?

Откуда-то же про патчи из debian8 пакета знаешь?

AK> я даже не имею понятия, как именно этот уродец нынче ставится.

Файлики-модули свои и grub.cfg кладет на раздел с partition type efi (можно FAT), а cвой second stage на раздел с типом bios-boot (без FS). Ну и в MBR что-то такое записывает, что умеет передавать управление на bios-boot раздел.

Это я с эхотажным sysutils/grub2, линуксовый может и как-то иначе.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Alex Korchmar написал(а) к Victor Sudakov в May 18 23:24:56 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

AK>> возьми и проверь, мне-то он зачем?
VS> Откуда-то же про патчи из debian8 пакета знаешь?
где-то читал, что они починили "опять".

> Alex

--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Eugene Grosbein в May 18 10:19:08 по местному времени:

Dear Eugene,

04 May 18 17:49, you wrote to me:

VS>>>> А вот GPT вещь хорошая и удобная. Количество разделов не
VS>>>> ограничено,
EG>>> У MBR/bsdlabel тоже практически не ограничено: 4*20=80 штук.
VS>> Но bsdlabel никто не понимает, кроме BSD. А в случае GPT можно
VS>> унести диск на Linux/Windows и надеятся, что они поймут, что там
VS>> такое. А если и не поймут, то увидят Protective MBR и хотя бы
VS>> диск не запорют (наверное).

EG> Зачем тебе неограниченное количество разделов на носимом диске-то?
EG> Одного FAT32/NTS в MBR недостаточно для обмена данными?

На носимом диске уже давно недостаточно FAT32 из-за ограничения размера файла в 4 Гб. А NTFS FreeBSD не умеет нормально на запись. Выручил бы exfat, но его нет не только в базовой системе, но даже в бинарных пакетах из-за каких-то лицензионных ограничений. И они оба (rw NTFS и exfat) только через fuse.

Но речь ведь не обязательно про носимый диск. Вот к примеру первые два пришедших в голову сценария.

1. Делается ТО компа с FreeBSD, железячник загружает его с хитрого ремонтного flash/DVD для проверки железа. Лучше если его инструменты будут видеть на диске нечто знакомое им, а то ещё попытаются чинить. Собственно Protective MBR на такой случай и придуман.

2. Комп с FreeBSD умер, снимаем диск и несем куда-то считывать с него данные, или загружать на другой системе. Далее см. п. 1.


VS>>>> можно давать разделам метки и монтировать по ним.
EG>>> Все метки у нас работают через geom_label, а он умеет метки
EG>>> не только для GPT, но вообще для чего угодно -
EG>>> для UFS через /dev/ufs/label, для остального через
EG>>> /dev/label/swap.
VS>> Я уже писал, что метки, доступные через /dev/ufs/label и
VS>> /dev/label/swap, нужно хранить в последнем секторе раздела.
VS>> Соответственно если подсунуть этот диск системе без geom, для неё
VS>> это мусор, особенно если она ожидает увидеть на этом месте копию
VS>> GPT.

EG> В конце диска ожидают увидеть копию GPT только если в начале есть
EG> оригинал. А если там MBR, то не ожидают. А зачем тебе метки фрёвых
EG> разделов за пределами freebsd, какой use case?

Так ведь в GPT могут храниться метки не только фревых разделов, а любых. В случае multiboot, или если глядеть на разделы каким-нибудь gparted-ом, метки разделов очень даже познавательны.

EG>>> И это в GPT тоже плохо. В нём всё плохо - ни совместимости
EG>>> с graid/gmirror,

Работает в общем-то с gmirror, хоть и с руганью в начале загрузки на отсутствие второй GPT. Неаккуратненько, да.

EG>>> ни мультизагрузчиков, единственный бут-раздел.

Да, единственный бут-раздел это минус, особенно если привык, что на MBR их с лёгкостью 4 шт и boot0 совершенно беспроблемен.

VS>> Мультизагрузчиков таки нет?

EG> Я не искал, но по твоим словам - нет :-)

Похоже что есть только grub2.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в May 18 23:06:15 по местному времени:

06 мая 2018, воскресенье, в 08:19 NOVT, Victor Sudakov написал(а):

EG>> Зачем тебе неограниченное количество разделов на носимом диске-то?
EG>> Одного FAT32/NTS в MBR недостаточно для обмена данными?
VS> На носимом диске уже давно недостаточно FAT32 из-за ограничения размера файла в
VS> 4 Гб. А NTFS FreeBSD не умеет нормально на запись. Выручил бы exfat, но его нет
VS> не только в базовой системе, но даже в бинарных пакетах из-за каких-то
VS> лицензионных ограничений. И они оба (rw NTFS и exfat) только через fuse.

Твои данные на эту тему сильно устарели. Во-первых, ту реализацию NTFS,
которая не умеля rw, из FreeBSD давно выкинули уже. Вместо неё
fuse нынче в базовой системе с десятки и на моём домашнем dualboot-десктопе
прекрасно монтируется NTFS с соседнего раздела с Win8.1.

Правда, для этого саму Win8.1 пришлось настроить размонтировать
раздел при shutdown (ценой слегка более медленного выключения/включения),
а то по дефолту оно нынче только симулирует shutdown, а реально выполняет
что-то вроде suspend-to-disk и не размонтирует fs.

VS> Но речь ведь не обязательно про носимый диск. Вот к примеру первые два
VS> пришедших в голову сценария.

VS> 1. Делается ТО компа с FreeBSD, железячник загружает его с хитрого ремонтного
VS> flash/DVD для проверки железа. Лучше если его инструменты будут видеть на диске
VS> нечто знакомое им, а то ещё попытаются чинить. Собственно Protective MBR на
VS> такой случай и придуман.

Я бы не пустил к железке железячника, который использует для TO железа
инструменты, "пытающиеся чинить" информацию на диске - в самом крайнем
случае, предварительно убрав собственно диски. Нафик-нафик.

VS> 2. Комп с FreeBSD умер, снимаем диск и несем куда-то считывать с него данные,
VS> или загружать на другой системе. Далее см. п. 1.

А вот это я делал, в том числе удалённо за тысячи км.
И разумеется, спасение данных (включая chflags и остальное)
выполнялось подключением к другой системе, загруженной с FreeBSD
со специально изготовленного .img, который подымал сеть
и позволял зайти туда по ssh. Это был как раз тот случай с SCSI-дисками,
про который на днях упомянал, там вообще ничего по дефолту
не было "видно" из-за смещения SCSI-контроллером MBR относительно
начала дисков.

Я не понимаю, чем в описанных ситуациях поможет множество разделов
или метки разделов.

EG>>>> И это в GPT тоже плохо. В нём всё плохо - ни совместимости
EG>>>> с graid/gmirror,
VS> Работает в общем-то с gmirror, хоть и с руганью в начале загрузки на отсутствие
VS> второй GPT. Неаккуратненько, да.

Тут проблема вовсе не в "неаккуратненько", а в том, что софт надеется
на доступность резервной копии GPT и ведет себя соответственно,
а в момент X внезапно окажется, что нет ни оригинала,
ни копии и совершенно штатная процедура загрузки с использованием бекапа
ВНЕЗАПНО переходит в разряд аварийной починки вручную.

EG>>>> ни мультизагрузчиков, единственный бут-раздел.
VS> Да, единственный бут-раздел это минус, особенно если привык, что на MBR их с
VS> лёгкостью 4 шт и boot0 совершенно беспроблемен.

Кстати сказать, дополнительная ненужная single point of failure.

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

И пару раз за почти 20 лет такие случаи были :-)

Eugene
--
Однажды, будучи ещё мальчишкой, я был на каникулах и прогуливался вдоль реки.
Я увидел выдру с выводком. Весьма умилительное зрелище, думаю, вы согласитесь
со мной. Выдра нырнула и поймала жирного лосося, которого она с трудом
выволокла на ствол полузатопленного дерева и принялась пожирать, разумеется,
заживо. Из распоротого брюха лосося вывалилась икра, о, я до сих пор помню
чудесный розовый цвет этих икринок, к которым тут же бросились маленькие выдры,
ссорясь между собой за лакомство. Чудо природы: мать и дети, пожирающие
мать и детей. Вот тогда я и познал впервые, что есть зло. Оно встроено в саму
природу вселенной.
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в May 18 18:48:57 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> fuse нынче в базовой системе с десятки и на моём домашнем dualboot-десктопе
EG> прекрасно монтируется NTFS с соседнего раздела с Win8.1.
основная беда с fuse под фрей (и отчасти макосью) в том, что ее писали под
линукс. У которого есть buffer cache, поэтому авторы фузевых файловых систем
вообще не заморачивались тем, как и что они пишут/читают.
В результате по чтению ntfs3g отстает от native всего лишь в пару раз,
а не на пару порядков. И не рискует прогрызть в флэшке дыру. С записью похуже,
но, при избытке процессорной мощности, жить можно.

У фри эту проблему пытались решить дополнительной прослойкой, порт заброшен
лет семь назад, степерь ее эффективности представляется мне очень сомнительной.

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в May 18 06:01:40 по местному времени:

06 мая 2018, воскресенье, в 16:48 NOVT, Alex Korchmar написал(а):

AK> У фри эту проблему пытались решить дополнительной прослойкой, порт заброшен
AK> лет семь назад, степерь ее эффективности представляется мне очень сомнительной.

Твои данные тоже очень устарели.

Я вообще удивляюсь, как тебя хлебом не корми, но дай поспорить
о вкусе устриц с теми, кто их ест.

Eugene
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Eugene Grosbein в May 18 12:05:38 по местному времени:

Dear Eugene,

06 May 18 23:06, you wrote to me:

EG>>> Зачем тебе неограниченное количество разделов на носимом
EG>>> диске-то? Одного FAT32/NTS в MBR недостаточно для обмена
EG>>> данными?
VS>> На носимом диске уже давно недостаточно FAT32 из-за ограничения
VS>> размера файла в 4 Гб. А NTFS FreeBSD не умеет нормально на
VS>> запись. Выручил бы exfat, но его нет не только в базовой системе,
VS>> но даже в бинарных пакетах из-за каких-то лицензионных
VS>> ограничений. И они оба (rw NTFS и exfat) только через fuse.

EG> Твои данные на эту тему сильно устарели. Во-первых, ту реализацию
EG> NTFS, которая не умеля rw, из FreeBSD давно выкинули уже. Вместо
EG> неё fuse нынче в базовой системе с десятки и на моём домашнем
EG> dualboot-десктопе прекрасно монтируется NTFS с соседнего раздела с
EG> Win8.1.

Через sysutils/fusefs-ntfs же?

EG> Правда, для этого саму Win8.1 пришлось настроить размонтировать
EG> раздел при shutdown (ценой слегка более медленного
EG> выключения/включения), а то по дефолту оно нынче только симулирует
EG> shutdown, а реально выполняет что-то вроде suspend-to-disk и не
EG> размонтирует fs.

У меня с Windows 7 проблема с записью есть: через NTFS-3G пишешь-пишешь на NTFS диски, а загрузившись в Windows, записанного не находишь. Писал в никуда. Потому и написал выше "А NTFS FreeBSD не умеет нормально на запись."

Возможно это что-то на Windows надо отключать, какой-нибудь журнал? Но сходу не нашёл.

VS>> Но речь ведь не обязательно про носимый диск. Вот к примеру
VS>> первые два пришедших в голову сценария.

VS>> 1. Делается ТО компа с FreeBSD, железячник загружает его с
VS>> хитрого ремонтного flash/DVD для проверки железа. Лучше если его
VS>> инструменты будут видеть на диске нечто знакомое им, а то ещё
VS>> попытаются чинить. Собственно Protective MBR на такой случай и
VS>> придуман.

EG> Я бы не пустил к железке железячника, который использует для TO железа
EG> инструменты, "пытающиеся чинить" информацию на диске - в самом крайнем
EG> случае, предварительно убрав собственно диски. Нафик-нафик.

Случаи всякие бывают. Protective MBR (и вообще наличие стандартной, всеми признаваемой partitioning scheme) - доп. подстраховка.

[dd]

EG>>>>> И это в GPT тоже плохо. В нём всё плохо - ни совместимости
EG>>>>> с graid/gmirror,
VS>> Работает в общем-то с gmirror, хоть и с руганью в начале загрузки
VS>> на отсутствие второй GPT. Неаккуратненько, да.

EG> Тут проблема вовсе не в "неаккуратненько", а в том, что софт надеется
EG> на доступность резервной копии GPT и ведет себя соответственно,
EG> а в момент X внезапно окажется, что нет ни оригинала,
EG> ни копии и совершенно штатная процедура загрузки с использованием
EG> бекапа ВНЕЗАПНО переходит в разряд аварийной починки вручную.

Это какой например софт так надеется?

EG>>>>> ни мультизагрузчиков, единственный бут-раздел.
VS>> Да, единственный бут-раздел это минус, особенно если привык, что
VS>> на MBR их с лёгкостью 4 шт и boot0 совершенно беспроблемен.

EG> Кстати сказать, дополнительная ненужная single point of failure.

EG> Одна из причин, по которым я на домашнем десктопе держу несколько
EG> операционок с MBR, это то, что при софтовом повреждении одной из них
EG> до состояния незагружаемости у меня всегда есть возможность
EG> загрузиться во вторую, где заранее настроенное комфортное окружение
EG> с доступом в сеть (к вебу, к своей почте) и даже если форс-мажор
EG> и некогда заниматься починкой - десктоп всё равно жив и доступен.

Это проще на флешку поставить полноценную систему. У меня есть такая (правда без иксов).

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Victor Sudakov написал(а) к Eugene Grosbein в May 18 12:30:46 по местному времени:

Dear Eugene,

06 May 18 23:06, you wrote to me:

EG>>> Зачем тебе неограниченное количество разделов на носимом
EG>>> диске-то? Одного FAT32/NTS в MBR недостаточно для обмена
EG>>> данными?
VS>> На носимом диске уже давно недостаточно FAT32 из-за ограничения
VS>> размера файла в 4 Гб. А NTFS FreeBSD не умеет нормально на
VS>> запись. Выручил бы exfat, но его нет не только в базовой системе,
VS>> но даже в бинарных пакетах из-за каких-то лицензионных
VS>> ограничений. И они оба (rw NTFS и exfat) только через fuse.

EG> Твои данные на эту тему сильно устарели. Во-первых, ту реализацию
EG> NTFS, которая не умеля rw, из FreeBSD давно выкинули уже. Вместо
EG> неё fuse нынче в базовой системе с десятки и на моём домашнем
EG> dualboot-десктопе прекрасно монтируется NTFS с соседнего раздела с
EG> Win8.1.

Через sysutils/fusefs-ntfs же?

EG> Правда, для этого саму Win8.1 пришлось настроить размонтировать
EG> раздел при shutdown (ценой слегка более медленного
EG> выключения/включения), а то по дефолту оно нынче только симулирует
EG> shutdown, а реально выполняет что-то вроде suspend-to-disk и не
EG> размонтирует fs.

У меня с Windows 7 проблемы с записью были: через NTFS-3G пишешь-пишешь на NTFS диски, а загрузившись в Windows, записанного не находишь. Писал в никуда. Потому и написал выше "А NTFS FreeBSD не умеет нормально на запись."

Виноват тут скорее всего виндовый fast restarting, но я не знаю, как его отключить отдельно от hibernation.

VS>> Но речь ведь не обязательно про носимый диск. Вот к примеру
VS>> первые два пришедших в голову сценария.

VS>> 1. Делается ТО компа с FreeBSD, железячник загружает его с
VS>> хитрого ремонтного flash/DVD для проверки железа. Лучше если его
VS>> инструменты будут видеть на диске нечто знакомое им, а то ещё
VS>> попытаются чинить. Собственно Protective MBR на такой случай и
VS>> придуман.

EG> Я бы не пустил к железке железячника, который использует для TO железа
EG> инструменты, "пытающиеся чинить" информацию на диске - в самом крайнем
EG> случае, предварительно убрав собственно диски. Нафик-нафик.

Случаи всякие бывают. Protective MBR (и вообще наличие стандартной, всеми признаваемой partitioning scheme) - доп. подстраховка.

[dd]

EG>>>>> И это в GPT тоже плохо. В нём всё плохо - ни совместимости
EG>>>>> с graid/gmirror,
VS>> Работает в общем-то с gmirror, хоть и с руганью в начале загрузки
VS>> на отсутствие второй GPT. Неаккуратненько, да.

EG> Тут проблема вовсе не в "неаккуратненько", а в том, что софт надеется
EG> на доступность резервной копии GPT и ведет себя соответственно,
EG> а в момент X внезапно окажется, что нет ни оригинала,
EG> ни копии и совершенно штатная процедура загрузки с использованием
EG> бекапа ВНЕЗАПНО переходит в разряд аварийной починки вручную.

Это какой например софт так надеется?

EG>>>>> ни мультизагрузчиков, единственный бут-раздел.
VS>> Да, единственный бут-раздел это минус, особенно если привык, что
VS>> на MBR их с лёгкостью 4 шт и boot0 совершенно беспроблемен.

EG> Кстати сказать, дополнительная ненужная single point of failure.

EG> Одна из причин, по которым я на домашнем десктопе держу несколько
EG> операционок с MBR, это то, что при софтовом повреждении одной из них
EG> до состояния незагружаемости у меня всегда есть возможность
EG> загрузиться во вторую, где заранее настроенное комфортное окружение
EG> с доступом в сеть (к вебу, к своей почте) и даже если форс-мажор
EG> и некогда заниматься починкой - десктоп всё равно жив и доступен.

Это проще на флешку поставить полноценную систему. У меня есть такая (правда без иксов).

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Alex Korchmar написал(а) к Eugene Grosbein в May 18 09:53:20 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> У фри эту проблему пытались решить дополнительной прослойкой, порт
AK>> заброшен
AK>> лет семь назад, степерь ее эффективности представляется мне очень
AK>> сомнительной.
EG> Твои данные тоже очень устарели.
OPTIONS_DEFAULT=LOCK UBLIO
LOCK_DESC= Lock the device when mounting (avoids access)
LOCKCFLAGS= -DUSELOCK
UBLIO_DESC= Enable user space cache for improved speed
UBLIOEXTRAPATCНES= ${FILESDIR}/extra-patch-ublio
UBLIOLIBDEPENDS= libublio.so:devel/libublio

EG> Я вообще удивляюсь, как тебя хлебом не корми, но дай поспорить
EG> о вкусе устриц с теми, кто их ест.
с теми кто слаще морковки не едал, и тесты тоже не делал?


> Alex

--- ifmail v.2.15dev5.4