У меня есть управляемый mdadm RAID1 с одним разделом EXT4 (имеющим как файлы ОС, так и файлы GRUB в /boot/grub ), и я хотел бы знать, какие модули и какая конфигурация мне нужна для GRUB для загрузки с него.
Минимальным требуемым grub.cfg является следующее:
set timeout=1 set root='mduuid/ce16c757e4752e4fa9a2fd4935df1aef' menuentry 'Arch Linux' { linux /boot/vmlinuz-linux root=UUID=05dddf23-1d9f-417e-b3f8-2281a328dc0b rw initrd /boot/initramfs-linux.img }
Да, немного отличается от длинного потока мусора, который генерируется grub-mkconfig , и, как вы можете видеть, для этой установки не нужны модули.
Моя конкретная настройка – это один раздел на диске в формате MBR, на котором я собрал массив RAID1 и раздел EXT4 на этом массиве.
root переменная устанавливается в mduuid/xxx с UUID массива RAID, который вы можете получить, запустив mdadm --examine /dev/sdX на диске или разделе, который является частью массива RAID. Это не UUID файловой системы EXT4 поверх RAID , не используйте UUID, сообщаемый lsblk поскольку он даст вам UUID раздела, который там не работает.
Вы также можете установить root переменную в md/... с меткой вашего массива RAID, указанным при его создании ( mdadm ... -N "some label" ... ). Для других способов указания корневого устройства ознакомьтесь с документацией .
UUID по строке параметра ядра – это UUID файловой системы, которая находится поверх массива RAID – этого можно получить, запустив lsblk -o NAME,UUID :
NAME UUID loop0 └─loop0p2 ce16c757-e475-2e4f-a9a2-fd4935df1aef └─md127 05dddf23-1d9f-417e-b3f8-2281a328dc0b loop1 └─loop1p2 ce16c757-e475-2e4f-a9a2-fd4935df1aef └─md127 05dddf23-1d9f-417e-b3f8-2281a328dc0b
В моем случае это соответствует mdXXX устройства 05dddf23-1d9f-417e-b3f8-2281a328dc0b – 05dddf23-1d9f-417e-b3f8-2281a328dc0b . Не используйте UUID базового раздела – loopXp2 в этом примере.
В качестве бонуса, вот некоторые ужасные сценарии оболочки, которые работают, если вы хотите поэкспериментировать с GRUB в виртуальной машине QEMU / KVM.
Чтобы создать некоторые необработанные диски, они должны быть «сырыми» для монтирования на хосте, вы не можете использовать qcow2 или vmdk:
qemu-img create -f raw driveX.img XXXG # name and size
Чтобы запустить виртуальную машину с двумя дисками, ISO (в данном случае это Archlinux, но это может быть что угодно) и базовый доступ к сети:
/path/to/qemu-system-x86_64 -m 512 -cpu host -smp 2,cores=2,sockets=1 -machine q35,accel=kvm -balloon none -device ahci,id=ahci -drive if=none,file=drive1.img,format=raw,cache=none,aio=native,id=hdd1 -device ide-hd,bus=ahci.0,drive=hdd1 -drive if=none,file=drive2.img,format=raw,cache=none,aio=native,id=hdd2 -device ide-hd,bus=ahci.1,drive=hdd2 -drive if=none,file=arch.iso,format=raw,cache=none,aio=native,id=iso,snapshot=on -device ide-cd,bus=ahci.2,drive=iso -device pci-ohci,id=ohci -device usb-kbd,bus=ohci.0 -device usb-mouse,bus=ohci.0 -netdev user,id=net0 -device e1000-82545em,autonegotiation=on,netdev=net0 -realtime mlock=on
Сценарий для монтирования разделов виртуальной машины на хосте, обязательно запустите QEMU перед запуском, чтобы не повредить разделы:
losetup -P -f drive1.img # create loopback device nodes for the virtual disks losetup -P -f drive2.img mdadm --assemble /dev/md/root /dev/loop0p1 /dev/loop1p1 # assemble the RAID # some distributions will auto-detect and assemble them so it sometimes fails # running this script a second time usually succeeds in mounting it anyway # if it failed the first time - I don't have time to fix the real issue mount "/dev/md/root" rootfs # mount the root FS of the VM in this directory
Сценарий для размонтирования, запустите это (несколько раз, чтобы быть в безопасности) перед началом резервного копирования виртуальной машины:
umount rootfs # umount the FS mdadm --stop /dev/md127 # sometimes the array appears under these names mdadm --stop /dev/md126 # so we stop them as well just to be safe mdadm --stop /dev/md/root # the correct name losetup -D # detach all loop device nodes