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

MBR?


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

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

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

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

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

GPT?


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

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

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

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

LVM


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

Но к сожалению, логика того, что 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):

pvcreate /dev/sda
vgcreate ubuntu /dev/sda
lvcreate -n root -L6G ubuntu
lvcreate -n swap -l100%FREE ubuntu

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

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

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


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

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

pvs -o +pe_start

покажет это. Что для нас это означает? Первый мегабайт диска свободен, никто не мешает 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 задуман достаточно неплохо. Нет никаких скрытых тебе областей, создай раздел, положи туда загрузчик в виде .efi-файла, 7 строк конфигурации и загружайся.

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

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

lilo?


Тут, думаю, раздастся громкий 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.

Комментарии (66)


  1. amarao
    15.11.2017 23:46

    LVM на диск без раздела может быть, и даже используется, но на практике отсутствие метки типа диска может приводить к случайным «потерям» данных из-за софта, который про LVM не знает, а про разделы знает.

    Кстати, жизнь в новых линуксах с разделами стала проще, потому что теперь partition table системного диска может обновляться без перезагрузки.

    Почему всё-таки GPT а не LVM? Потому что LVM слишком сложен. GPT прост, и это его большое преимущество, для стандарта, который должны понимать все ОС и понимать совершенно одинаково.


    1. prometheus_ru Автор
      15.11.2017 23:51

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

      Мечтаю, видимо.


      1. CodeRush
        16.11.2017 01:01

        Когда RedHat начнет выпускать прошивки или железо — вот тогда они смогут пропихнуть что-угодно в свои продукты, а пока их ОС ставится на сервера и рабочие станции Lenovo, Dell или HP, их безопасники за одну только идею добавить в прошивку еще один весьма нетривиальный парсер на С любому голову оторвут.


      1. amarao
        16.11.2017 13:39

        LVM сложен. Очень сложен. Mirror volumes, снапшоты.

        Вы действительно хотите поддержку снапшотов у mirror volumes в EFI? Зачем оно винде, например, которая LVM не использует, а поддерживать будет вынуждена?

        Стандарты должны быть разумными. Это включает в себя минимальное пересечение по требованиям для интероперабельности.

        LVM в этот стандарт никак не укладывается. С тем же успехом можно требовать поддержки btrfs в качестве EFI тома или linux raid 60 для загрузки.


    1. AntonAlekseevich
      16.11.2017 12:01

      GPT без MBR не работает, точнее не существует. (Может я просто не видел что GPT существовал целиком на диске с сектора 0, а не с сектора 1.)


      1. amarao
        16.11.2017 13:41

        MBR на GPR — легаси-затычка о которой можно не думать. Считайте, сигнатура такая длинная.


      1. pfg21
        16.11.2017 14:48

        GPT пишет в нулевой сектор диска псевдозапись MBR емнип с одним разделом на весь диск, с помощью которой «шифруется» от случайного удаления програмками, не умеющих GPT.
        это вписано в основы GPT и весьма правильно.


        1. AntonAlekseevich
          16.11.2017 15:34

          псевдозапись MBR

          Хмм… Псевдозапись значит.
          440 байт продолжают использоваться по назначению(Для BootCode), а разделы в MBR(4 в стандарте, но зависит от типа MBR(! Для дискстора вроде можно и 8 держать на диске)) можно писать как писали до GPT(4 GPT таблиц на диске держать можно, но толку 0.).


          От GPT диск не шифруется! И MBR не шифрует GPT. А просто указывает на наличие GPT разметки в разделе.


          От случайного удаления или перезаписи может спасти только Backup 0-33 сектора на внешний носитель.


          случайного удаления програмками

          Вижу это как главный козырь? (Даже GPT не защищает от DD и программ автоматической перезаписи данных.)


        1. prometheus_ru Автор
          16.11.2017 15:44

          То, о чем Вы говорите, называется Protective MBR. Однако, оно уже все реже используется. А есть еще Hybrid, когда MBR дублирует первые 4 раздела из GPT, это Apple любит.


          1. AntonAlekseevich
            16.11.2017 17:01

            У Apple своя же разметка вроде, разве нет? (Задумался.)
            Однако разделы в общем это нормальная практика.
            И в этом плане MBR проработан достаточно сильно.
            Ненужна куча разделов, просто нужны нужные разделы и их типы. (4(Boot, Swap, RootFS, Home) достаточно(Но как я упоминал ранее есть для большего количества Diskstore.))
            А вот то что нужна динамика в изменении разделов, ну я понимаю что это упрощение, но я бы сказал что это сильное излишество.


      1. f1inx
        17.11.2017 18:31

        В мире отличном от x86 достаточно частое явление отсутствие MBR при наличии GPT посмотрите на тот же Jetson K1/X1/X2. Если uboot или какой-либо другой первичный загрузчик ядра лежит в NOR/NAND/SPI/QSPI флешке то наличие lilo/grub противопоказано, а MBR, GPT и других disk label совершенно опционально.


        1. AntonAlekseevich
          17.11.2017 20:55

          Тогда и в отличном от ARM, PowerPC, SPARC и подобных им тоже.


  1. CodeRush
    16.11.2017 00:52

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

    Через мой труп, извините. Иметь драйверы любых файловых систем кроме совсем тривиальных в прошивке — верный способ быть взломанным через втыкание внешнего носителя с творчески испорченной ФС, разбор которой приведет к выполнению вредоносного кода в BDS, а дальше там обход SecureBoot, обход пароля от BIOS Setup, и прочее воровство и убийство.
    Вот вам один стандартный формат и драйвер к нему, оба простые как палка — пользуйтесь, городите поверх них любые LVMы, ZFSы, APFSы, что угодно, а прошивке оставьте ее GPT, который просто работает.


  1. DrPass
    16.11.2017 00:54
    +1

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

    Я, честно говоря, так и не понял. Разбиение диска на разделы — это же операция, которая в 99% случаев делается один раз в жизни диска. А в остальных 1% лучше её сделать на существующих костылях, чем искать универсальное решение в ущерб простоте.


    1. prometheus_ru Автор
      16.11.2017 10:46

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


      1. farcaller
        16.11.2017 12:18

        Ну так сделайте один раздел на весь диск и на нем хоть LVM, хоть Ceph Bluestore.


        LVM существенно сложнее GPT. В LVM нетривиально получить данные по логическому смещению.


        1. prometheus_ru Автор
          16.11.2017 15:45

          Смотрите, при виртуализации часто бывает ситуация, когда Вы меняете (т.е. увеличиваете) размер диска виртуальной машины. И что тогда делать?


          1. farcaller
            16.11.2017 17:44

            Хранить виртуалки на LVM или Ceph? Всегда так делаю :-)


          1. farcaller
            16.11.2017 18:13

            А, я понял — вы про изменение размера диска внутри виртуалки.


            Очень редко с таким сталкиваюсь, всегда проще нарезать новую, а данные на загрузочном диске и не хранятся. Я даже не уверен что облака AWS / GCP поддерживают такое.


            Как это решается? примитивным скриптом. Отресайзить единственный раздел и отресайзить фс. Если на лету страшно — то ребутнуть машину, coloudinit отресайзит на загрузке.


      1. quartz64
        16.11.2017 13:31

        Зачем мне надо будет менять размер разделов, точнее одного раздела с LVM внутри — мне нужно поменять размеры нужных мне LV? Бэкапить и снапшотить я тоже буду LV.


        1. amarao
          16.11.2017 13:40

          Вы — нет, а я, как IT-тролль, первое что сделаю, это засуну LV в качестве одного из PV вовнутрь PG. И бедный EFI должен будет deal with this.


      1. DrPass
        16.11.2017 17:05
        +1

        Ну а как часто вы это делаете в обычной жизни? Мне за четверть века жизни в обнимку с компьютером это приходилось делать всего лишь несколько раз. В каждом случае я брал актуальную на то время утилитку разметки дисков и переразбивал их. Т.е. поддержка этой функции операционной системой «из коробки» практически не востребована (кроме каких-то частных и редких кейсов). По крайней мере, калории, потраченные на её установку и настройку, не окупаются.


  1. firegurafiku
    16.11.2017 01:10

    Согласен с первым комментатором, что отдавать весь диск под LVM может быть опасно. Если есть хотя бы небольшой шанс случайного подключения этого диска к Windows-компьютеру неквалифицированным пользователем — лучше не надо, от данных могут остаться только оправдания «Да он же пустой был!». (Думаю, это одна из причин, почему GPT-разметка диска имитирует наличие MBR.)


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

    Ну так загрузите Grub по сети. В этой ситуации отдельный загрузчик на диске просто не нужен — можно хоть LVM, хоть LVM поверх LUKS, хоть Btrfs.


    1. prometheus_ru Автор
      16.11.2017 10:47

      GPT не просто имитирует MBR, она как бы может его использовать в гибридном режиме, что любит Apple. Не вижу проблемы создать Protective MBR для LVM.


  1. LexS007
    16.11.2017 01:20

    Статья из разряда: придумать себе проблему и пытаться решить ее.

    Зачем на компе с UEFI ставить GRUB или LILO? Это лишний загрузчик в цепи.
    UEFI Boot manager прекрасно запускает EFISTUB linux kernel.


    1. firegurafiku
      16.11.2017 02:17

      UEFI Boot manager прекрасно запускает EFISTUB linux kernel.

      Прекрасно запускает с LVM-тома?


      Статья из разряда: придумать себе проблему и пытаться решить ее.

      Нет, статья из разрядов «железка будет делать так, как я хочу, а не так, как ей удобно» и «кажется, теперь действительно пора лечиться от перфекционизма». С точки зрения автора, MBR (или GPT) — лишняя абстракция, не нужная для его целей, поэтому он её исключил. Благо ядро Linux не имеет ничего против.


      1. LexS007
        16.11.2017 14:18

        Прекрасно запускает с LVM-тома?

        Со стандартного ESP раздела.
        С точки зрения автора, MBR (или GPT) — лишняя абстракция, не нужная для его целей, поэтому он её исключил. Благо ядро Linux не имеет ничего против.

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

        А, в таком случае нужно вооружатся EDK и писать свой EFI драйвер для LVM.


    1. Sly_tom_cat
      16.11.2017 23:45

      Поддерживаю. Именно так у меня почти все мои компы и грузятся — вот утилитку наваял под это дело: github.com/slytomcat/UEFI-Boot


  1. vanxant
    16.11.2017 09:20

    Очень много раз меня спасала привычка делать в начале диска крохотный FAT раздел, с DOS и lilo.exe под DOS. Да, знаю толк, но возможность поднять сервак с уьитым загрузчиком по kvm — бесценна


    1. kalininmr
      16.11.2017 18:45

      я прям образ исошки обычно пишу. однажды помогло.


  1. conflict
    16.11.2017 10:42

    как по мне, так проще немного lvm допилить. пусть при использовании всего диска сделает что-то похожее на раздел, что будет символизировать наличие lvm на диске


  1. baxxter
    16.11.2017 10:43

    А не проще добавить небольшой диск под boot изначально, раз речь об виртуальных серверах и теоретически возникнет проблема с последующим расширением раздела(хотя опять же в таком случае проще добавить диск в vg расширении имхо)?
    А root уже можно монтировать в lvm:
    <img src=«А не проще добавить небольшой диск под boot изначально, раз речь об виртуальных серверах и теоретически возникнет проблема с последующим расширением раздела(хотя опять же в таком случае проще добавить диск в vg расширении имхо)? А root уже можно монтировать в lvm:


  1. rovenos
    16.11.2017 10:43

    была проблема LVM c systemd, которую регшал переустановкой. с тех пор LVM как то не очень


    1. prometheus_ru Автор
      16.11.2017 10:48

      А дайте ссыль, что за баг был?


  1. AndreyMtv
    16.11.2017 10:43

    Зачем вообще разделы нужны? Раньше файловые системы не могли адресовать весь обьем диска, теперь вроде бы таких проблем нет.
    Имхо это просто следование глупым традициям, никаких реальных проблем наличие разделов не решает.


    1. prometheus_ru Автор
      16.11.2017 10:49

      Разделы нужны для 4 следующих причин:

      1. Ограничение размера (квоты не везде работают нормально).
      2. Возможность использования разных ФС
      3. Возможность использования разных опций монтирования (особенно касательно журнала)
      4. Не поверите, чтобы ограничить раздел и увеличить скорость random read/write


      1. AndreyMtv
        16.11.2017 11:09

        В самих разделах нет ничего страшного и ужасного, но автора сильно печалит невозможность увелисения размера разделов (в некоторых случаях)


        1. ??? Это проблема мбр, что где то у кого то квоты не работают?
          Единственный правильный на мой вкус способ "разбиения на разделы" это операционка на одном диске, пользовательские данные на другом диске. Если операционок больше двух, то запихиваем их в виртуальные машины.
          Можно бесконечно придумывать разные искуственные юзеркейсы, зачем нам кровь из носу нужны разделы, но все они не имеют отношения к главной теме статьи. Нам зачем то нужна куча разделов с постоянной возможностью менять их размер.
          Анек в тему.
          Поиходит мужик к врачу…
          • Доктор, когда, я делаю вот так, у меня болит вот здесь.
          • А вы "вот так" не делайте.


        1. prometheus_ru Автор
          16.11.2017 14:11

          LVM не только меняет разделы. Я могу сделать консистентный (относительно) снэпшот с rootfs и его забекапить. Попробуйте это на досуге с обычными разделами.


          1. begemoth3663
            16.11.2017 16:38

            … и что люди только не придумают, лишь бы не использовать zfs...


            1. prometheus_ru Автор
              16.11.2017 16:38

              Ой, да мне хоть ext2. Просто снэпшоты, как по мне, не должны быть функционалом файловой системы.


              1. kalininmr
                16.11.2017 18:46

                тут большая тема для дискуссии


              1. firegurafiku
                16.11.2017 21:33

                Я могу сделать консистентный (относительно) снэпшот с rootfs и его забекапить.
                Просто снэпшоты, как по мне, не должны быть функционалом файловой системы.

                Если хотите избавиться в этом предложении от слова «относительно», придётся выносить снэпшоты на уровень файловой системы. Если вы при этом хотите иметь качественные компрессию, дедупликацию и шифрование, то придётся встраивать в ФС и их тоже. В результате продвинутая ФС неизбежно получается сложной.


                1. prometheus_ru Автор
                  16.11.2017 22:12

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


                  1. firegurafiku
                    16.11.2017 22:21

                    ряд приложений могут открывать что-то с флагом O_DIRECT

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


                    man 2 open
                    EINVAL The filesystem does not support the O_DIRECT flag.
                           See NOTES for more information.


                    1. prometheus_ru Автор
                      16.11.2017 22:25

                      Так в том и дело, что мы с Вами пришли к соглашению — неважно, где мы делаем снапшот, приложение есть проблема. Но еще раз, я готов долго холиварить на тему «где лучше делать снапшот, в блочном девайсе или в файлухе», но все же пока склоняюсь к блочному девайсу.


        1. JerleShannara
          16.11.2017 18:49

          Зачем мне нужны разделы? Да очень легко, вот крутится уэб сэрвер, на нём всякий ноты.жыэс, похапе, пёрлы и прочие с функционалом «дыра». Уэбсервер должен куда-то уметь писать всякий мусор без особых проблем. Теперь ксакеп вася берёт и заливает какой-нить бинарь, который через дыру в запускает… Ой, не вышло, у меня на /tmp noexec,nosuid, nodev и ещё куча всего стоит. Дешего и сердито, можно конечно с grsec/PaX заморочаться и настроить всё так, что ксакеп даже с дырявым пхп 5.0 и нифига сделать не сможет, но это потребует огромных время и трудозатрат, что не эффективно с точки зрения Убитых Енотов.


          1. firegurafiku
            16.11.2017 21:35

            Ой, не вышло, у меня на /tmp noexec,nosuid, nodev и ещё куча всего стоит.

            Ничего не мешает примонтировать LVM-том с опциями noexec, nosuid и nodev, MBR или GPT для этого не обязательны.


  1. nehrung
    16.11.2017 11:32

    С MBR не всё так просто… Дело в том, что под него наработана куча удобных простому пользователю инструментов и методик, и отказаться от всего этого ему нелегко. Гляньте на содержимое известного пакета ремонтно-восстановительных утилит 2k10 — там для восстановления загрузки есть с десяток программ, но… для MBR. Эквиваленты всего этого для UEFI до меня пока не докатились.
    Но я простой пользователь, а тут разговор на уровне не ниже сисадмина… Пока всё это с вашего уровня спустится на наш, много воды утечёт.


    1. Sly_tom_cat
      16.11.2017 23:50

      Для восстановления UEFI тоже уже есть инструменты: boot-repair например.


  1. scruff
    16.11.2017 12:36

    Немного не догоняю. Поясните — сейчас сделал lsblk на CentOS7.
    /dev/sda1 есть /boot на 500МБ (предполагаю тот самый MBR)
    /dev/sda2/ есть LVM на всё остальное дисковое пространтсво.

    Что в этом полхого? Фактически LVM почти на всём диске. Дели нарезай разделы как хочешь.


    1. prometheus_ru Автор
      16.11.2017 14:10

      А теперь попробуйте увеличить размер диска — это запросто бывает в виртуализированных средах. Тогда чтобы отдать добавленный «хвост» в LVM надо будет создать еще один раздел, его тоже пихнуть в LVM. Проделайте это еще два раза и выяснится, что теперь надо делать extended partition. Ну и поехали.


      1. quartz64
        16.11.2017 15:25

        Можно создать отдельный образ, в котором будет LVM поверх сырого диска, и уже его наращивать.


        1. prometheus_ru Автор
          16.11.2017 15:48

          Так обычно и делается, только зачем два диска? На одном держать загрузочную часть для EFI? Можно, но только две сущности вместо одной.

          На диске, где LVM поверх сырого, свободен первый мегабайт. Так почему бы и нет?


      1. firk
        16.11.2017 15:56

        Почему это?
        Я с LVM дел не имел, но судя по вашему описанию он умеет расширяться в добавленное пространство. Увеличиваете размер раздела, в котором он настроен (если раздел в конце диска), даёте команду LVM'у расшириться в появившееся дополнительное место, и всё.


        1. prometheus_ru Автор
          16.11.2017 16:01

          У Вас LVM в разделе. Тогда надо сначала увеличить раздел, а потом уже увеличивать LVM.

          Поэтому я и говорю, что разделы — зло, если уже есть LVM.


          1. firk
            16.11.2017 16:06

            Так а в чём проблема то? Ну мелкое дополнительное действие. Тогда можно сказать и что система выделения места на хостинге плохая — вам надо сначала увеличить "диск" а потом только увеличивать LVM. А вот если бы диск сам увеличивался при попытке записи за границу его размера — было бы проще.


            1. prometheus_ru Автор
              16.11.2017 16:07

              Знаете, как на MBR увеличиваются разделы? Удаляете и создаете новый. Не самая веселая операция. См. выше про утилиту ptmax для этой цели.


              1. firk
                16.11.2017 16:12

                Это проблема его поддержки конкретным софтом, а не самого формата. Если не привязываться к конкретному софту, то увеличение раздела в MBR делается правкой 4 байтов в загрузочном секторе. Возможно ptmax так и делает.


                1. prometheus_ru Автор
                  16.11.2017 16:13

                  В таком духе все проблемы в IT мире в софте, а не в формате, конечно.


              1. firegurafiku
                16.11.2017 22:03

                Знаете, как на MBR увеличиваются разделы? Удаляете и создаете новый.

                Вас кто-то дезынформировал. Для того, чтобы увеличить размер последнего на диске primary-раздела, достаточно заменить одни три байта на другие три байта — sfdisk с этим прекрасно справляется.


                К сожалению, у меня нет MBR-раздела под рукой, чтобы продемонстрировать, но для GPT это тоже работает. Нужно как-то так:


                Шаг 1. Сдампим текущую таблицу разделов в файл.


                # sfdisk --dump /dev/sda | tee partitions.txt
                label: gpt
                label-id: <...>
                device: /dev/sda
                unit: sectors
                first-lba: 34
                last-lba: 500118157
                
                /dev/sda1 : start=        2048, size=      262144, <...>
                /dev/sda2 : start=      264192, size=      784384, <...>
                /dev/sda3 : start=     1048576, size=   249020416, <...>
                /dev/sda4 : start=   250071040, size=   250046464, <...>

                Шаг 2. Залезем в сдампленный файл редактором. В последней строчке заменим size=250046464 на size=*.


                Шаг 3. Скормим дамп обратно.


                # sfdisk /dev/sda <partitions.txt

                Важно понимать, что магии не бывает, и это работает только с последним разделом на диске, и только при условии не-уменьшения его размера. Если есть возможность — лучше воспользуйтесь gparted, он классный и много чего умеет.


                1. prometheus_ru Автор
                  16.11.2017 22:11

                  Да без проблем, можно и sfdisk, только я вообще рассматриваю с точки зрения fdisk.

                  И да, до 16.04 sfdisk надо было для загрузки вызывать с ключом -f.

                  Но еще раз, по факту, это удаление разделов и создание их заново. А не обновление 4 байтов.


                  1. firegurafiku
                    16.11.2017 22:27

                    Но еще раз, по факту, это удаление разделов и создание их заново. А не обновление 4 байтов.

                    На диске обновится пара десятков секторов (в случае с GPT). Данным при этом не будет ничего — лишь бы в новой таблице смещения разделов совпали с теми, что было в старой (а они совпадут, никуда не денутся).


                1. AntonAlekseevich
                  16.11.2017 22:46

                  Если есть возможность — лучше воспользуйтесь gparted, он классный и много чего умеет, в том числе двигать и ресайзить разделы без потери данных.

                  Только не переносите на объем меньше переносимого раздела в сторону(либо по оффсэту) или фигакс данным.


  1. Sly_tom_cat
    16.11.2017 18:18

    LVM — отстой. :) Подтома btrfs — наше все. :)

    Отдаем весь диск btrfs и GRUB прекрасно ставится в зарезервированный 1М (в начале диска перед фактическим началом потрохов btrfs). И в таком режиме все прекрасно грузится (там, вроде как, MBR c таблицей разделов невольно возникает при установке GRUB, но не используется)
    Никаких тебе таблиц разделов — все в шоколаде…

    … только вот SWAP (если нужен) испортит эту лебединую песню т.к. пока его без костыльного велосипеда с loop девайсом не создать в btrfs…


    1. prometheus_ru Автор
      16.11.2017 22:13

      У меня есть серьезные основания сомневаться в будущем btrfs против LVM лишь потому, что RedHat теперь считает ее deprecated.

      Безусловно, на RedHat свет клином не сошелся, но все же.


      1. Sly_tom_cat
        16.11.2017 23:07

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

        Но упоминать красную шапку с их древним ядром, как повод для беспокойства в судьбе btrfs — еще более не серьезно… они просто уже не могут продолжать тянуть обновления связанные с btrfs в свое древнее ядро… уж слишком сильно оно отстало от мейнстрима… Вот когда (если) они хотя бы на 4.4 перейдут, и при этом не захотят поддерживать btrfs — вот тогда буде повод задуматься…