Полагаю, на оба вопроса ответ отрицательный. Как я понимаю, место под загрузочный сектор резервируется при создании таблицы разделов. Поэтому, если даже лило туда встанет, то могут побиться данные.

Ещё вопрос — умеет ли debootstrap использовать локальные зеркала?

В мане написано:
debootstrap sarge ./sarge-chroot file:///PATH_TO_LOCAL_MIRROR/debian

Yeah...

Установить систему через debootstrap получилось с привлечением диска netinstall.

После некоторых манипуляций установил туда lvm2 и lilo. Оба пакета удалось сконфигурировать. LILO уже стартует, но ядро пока не заводится из-за кривого initrd (VFS not syncing)... Или ещё чего-то — у меня нет опыта ручного конфигурирования ядра/загрузчика на LVM. Буду разбираться.

P.S.: анонимус, всё правильно сказал, мне такие игры по душе ;-)

В мане написано

У меня упрощённое зеркало. Там даже Release нету, только Packages.gz =)

Поэтому, если даже лило туда встанет, то могут побиться данные.

Целостность LVM, похоже, не нарушена — lv-root подцепился, [vg|lv]display дают нормальный выхлоп.

Это говорит только о том, что метаданные LVM не побились. Советую сделать fsck всем файловым системам на этой vg.
А вообще чудес быть не должно, и либо лило уже записался поверх данных, либо данные когда-нибдь запишутся поверх лило. Всему свое время.

Странно, ядро по-прежнему не грузится =( initrd пересобирал.

Традиционный совет: влепи в initrd шелл и busybox и посмотри, что там происходит.

Ошибок не найдено (fsck и vgck) А разве MBR могла быть затронута какими-то метаданными? LILO ведь именно в ней.

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

man pvcreate

... For whole disk devices only the partition table must be erased, which will effectively destroy all data on that disk. This can be done by zeroing the first sector...

man pvcreate

-Z, --zero y/n

Whether or not the first 4 sectors (2048 bytes) of the device should be wiped. If this option is not given, the default is to wipe these sectors unless either or both of the --restorefile or --uuid options were specified.

Я так понял, без --uuid и/или --restorefile оно потрёт четыре сектора нулями, и оставит их в покое.

влепи в initrd шелл и busybox и посмотри, что там происходит.

Они там, вроде, по умолчанию. Но перед паникой ещё выскакивает что-то типа «couldn't find valid ramdisk at offset=0» (не дословно, как помню).

В гугле таких ошибок тонны, по самым разным причинам. Ну его нафиг, наверно...

Дык правильно, первым делом вычистить остатки MBR, чтобы избежать недопонимания с загрузчиками и проч.

После этого, наверное, эти области используются как обычное пространство.

После этого, наверное, эти области используются как обычное пространство.

Неа. Вопреки ману, там LVM-лэйбл. Выяснено dd.

> Хочу установить Debian на LVM, который будет развёрнут на целом диске без таблицы разделов (pvcreate /dev/sda). По каким-то причинам установщик не хочет ставиться на такой диск, требуя создать таблицу разделов.

ну а где ты предлагаешь жить загрузчику? И как BIOS его найдёт, будет парсить твою LVM чтоли? Как минимум нужен MBR или его имитация (как в GPT) потому что по стандарту загрузки BIOS считывает первый сектор загрузочного диска и передаёт ему управление. Идём далее: в 512 байт первого сектора можно впихнуть только простейший MBR-загрузчик, ничего вменяемого типа GRUB(2)/LILO/SYSLINUX туда не поместится, значит нужно выделить место для stage2 загрузчика ... — в общем не выпендривайся. Помимо LVM по любому нужен MBR и зарезервированное место для stage2 (для GPT+GRUB2 это отдельный неотформатированный раздел, для MBR+GRUB(2)/LILO это «ничейное место» до начала первого раздела, для SYSLINUX/EXTLINUX место для stage2 резервируется в специальных неперемещаемых секторах на загрузочном FAT*/ext* разделе).

> Ещё вопрос — умеет ли debootstrap использовать локальные зеркала?

так поковыряйся в коде — это же простой sh-скрипт. И руками поставь зеркало которое тебе нужно. Скачивает он wget-ом, так что на зеркале надо будет поднять простой статичный http-сервер, например mini-httpd

ранее вполне работало:
#mount -t iso9660 -o loop /home/dvd1/*.iso file:/mnt
#debootstrap --arch i386 etch /var/etch32 file:///mnt

Идём далее: в 512 байт первого сектора можно впихнуть только простейший MBR-загрузчик, ничего вменяемого типа GRUB(2)/LILO/SYSLINUX туда не поместится, значит нужно выделить место для stage2 загрузчика ...

У LILO нет stage2. Он весь размещается в MBR или бут-секторе тома. Отсюда ограничение на 16 пунктов загрузочного меню, а также использование BIOS для доступа к физически адресованному kernel/initrd. Пруф смотри на википедии. Поэтому же у него только два принципиальных ограничения: 1) нельзя загрузить ядро, физически размещённое более, чем на одном устройстве; 2) нельзя загрузить ядро, которое находится на шифрованном томе.

Или же я жду пруф, что есть некий загадочный stage2, которого никто не видел.

Скачивает он wget-ом, так что на зеркале надо будет поднять простой статичный http-сервер, например mini-httpd

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

> Или же я жду пруф, что есть некий загадочный stage2, которого никто не видел или рассержусь

http://people.manchester.ac.uk/~zlsiial/grub/img17.htm

также имей ввиду что «stage2» — это в GRUB она так называется. В SYSLINUX она например называется LDLINUX.SYS, а в LILO похоже вообще не имеет официального имени. Но сути это не меняет — весь код загрузчика не помещается в MBR, и перед тем как LILO станет способен загрузить ядро он должен догрузить дополнительные части себя любимого.

Ok. Попробую выяснить подробности потом.

//На правах рекламы: возобновлена разработка LILO. Вышла версия 23.0, в этом же году ожидается 23.1.

Да, это объясняет, почему бэкап LILO в виде первого сектора диска оказался бесполезен когда-то...

Попробую выяснить подробности потом.

Оказалось, надо было внимательно читать статью на той же википедии — там всё разжёвано.

Я lvm настроил самим инсталлером убунты и счастлив.

Автор, у тебя не Ъ дистр. Sex-linux давно не обновлялся, так что советую LFS. Удачного геморроя!

Зря я запостил ссылку в толксах... Ты даже не понял суть задачи, очевидно. Настроить LVM из debian-installer я могу. В данном же конкретном случае, у задачи нет решения. Оно было бы, будь у команды pvcreate опция типа offset, чтобы PV мог начинаться с отступом от начала блочного устройства — тогда осталось бы место для загрузчика.

Найдено некое подобие решения — loop partition table, коя как бы не совсем является таблицей разделов. Других решений при нынешней логике работы с PV, похоже, нет.