Почему во время обновления системы изменился UUID диска?

Разве установка нового ядра меняет UUID раздела?

Граб не умеет пользоватся uuid, в этом-то и проблема. Малейшее изменение символьных названий разделов (удалили, добавили, сменили интерфейс, сменили контроллер в биосе и т.п.) и он уже выпадает в свою консоль восстановления.

Граб не умеет пользоватся uuid

4.2

menuentry 'Void GNU/Linux' --class void --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-caa978a9-3e88-4a27-bec8-a69524c97a38' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod f2fs
	search --no-floppy --fs-uuid --set=root caa978a9-3e88-4a27-bec8-a69524c97a38
	echo	'Loading Linux 6.6.52_1 ...'
	linux	/boot/vmlinuz-6.6.52_1 root=UUID=caa978a9-3e88-4a27-bec8-a69524c97a38 ro  
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initramfs-6.6.52_1.img
}

Ещё можно добавить исходное сообщение, до локализации:

The grub loader was previously installed to a disk that is no longer present, or whose unique identifier has changed.
It warns that grub has to be written to the appropriate boot devices in order for it to stay in sync.

По нему гуглить веселее. Дальше советуют смотреть ″debconf-show grub-pc″ и думать, почему дебиан считает, что установил grub на устройство, которого нет в системе.

Тут целая мешанина, из того, что виртуалка меняет выдаваемую информацию, dpkg думает о том, куда ставил grub и grub, который не может передать системе информацию откуда он загружался.

Это вобще мимо кассы. Содержимое конфига grub не связано с процессом его загрузки. GRUB в начале должен загрузить сам себя и загрузить в себя конфиг-файл.

Можете поизучать команду ″grub-probe″ и понять, можно ли из MBR или файла BOOTX64.EFI вытащить информацию, откуда GRUB будет себя и конфиг загружать и какие модули он засунул в stage1.

А если без GRUB (efistub и пр.)?

Граб не умеет пользоватся uuid

4.2

grub действительно не умеет в uuid.
Тот uuid что прописывается в конфиге обрабатывает не grub, а или скрипты+udev записанные в initramfs.

Тот uuid что прописывается в конфиге обрабатывает не grub

Ну эту то строку обрататывает grub:

search --no-floppy --fs-uuid --set=root caa978a9-3e88-4a27-bec8-a69524c97a38

То есть искать ФС с ядром и initramfs он может по UUID.

Другое дело, что с поиском самого конфига у него плохо. Он обычно ищет по номеру раздела. Но, если каталог grub/ будет на MD-RAID, то в grubx64.efi (и в core.img) будет прописано что-то типа (mduuid/77716c1d5a0125faec3aa8b3c8e4e34)/grub, то есть поиск по uuid md-raid'а.

Ну или через grub-mkimage, наверно, можно что-то сотворить.

То есть …

Ну или …

Зачем гадать? Поставьте виртуалку и попробуйте вcтавить или удалить раздел перед системным, и пощупайте результат сами.

P.S. Проще всего иметь загрузочную флешку с SuperGrub (https://www.supergrubdisk.org/). Загрузить систему, ответственную за граб, с неё. И штатно обновить конфигурацию граба изнутри (update-grub).

Что значит «удалить раздел перед системным»?

У меня так: «Bios Boot», «ESP», «/boot (grub)», «swap», «/». Причём, у меня снят образ первого гигабайта этого диска, и когда мне надо сделать ещё одну систему, я этот гигабайтый образ dd на новый ssd, потом восстанавливаю копию GPT, меняю размеры swap и root разделов, случайный GUID, UUID, редактирую grub.cfg. Но grub не переустанавливаю и всё работает, в гибридном режиме (MBR и EFI).

Чтобы сломать дефолтный груб нужно удалить раздел перед /boot/grub. Причём не просто удалить, а чтобы у номера разделов сдвинулись. Об этом обычно никто не просит и разделы нулевого размера никому не помешают, но разработчики программ (редакторов разделов) об этом не в курсе.