Linux boot from lvm

/boot в lvm при использовании grub2 efi

господа, доброго времени суток!

Использую grub2, гружусь через efi, / в lvm, /boot/efi — отдельный раздел fat32 для efi. Нужно ли в таком случае выносить /boot из lvm или можно оставить внутри /?

а зачем grub в таком случае? не проще грузить сразу из efi?

не работал с LVM на EFI, но логика подсказывает что отдельный /boot нужен

не сообразил сразу, что efi может через initrd грузиться, в принципе да, буду сейчас пробовать напрямую

з.ы. такая же схема у меня: uefi, gpt, lvm, без левых загрузчиков

Достаточно раздела /boot/efi
целиком /boot выносить не обязательно

Можно и напрямую, и граб оставить на всякий случай, оба пункта будут доступны в меню загрузки efi

премного благодарен, попробуй так.

в общем, собрал ядро для efi, закинул все в папку EFI/boot/ в efi разделе, вручную грузится нормально через команду в efi shell

Источник

Booting Linux from LVM Volumes

About

In this tutorial, we will explain the Linux boot process in general, and how it works when Linux is installed on an LVM volume. It’s recommended to read the previous chapter about LVM if you are not already familiar with LVM. This section will also give you a good understanding of the Linux boot process in general even if you don’t use LVM, so it’s worth reading. It is recommended that you read the previous pages about LVM before reading this one.

Booting from an LVM Root filesystem

Many linux distributions such as Redhat/Fedora allow you to install the root filesystem on an LVM Logical Volume. This way you get the flexibility of LVM for this filesystem and not just for the data. The down side is that the boot procedure is a bit more complex, and you need to understand how its boots so that you are able to fix it in case of problems.

Booting using a root filesystem located on an LVM Logical Volume is more complicated because the kernel does not know anything about LVM. So it needs the LVM binary to mount the root filesystem. But the LVM binary is installed on the root filesystem that we want to mount… The solution to this egg and chicken problem is to boot with an initramfs. This is a compressed archive that contains all the kernel modules and programs that are required to mount the root filesystem at boot time. In general, it’s located in /boot , and it is called initramfs-x.y.z.gz . The other important file is the linux kernel image which is called vmlinuz-x.y.z .

Here are the important steps involved in booting from LVM:

• The BIOS executes the boot loader which is very often Grub
• The boot loader has its own code for reading partitions and filesystems. So it knows how to read files from the /boot partition which contains the linux kernel image (vmlinuz-x.y.z) and the initramfs (initrd-x.y.z.gz). It first loads these two files into memory. Then it executes the kernel image and it tells the kernel where the initramfs is located in memory. The boot command line is also passed to the kernel. This command line contains the important parameters for the kernel such as root=/dev/volgroup/lvroot .
• The linux kernel starts and executes its initialization code. Then it reads the initramfs from the memory. The contents is uncompressed into a new location in the memory.
• The contents of the initramfs is now available. The program/script called init is now executed. This script which is specific to each linux distribution is responsible for finding the root filesystem.
• If the LVM Physical Volumes are stored on the top of a RAID disk, the init program will first execute dmraid/mdadm to make this raid disk available.
• Then the init script will run programs such as pvscan/vgscan/lvscan to detect the LVM volumes located on the disks
• The LVM volumes are not usable yet. They have to be activated first. This is done by vgchange —available y or vgchange -ay .
• The init script reads the virtual file called /proc/cmdline to see what is the name of the root filesystem specified on the boot command line.
• The root filesystem is mounted in a temporary directory such as /rootfs and other things such as /rootfs/proc and /rootfs/dev may also be mounted.
• The initscript executes a chroot to /rootfs . This means that this directory becomes the new root for the processes which will be executed. When a process reads /bin/something it will read /rootfs/bin/something in reality.
• The secondary init program, the one which is stored on the root filesystem is now executed and it finishes the initialization with an access to the real root filesystem.

Distributions and rootfs on LVM

• All mainstream Linux distributions now support LVM2. But the installation program may not allow you to install the Linux rootfs onto an LVM Logical Volume.
  • Redhat + Fedora + CentOS, anaconda (the installation program) install the root filesystem on LVM by default, but you can change it.
  • Gentoo: since the default installation method is to install it by hand, you can directly install Gentoo on LVM if you know what you are doing
  • Ubuntu: as of version 09.04, the installation program does not support LVM, but you can probably migrate the root filesystem after installation.

