Как управлять именами дисков и разделов
Блок My Ubuntu 16.04 MythTV имеет два жестких диска sda и sdb, подключенных к интерфейсам SATA1 и SATA2 соответственно. Они имеют разделы sda1, sda2 и sdb1, sdb2 и др. Я устанавливаю SDD объемом 240 ГБ и, исследовав эту тему, ожидал, что это будет sdc при подключении к SATA3. По каким-то причинам gparted видит в нем sdb, а то, что было sdb, теперь sdc, так что все имена разделов неправильные. Т.е. sdc имеет разделы sdb1, sdb2 и т.д.
Намерение состоит в том, чтобы перенести на SDD все, кроме двух разделов размером 1 ГБ, используемых для записей MythTV, по одному на каждом HDD. В идеале sda должен быть SDD на SATA1 с текущим sda становится sdb на SATA2, а текущий sdb становится sdc на SATA3 с соответствующими именами всех разделов.
Тогда только несколько вопросов:-
Является ли это разумной целью и возможно ли это достичь без переустановки, и как этого достичь?
Было бы предпочтительно каким-то образом форсировать название "sdc" для SDD, чтобы разделы могли быть названы более подходящим образом?
Есть ли какие-нибудь накладные расходы операционной системы или какие-нибудь другие проблемы (кроме путаницы) при несовпадении названий разделов на диске?
Названия разделов должны быть уникальными для всей системы или только для каждого диска, т.е. можно ли сослаться на них, включив название диска, например, /dev/sda/sdb4?
Я уверен, что здесь, вероятно, есть еще несколько вопросов, но на данный момент я не могу придумать ни одного из них.
2 ответа
Имена разделов уникальны по ширине системы, никакие два не могут быть идентичными, или вы сталкиваетесь с большими проблемами. Вы попадете в ситуацию, когда не будете знать, какой раздел монтируется в данный момент, не проверив физическое расположение. Он может измениться между загрузками, так как это будет зависеть от того, какой диск был виден системой для монтирования первым. По этой причине ваш SSD оказался в виде /dev/sdb, который был виден раньше другого диска, или на канале контроллера, который находится в очереди перед вторым вращением, результат такой же, как и при первом вращении, поэтому он получает следующую букву диска в очереди для назначения. Для обеспечения предсказуемости при монтаже можно использовать PARTUUID или LABEL в Вашей /etc/fstab, чтобы не допустить путаницы при смене буквы привода. Для поиска необходимой информации используйте команду blkid в качестве корневой или с помощью sudo.
root@buster-raspi:~# blkid
/dev/mmcblk1: PTUUID="8ed03b0d" PTTYPE="dos"
/dev/mmcblk1p1: SEC_TYPE="msdos" LABEL_FATBOOT="RASPIFIRM" LABEL="RASPIFIRM" UUID="AC25-5007" TYPE="vfat" PARTUUID="8ed03b0d-01"
/dev/mmcblk1p2: LABEL="RASPIROOT" UUID="cce1d06d-e567-4b48-a624-e823b516507f" TYPE="ext4" PARTUUID="8ed03b0d-02"
/dev/sda1: SEC_TYPE="msdos" UUID="3651-174E" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="9fad4e77-177d-4a3c-929a-3897e6bc1810"
/dev/sda2: UUID="4a349c2c-0df5-4fdb-a99f-906423554de9" TYPE="ext4" PARTUUID="59097f66-f9fb-4a50-a491-8a71becaa2bd"
Под командой /etc/fstab я показываю свой выход Pi 4.
root@buster-raspi:~# cat /etc/fstab
# The root file system has fs_passno=1 as per fstab(5) for automatic fsck.
#LABEL=RASPIROOT / ext4 rw 0 1
PARTUUID=59097f66-f9fb-4a50-a491-8a71becaa2bd / ext4 rw 0 1
# All other file systems have fs_passno=2 as per fstab(5) for automatic fsck.
LABEL=RASPIFIRM /boot/firmware vfat rw 0 2
В этом файле видно, как он смонтирован с помощью LABEL=RASPIFIRM для загрузки машины и PARTUUID=59097f66-f9fb-4a50-a491-. 8a71beca2bd / ext4 rw 0 1 для / системы, которую я скопировал с прокомментированного раздела #LABEL=RASPIROOT, чтобы файлы загружались с SSD, а не с карты sd, на которой они были.
Этот метод обеспечивает постоянное надежное именование файловых систем для монтирования при загрузке. Они никогда не меняются, если только вы не отформатируете раздел или вручную в случае LABEL не измените его. Оба намеренных действия со стороны пользователей, которые должны знать, что теперь изменения необходимы, чтобы иметь возможность загрузиться заново.
Для повторной загрузки без переустановки, для этого нужно скопировать файлы на текущий /. После этого, если BIOS загружается, то GRUB устанавливается на новый диск методом повторной проверки, чтобы убедиться, что новая установка найдена. Затем загрузитесь в этот установочный диск, сотрите старый диск и повторите GRUB, чтобы устранить ошибку, из-за которой он не был найден после стирания. GRUB настолько замечательно, что даже при отсутствии не включенной операционной системы откажет в попытке загрузки. До тех пор, пока эта запись не будет удалена путём переустановки, загрузка будет неудачной, даже если эта ОС не имеет никакого отношения к загрузке той, что вам нужна. Если бы система EFI, которой, кажется, у вас нет, вам бы пришлось скопировать крошечный /dev/sda1 в начале диска в соответствующий раздел на новом диске и пройти через GRUB двойную установку заново. Вы можете увидеть этот раздел в моем выводе выше на /dev/sda1 SSDSSD, который я использую, т.к. он разбит на разделы GPT и требует загрузки с помощью метода EFI. Думаю, я все это покрыл. Побитый вышеприведенным плакатом во время его написания, я все равно его оставлю.
Короткий ответ - "больше нет". Я думаю, что это было около 16.04, когда правила udev для указания устройств хранения на /dev/sdX ушли. Вы можете использовать udev для создания дополнительных симлинков с предопределенными именами, но /dev/sdX (и некоторые другие) подпадают под компетенцию ядра.
Имена устройств в ядре даются в зависимости от порядка их обнаружения. Загрузочный диск всегда будет обнаружен первым, поэтому, если он находится на шине, которой назначена буква в /dev/sdX, то X всегда будет a. Если во время загрузки SSD-накопитель отвечает на команду зонда быстрее, чем жесткий диск, то, вероятно, он всегда будет назначен следующим, за ним следуют устройства, которые реагируют медленнее. Если SSD и жесткий диск имеют очень близкое время отклика, которое колеблется по какой-либо причине, вы можете увидеть, что назначение подкачки с разными загрузочными устройствами.
По таким причинам мы обычно используем точки монтирования с UUID, так что обычно все "просто работает", и нам не нужно скрипеть с настройками или изменять fstab чаще, чем это необходимо