There are good reasons for using LVM for the root filesystem:

• The root filesystem will be more flexible: it will be easier to resize it if it is on an LVM Logical Volume
• You can make snapshots of the root filesystem which is very useful if you want to make consistent backups of it

You may not want your root filesystem to be on an LVM Logical Volume if you don’t want to boot with a ramdisk. If you compile your own kernel with all the important disk and filesystem drivers built in the linux image, it will be possible to boot with no initramfs as long as linux is installed on a standard disk partition that the kernel will be able to mount.

Extracting an initramfs

An initramfs contains the files necessary to obtain access to the root filesystem at boot time. It is possible to read its contents if you want to have a look at its contents. There are two sorts of such files: the old ones are called initramdisk and the new ones are called initramfs.

about initramfs

Most linux distributions provide initramfs along with kernel images. They are compressed cpio archives. Here is how to extract it

Create a temporary directory

Extract the compressed initramfs

Here is how to recreate an initramfs

The following command will create a new initramfs using files located in /var/tmp/ramdiskfiles-new :

Источник

LVM + lilo > GPT + EFI (или почему GRUB такой неуклюжий)

TL;DR: автор сокрушается о том, что GRUB не может жить полноценно с LVM и с удивлением открывает, что это отлично умеет заброшенный в 2015 году загрузчик lilo.

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

Я еще раз повторю, не надо сейчас мне говорить «так сложилось», а включите логику. MBR ужасна.

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

Еще одна проблема MBR заключается в том, что разделы нельзя просто так увеличивать (ну, кроме последнего). Хотите изменить размер раздела? Ну, это просто — нужно удалить его и заново создать, передвинув его конец. Глубокоуважаемый товарищ amarao запилил прекрасную утилиту ptmax, которая позволяет хоть как-то снять эту боль, но послушайте, еще раз, ведь есть же другой путь!

Отдельным пунктом идет прекрасное поведение загрузчика GRUB с MBR. Ну, поскольку загрузчику мало 446 байт для полноценной жизни, он помещает свой core.img в «зазор» между окончание MBR и началом первого раздела (который предлагается начинать с 1 мегабайта, хотя раньше было ближе).

Эээээ, нет. GPT лечит проблему того, что в MBR в одном флаконе собран уж и еж. GPT как бы говорит нам, что теперь нет никаких скрытых областей, куда GRUB будет что-то писать, вот для него отдельный раздел. Отлично. Но куда деваться от того, что разделы все равно нельзя увеличить?

Ну, например, поставил я систему. Выделил под rootfs 32 Гб, а завтра понял, что мне надо 64. И как жить? Что делать? Если я создал после rootfs раздел под swap, то расширение раздела под rootfs выглядит вот так:

1. Выключить swap
2. Снести раздел под swap
3. Изменить размер раздела под rootfs
4. Расширить файловую систему rootfs
5. Создать раздел под swap
6. Включить swap

Все бы хорошо, но если у меня за rootfs создан раздел с данными и передвинуть его я не могу? Ну, тогда нужно страдать.

О да, вот это уже круто! Ведь тут вопрос разделов вынесен за скобки вообще. Я могу создать сколько угодно разделов и не задумываться о том, как их потом увеличивать. Круто? Да.

Но к сожалению, логика того, что LVM заменяет собой MBR и GPT приходит не ко всем. До сих пор целый ряд подходов системных администраторов косно крутится вокруг логики «давайте создадим раздел на весь диск, а раздел добавим в LVM».

Ну и крутотенюшка заканчивается, когда Вы хотите отказаться от MBR или GPT полностью, а остаться только с LVM.

Попытка с инсталлятором Ubuntu

Note: здесь и далее я буду говорить про Ubuntu, если уважаемое сообщество подскажет, как обстоят дела с этим вопросом в других дистрибутивах, буду рад.

«В чем проблема? Я ж видел даже в инсталляторе Ubuntu строчку про LVM!» — скажет любой, кто устанавливал хоть раз, например, Ubuntu и будет прав.

Да, ну давайте посмотрим, какой ад вариант нам предложит инсталлятор.

Здесь прекрасно все. От мелочей до важного.

Для начала, оцените иронию — под LVM отдан раздел, а не диск. Почему? Я оставлю это на совести тех, кто это придумал. Особый цинизм в том, что раздел расширенный, т.е. на диске будет болтаться два блока с MBR. Окей.

Потом мы оценим обычный раздел /boot. Да, Вы хотите LVM, но у Вас будет и MBR тоже. Почему так? Ну раньше это можно было оправдать тем, что grub не умел эти Ваши LVM, но он давно уже умеет.

Ну и плавно к важному. Никого не смущает, что по сути LVM натягивается, как сова на глобус поверх MBR? Это как понимать? Зачем это вообще?

Да закопайте уже стюардессу

Отказаться от MBR просто — мы же можем отдать целый диск в подчинение LVM? Можем и нужем. Как это сделать из инсталлятора? Увы, никак. Руками. То есть, перед шагом Partition disks нужно переключиться в соседний tty и руками сделать следующее (подразумевается, что диск, куда мы хотим установить систему, зовут /dev/sda):

Тут я отдаю 6 гигабайт на rootfs, оставшееся на swap, изменить по желанию.

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

Хьюстон, у нас проблемы

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

Напомню, что LVM обычно отступает 1Mb от начала физического носителя. Откуда я знаю? Ну команда

покажет это. Что для нас это означает? Первый мегабайт диска свободен, никто не мешает GRUB записать туда свои 446 байт загрузчика, плюс core.img. Вот только без MBR он не сможет это сделать!

Еще раз, я поражаюсь нежности GRUB: тебе дают диск, давай уже, сделай так, чтобы ты оттуда мог грузиться. Ты умеешь LVM, в чем проблема?

Даже попытки вызвать grub-install вручную с параметром -s привели только к тому, что «unable to identify a filesystem in hostdisk//dev/sda: safety check can’t be performed».

Воскуривание сырцов открывает жестокую правду: GRUB просто не умеет выполнить инсталляцию самого себя, если нет живого MBR с хотя бы одним разделом.

Лирическое отступление: истинные бойцы с презрением скажут: «Зачем тебе вообще возиться с этим отсталым GRUB? Приходи же в нашу церковь EFI!».

Вообще я согласен, с EFI все гораздо проще, но есть проблема с кучей Legacy машин, которые EFI уметь не будут. То есть, заставить EFI грузиться как BIOS обычно можно, обратное, увы, не всегда выполнимо. А я хочу LVM и мороженку, тьфу, загрузку не только с EFI.

В целом, EFI задуман достаточно неплохо. Нет никаких скрытых тебе областей, создай раздел, положи туда загрузчик в виде .efi-файла, 7 строк конфигурации и загружайся.

Нет, подождите. Опять создай раздел? Может быть кто-нибудь догадается в спецификацию EFI добавить поддержку LVM? Пожалуйста?

В качестве выхода, конечно, можно взять небольшую флешку и отформатировать ее в желанный для EFI FAT целиком, без разделов. Уже хлеб, но все равно в системе придется держать два диска, один для EFI, другой целиком под LVM, где уже система.

Тут, думаю, раздастся громкий WAT. Да, увы, так оно и есть, это настоящий и серьезный WAT.

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

И что мы выясняем? Что lilo отлично умеет устанавливаться на диск с LVM; умеет /boot в LVM; не требует, чтобы на диске был создан хоть какой-то MBR и замечательно работает на той же Ubuntu 16.04, т.е. пакет есть и он адекватен.

Беда в другом. Разработка lilo прекратилась в конце 2015 года. Ну, с другой стороны, оно умеет все, что надо, чтобы загружать современную систему целиком на LVM.

Заключение

Еще раз, пожалуйста, поймите главный message этой статьи — откажитесь от обычной таблицы разделов. Будь то MBR, будь то GPT, оно Вам не нужно, если есть LVM. Никогда не отдавайте под LVM разделы (кроме тех случаев, когда нужен какой-нибудь извращенный dual-boot с Windows), в этом просто нет смысла.

И давайте вместе надеяться, что когда-нибудь у нас будет поддержка LVM в EFI. А пока будем страдать, тьфу, использовать lilo.

Источник