Привет! Новая версия не грузится с nvme на ext4, при этом на экран сыпятся непонятные ошибки на XFS: error: not a correct XFS inode. после этих ошибок загрузка прекращается и все идет по кругу. Версия, которая не работает: 2.12-alt3 Версия, которая еще работает: 2.06-alt19 Повторяю, у меня нет xfs, efi раздел на vfat + rootfs на ext4, созданы 2 раздела gpt на nvme. Если нужна какая-либо еще информация готов предоставить.
Уточните, пожалуйста, какой образ вы используете?
(In reply to obidinog@basealt.ru from comment #1) > Уточните, пожалуйста, какой образ вы используете? не совсем понял вопрос, о каком образе речь, это загрузка реальной (не виртуальной) системы с nvme.
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #2) > (In reply to obidinog@basealt.ru from comment #1) > > Уточните, пожалуйста, какой образ вы используете? > > не совсем понял вопрос, о каком образе речь, это загрузка реальной (не > виртуальной) системы с nvme. В таком случае уточните, пожалуйста, на каком образе базируется система, регулярка или дистрибутив обновленный до сизифа? Подробную информацию можно посмотреть в /etc/os-release.
(Ответ для Egor Ignatov на комментарий #3) > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #2) > > (In reply to obidinog@basealt.ru from comment #1) > > > Уточните, пожалуйста, какой образ вы используете? > > > > не совсем понял вопрос, о каком образе речь, это загрузка реальной (не > > виртуальной) системы с nvme. > > В таком случае уточните, пожалуйста, на каком образе базируется система, > регулярка или дистрибутив обновленный до сизифа? > Подробную информацию можно посмотреть в /etc/os-release. $ cat /etc/os-release NAME="Sisyphus" VERSION="20240122" ID=altlinux VERSION_ID=20240122 PRETTY_NAME="ALT Regular" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:sisyphus:20240122" BUILD_ID="Sisyphus 20201124/unstable" ALT_BRANCH_ID="sisyphus" HOME_URL="http://en.altlinux.org" BUG_REPORT_URL="https://bugs.altlinux.org/" LOGO=altlinux
А в системе нет других xfs томов? Может на внешнем носителе?
(In reply to Egor Ignatov from comment #5) > А в системе нет других xfs томов? Может на внешнем носителе? нет, никаких xfs томов в системе нет
Нашел в чем ошибка[1], в апстриме уже есть патч, исправлю в grub 2.12-alt4. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2254370
(In reply to Egor Ignatov from comment #7) > Нашел в чем ошибка[1], в апстриме уже есть патч, исправлю в grub 2.12-alt4. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2254370 хм, я видел этот баг, но ведь там обсуждается загрузка с xfs и версия 2.06. Или это какой-то rh-specific баг, который не исправлен в апстриме grub?
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #8) > (In reply to Egor Ignatov from comment #7) > > Нашел в чем ошибка[1], в апстриме уже есть патч, исправлю в grub 2.12-alt4. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2254370 > > хм, я видел этот баг, но ведь там обсуждается загрузка с xfs и версия 2.06. > Или это какой-то rh-specific баг, который не исправлен в апстриме grub? Версия там не важна, так как они берут патчи из 2.12. А вот почему у вас воспроизвелась эта ошибка без xfs - загадка. Если вы НЕ используете Secure Boot, то можно проверить исправление установив grub из задания 355797.
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #0) > Если нужна какая-либо еще информация готов предоставить. А у вас efi система или Legacy BIOS?
(In reply to Egor Ignatov from comment #10) > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #0) > > Если нужна какая-либо еще информация готов предоставить. > > А у вас efi система или Legacy BIOS? uefi, но с отключенным secure boot.
У меня не получилось воспроизвести данную ошибку. Проверьте, пожалуйста, исправлена ли она в grub 2.12-alt4 из задания 355797.
(In reply to Egor Ignatov from comment #12) > У меня не получилось воспроизвести данную ошибку. > > Проверьте, пожалуйста, исправлена ли она в grub 2.12-alt4 из задания 355797. проверил, ничего не изменилось, все так же не грузится и такая же ошибка: error: not a correct XFS inode.
Можете, пожалуйста, прислать вывод с blkid
(In reply to obidinog@basealt.ru from comment #14) > Можете, пожалуйста, прислать вывод с blkid А также файл /boot/grub/grub.cfg
(Ответ для obidinog@basealt.ru на комментарий #14) > Можете, пожалуйста, прислать вывод с blkid [root@lks ~]# blkid /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="C832-FB08" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="cec19071-f176-482a-9c18-b4309b0c72e5" /dev/nvme0n1p2: LABEL="Root" UUID="efacf400-5bcb-47fe-be45-7d456279cee4" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="af6f77f3-8a2b-4ff4-a291-147e1cca6b4f" /dev/nvme0n1p3: LABEL="Opt" UUID="f2e9b8b5-3918-4322-9482-e206fc2a2475" UUID_SUB="f29d0dc1-773f-4274-8cfc-a03c0fd9148d" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="extended" PARTUUID="fe492c7d-724d-48f5-8d67-a750c9eea60f" /dev/bcache0: LABEL="Home" UUID="2e72d626-fbfb-485a-b197-ff89cdfad2d6" UUID_SUB="1a59e5ba-e9a4-4201-bdf7-c0d364f4f9bc" BLOCK_SIZE="4096" TYPE="btrfs" /dev/sdb2: UUID="57b59807-0857-f90a-0bf8-2e69a8a457cf" UUID_SUB="264881da-5ea6-de6f-7742-9723bccb4c36" LABEL="lks.home:md0" TYPE="linux_raid_member" PARTUUID="5b239ada-02" /dev/sdb1: LABEL="boot" UUID="5960926e-168e-4556-a59e-94e3f5a04b26" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="5b239ada-01" /dev/md0: UUID="71bd780e-0f93-44ec-8de5-083c99b943ae" TYPE="bcache" /dev/sdc2: UUID="57b59807-0857-f90a-0bf8-2e69a8a457cf" UUID_SUB="88f92e76-553e-9980-fc8c-9f5ca35c13f9" LABEL="lks.home:md0" TYPE="linux_raid_member" PARTUUID="9d7a8514-02" /dev/sdc1: LABEL="boot" UUID="5960926e-168e-4556-a59e-94e3f5a04b26" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9d7a8514-01" /dev/nvme1n1p2: UUID="ac4b3810-9fde-4053-a79d-4d9dabeff22e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="990dc673-370d-420e-9fe3-3c291f7e8778" /dev/nvme1n1p1: UUID="2030defd-bb39-4f24-a7c9-8796b675640a" TYPE="bcache" PARTUUID="96839c03-c088-4c81-b578-26d049b37247" /dev/sda1: UUID="20811390-b51e-4c7b-a915-5c472be7b56c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="1tb_usb3_disk" PARTUUID="7c70194b-833a-4543-aae7-a75227accb59"
Created attachment 16687 [details] grub.cfg
Пришлите, пожалуйста, еще выводы fdisk -l /dev/nvme0n1 lsblk
(In reply to obidinog@basealt.ru from comment #18) > Пришлите, пожалуйста, еще выводы > fdisk -l /dev/nvme0n1 > lsblk А также вывод команды: mokutil --sb-state Спасибо.
(Ответ для obidinog@basealt.ru на комментарий #18) > Пришлите, пожалуйста, еще выводы > fdisk -l /dev/nvme0n1 > lsblk ❯ sudo fdisk -l /dev/nvme0n1 [sudo] password for lakostis: Disk /dev/nvme0n1: 1.86 TiB, 2048408248320 bytes, 4000797360 sectors Disk model: Lexar SSD NM790 2TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 8743C777-6844-4913-A5AB-A60240463159 Device Start End Sectors Size Type /dev/nvme0n1p1 2048 249855 247808 121M EFI System /dev/nvme0n1p2 251904 976562175 976310272 465.5G Linux filesystem /dev/nvme0n1p3 978515968 4000796671 3022280704 1.4T Linux filesystem ❯ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 931.5G 0 disk └─sda1 8:1 0 931.5G 0 part sdb 8:16 0 931.5G 0 disk ├─sdb1 8:17 0 1G 0 part └─sdb2 8:18 0 930.5G 0 part └─md0 9:0 0 930.4G 0 raid1 └─bcache0 252:0 0 930.4G 0 disk /home sdc 8:32 0 931.5G 0 disk ├─sdc1 8:33 0 1G 0 part └─sdc2 8:34 0 930.5G 0 part └─md0 9:0 0 930.4G 0 raid1 └─bcache0 252:0 0 930.4G 0 disk /home sdd 8:48 1 0B 0 disk sde 8:64 1 0B 0 disk sdf 8:80 1 0B 0 disk sdg 8:96 1 0B 0 disk sr0 11:0 1 1024M 0 rom nvme0n1 259:0 0 1.9T 0 disk ├─nvme0n1p1 259:1 0 121M 0 part /boot/efi ├─nvme0n1p2 259:2 0 465.5G 0 part / └─nvme0n1p3 259:3 0 1.4T 0 part /opt nvme1n1 259:4 0 232.9G 0 disk ├─nvme1n1p1 259:5 0 116.4G 0 part │ └─bcache0 252:0 0 930.4G 0 disk /home └─nvme1n1p2 259:6 0 93.2G 0 part ❯ sudo mokutil --sb-state SecureBoot disabled
Created attachment 16688 [details] скриншот ошибки на экране
Похоже, что дело в том, что у вас nvme0n1p1 почему-то размечен и как fat32(vfat), и как fat16(msdos). Похожая ситуация описана тут https://bkhome.org/news/202212/boot-partition-mounts-as-msdos-instead-of-vfat.html
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #21) > Created attachment 16688 [details] > скриншот ошибки на экране может быть, но почему все работало в предыдущей версии grub? По мне это регрессия. В данном случае этот тип раздела видит только parted и blkid. И как это исправлять без пересоздания всего раздела EFI я не знаю.
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #23) > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #21) > > Created attachment 16688 [details] > > скриншот ошибки на экране > > может быть, но почему все работало в предыдущей версии grub? По мне это > регрессия. В данном случае этот тип раздела видит только parted и blkid. И > как это исправлять без пересоздания всего раздела EFI я не знаю. Возможно дело в атрибутах раздела, пришлите, пожалуйста, вывод команды `fdisk -x`
(In reply to Egor Ignatov from comment #24) > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #23) > > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #21) > > > Created attachment 16688 [details] > > > скриншот ошибки на экране > > > > может быть, но почему все работало в предыдущей версии grub? По мне это > > регрессия. В данном случае этот тип раздела видит только parted и blkid. И > > как это исправлять без пересоздания всего раздела EFI я не знаю. > > Возможно дело в атрибутах раздела, пришлите, пожалуйста, вывод команды > `fdisk -x` А также сразу и `fdisk -x -t dos`
Created attachment 16693 [details] fdisk.log
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #26) > Created attachment 16693 [details] > fdisk.log (In reply to Egor Ignatov from comment #24) > Возможно дело в атрибутах раздела, пришлите, пожалуйста, вывод команды > `fdisk -x` Вывод `fdisk -x` тоже нужен
Created attachment 16706 [details] fdisk -x
Created attachment 16755 [details] фото новой ошибки
Обсуждение пока зашло в тупик: > /boot/grub. У вас же grub установлен в ESP полностью, в /boot/efi/grub. > Ровно как и update-grub берет путь к конфигу из /etc/sysconfig/grub2 > GRUB_AUTOUPDATE_CFGNAME, который по умолчанию /boot/grub/grub.cfg. Это > явно не стандартная конфигурация после установки системы, удивлен, что > Вы не знали. Я это знаю, но у меня вместо /boot/grub был симлинк на /boot/efi/grub. Я ли его зачем-то сделал, или установщик не знаю. $ fgrep GRUB_AUTOUPDATE_CFGNAME /etc/sysconfig/grub2 fgrep: warning: fgrep is obsolescent; using grep -F GRUB_AUTOUPDATE_CFGNAME=/boot/grub/grub.cfg > > Я лишь прошу, чтобы в ESP был порядок, и в директориях > /boot/efi/EFI/altlinux и /boot/efi/EFI/BOOT была одна установка grub > (grub-efi-autoupdate это делает флагом --force-extra-removable почти > всегда). В Вашем дампе в этих директориях конфиги от разных версий. > Восстановил директории убрал симлинк и удалил /boot/efi/grub. Потом выполнил обновление пакета: [root@lks ~]# apt-get install grub-efi Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: grub-common The following packages will be upgraded grub-common grub-efi 2 upgraded, 0 newly installed, 0 removed and 171 not upgraded. Need to get 0B/8954kB of archives. After unpacking 192kB disk space will be freed. Do you want to continue? [Y/n] Committing changes... Preparing... #################################################################################################### [100%] Updating / installing... 1: grub-common-2.12-alt3 ##warning: /etc/sysconfig/grub2 created as /etc/sysconfig/grub2.rpmnew ################################################################################################## [ 25%] 2: grub-efi-2.12-alt3 #################################################################################################### [ 50%] Searching for ALT Linux GRUB efi image to update Skipping /boot/efi/EFI/BOOT/BOOT*.EFI (not ALT Linux GRUB) Skipping /boot/efi/EFI/BOOT/grub*.efi (not ALT Linux GRUB) Found /boot/efi/EFI/altlinux/grub*.efi (ALT Linux GRUB) Updating grub in /boot/efi with --force-extra-removable Installing for x86_64-efi platform. Installation finished. No error reported. Cleaning up / removing... 3: grub-efi-2.06-alt19 #################################################################################################### [ 75%] 4: grub-common-2.06-alt19 #################################################################################################### [100%] egrep: warning: egrep is obsolescent; using grep -E egrep: warning: egrep is obsolescent; using grep -E Searching for ALT Linux GRUB efi image to update Skipping /boot/efi/EFI/BOOT/BOOT*.EFI (not ALT Linux GRUB) Skipping /boot/efi/EFI/BOOT/grub*.efi (not ALT Linux GRUB) Found /boot/efi/EFI/altlinux/grub*.efi (ALT Linux GRUB) Updating grub in /boot/efi with --force-extra-removable Installing for x86_64-efi platform. Installation finished. No error reported. Generating grub configuration file ... Found linux image: /boot/vmlinuz Found initrd image: /boot/initrd.img Found linux image: /boot/vmlinuz-lks-wks Found initrd image: /boot/initrd-lks-wks.img Found linux image: /boot/vmlinuz-6.10.0-lks-wks-alt2.6 Found initrd image: /boot/initrd-6.10.0-lks-wks-alt2.6.img Adding boot menu entry for UEFI Firmware Settings ... Found memtest image: /boot/memtest-7.00.bin Found memtest image: /boot/memtest-7.00.efi done После загрузки получил уже другую ошибку (см. вложение), которая с xfs уже мало связана. Что еще можно посмотреть?
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #30) > Что еще можно посмотреть? Как я уже писал Вам на почту: > Пока все попытки воспроизвести ошибку локально ни к чему не привели. Можем > попробовать зайти с другой стороны. В приложении образ grub-2.12-alt4 без модуля > xfs, попробуйте загрузиться с него, пожалуйста. Так как у Вас выключен Secure > Boot, то возможно еще придется убрать(переименовать) отдельный модуль xfs > (/boot/efi/grub/x86_64-efi/xfs.mod в Вашем случае). Как минимум ошибка должна > пропасть, но это не значит, что в grub есть регресс, возможно новая версия > выявила какую-то проблему в Вашей установке.
Created attachment 16756 [details] grub-2.12-alt4 w/o xfs module
(In reply to Egor Ignatov from comment #31) > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #30) > > Что еще можно посмотреть? > > Как я уже писал Вам на почту: > > Пока все попытки воспроизвести ошибку локально ни к чему не привели. Можем > > попробовать зайти с другой стороны. В приложении образ grub-2.12-alt4 без модуля > > xfs, попробуйте загрузиться с него, пожалуйста. Так как у Вас выключен Secure > > Boot, то возможно еще придется убрать(переименовать) отдельный модуль xfs > > (/boot/efi/grub/x86_64-efi/xfs.mod в Вашем случае). Как минимум ошибка должна > > пропасть, но это не значит, что в grub есть регресс, возможно новая версия > > выявила какую-то проблему в Вашей установке. С данной версией ошибок при загрузке нет. Порядок проверки: - установил grub-common-2.12-alt3.x86_64 grub-efi-2.12-alt3.x86_64 - перезаписал grub*.efi в /boot/efi/EFI/{Boot,altlinux}/ модулем из вложения - убрал xfs.mod из /boot/grub/x86_64-efi Насчет "новая версия выявила какую-то проблему в Вашей установке" - если новая версия перестает работать таким образом да еще в коде, который вообще не должен выполняться, это регресс.
(In reply to Egor Ignatov from comment #31) > возможно новая версия выявила какую-то проблему в Вашей установке. Если такова рекация Grub именно на SEC_TYPE="msdos" на разделе "EFI System" (/dev/nvme0n1p1 в обсуждении), то это явный баг в Grub. Хотя, конечно, интересно, откуда этот SEC_TYPE взялся, зачем, а так же как его убрать. С другой стороны й меня есть инсталляция Workstation K (кажется бету ещё ставил), и там SEC_TYPE нет: Device Start End Sectors Size Type /dev/nvme0n1p1 2048 16779263 16777216 8G Linux swap /dev/nvme0n1p2 16779264 17188863 409600 200M EFI System /dev/nvme0n1p3 17188864 143038463 125849600 60G Linux filesystem /dev/nvme0n1p5 143050752 176605183 33554432 16G Linux filesystem /dev/nvme0n1p6 176605184 500118158 323512975 154,3G Linux filesystem # blkid | grep nvme0n1p2 /dev/nvme0n1p2: UUID="588A-2010" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="19e2a8b9-2535-ce44-b291-955f2b368979" Обновлять до p11 пока не пробовал.
(In reply to Sergey Y. Afonin from comment #34) > (In reply to Egor Ignatov from comment #31) > > > возможно новая версия выявила какую-то проблему в Вашей установке. > > Если такова рекация Grub именно на SEC_TYPE="msdos" на разделе "EFI System" > (/dev/nvme0n1p1 в обсуждении), то это явный баг в Grub. Хотя, конечно, > интересно, откуда этот SEC_TYPE взялся, зачем, а так же как его убрать. С > другой стороны й меня есть инсталляция Workstation K (кажется бету ещё > ставил), и там SEC_TYPE нет: Я думаю, что автор этой статьи[1] сам до конца не разобрался. Судя по всему blkid пишет SEC_TYPE="msdos" на всех fat16 разделах. При этом у меня на установке системы с ESP в fat16 ошибка не воспроизвелась. То есть предположение что "Новая версия ломает загрузку с FAT разделом, созданным одновременно как fat32(vfat), и как fat16(msdos)" оказалось ошибочным. [1] https://bkhome.org/news/202212/boot-partition-mounts-as-msdos-instead-of-vfat.html (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #33) > Насчет "новая версия выявила какую-то проблему в Вашей установке" - если > новая версия перестает работать таким образом да еще в коде, который вообще > не должен выполняться, это регресс. Код xfs как раз должен исполняться при поиске файловой системы на машине (команда search.fs_uuid в /boot/efi/altlinux/grub.cfg). Если имеется такая возможность, то я бы попросил Вас попробовать запустить систему с одним только подключенным системным диском (nvme0n1) до полной загрузки GRUB, запускать linux не обязательно.
(In reply to Egor Ignatov from comment #35) > Код xfs как раз должен исполняться при поиске файловой системы на машине Должен-то он должен, только вот он не должен варианты FAT считать за XFS, находить там структуры этой ФС и считать их поломанными. Вообще я уже наступал на грабли с Grub, когда он находит не то и путается в показаниях: https://www.altlinux.org/Update/p10#Grub_и_multiple_partition_labels Баг правда не стал заводить.
(In reply to Egor Ignatov from comment #35) > Eсли имеется такая возможность, то я бы попросил Вас попробовать запустить > систему с одним только подключенным системным диском (nvme0n1) до полной > загрузки GRUB, запускать linux не обязательно. Нашел вариант попроще, достаточно добавить флаг --efidisk-only к команде search.fs_uuid в /boot/efi/altlinux/grub.cfg. Если с этим флагом система загрузится, значит какая-то из файловых систем с других дисков проходит валидацию суперблока xfs. Нашел, где в коде нужно добавить проверку на ошибку "error: not a correct XFS inode.", задание с возможным исправлением: https://packages.altlinux.org/en/tasks/356611 Возможно мы наткнулись на редкий случай, когда случайные данные на диске совпали с magic number суперблока XFS. Или, может быть, XFS был когда-то раньше на диске.
(In reply to Egor Ignatov from comment #37) > (In reply to Egor Ignatov from comment #35) > > Eсли имеется такая возможность, то я бы попросил Вас попробовать запустить > > систему с одним только подключенным системным диском (nvme0n1) до полной > > загрузки GRUB, запускать linux не обязательно. > > Нашел вариант попроще, достаточно добавить флаг --efidisk-only к команде > search.fs_uuid в /boot/efi/altlinux/grub.cfg. Если с этим флагом система > загрузится, значит какая-то из файловых систем с других дисков проходит > валидацию суперблока xfs. > > Нашел, где в коде нужно добавить проверку на ошибку "error: not a correct > XFS inode.", задание с возможным исправлением: > https://packages.altlinux.org/en/tasks/356611 > > Возможно мы наткнулись на редкий случай, когда случайные данные на диске > совпали с magic number суперблока XFS. Или, может быть, XFS был когда-то > раньше на диске. что именно мне нужно проверить?
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #38) > что именно мне нужно проверить? Я бы, кстати, по возможности, попробывал бы раздел нулями затереть, форматнуть и вернуть файлы обратно. Ну и предварительно его как есть забакапить через dd, и, если что, так же вернуть обратно через dd.
(In reply to Sergey Y. Afonin from comment #39) > > что именно мне нужно проверить? > > Я бы, кстати, по возможности, попробывал бы раздел нулями затереть, > форматнуть и вернуть файлы обратно. Ну и предварительно его как есть > забакапить через dd, и, если что, так же вернуть обратно через dd. И, может быть, копию радела Егору отдать, для опытов. Вдруг прокатит?
(In reply to Sergey Y. Afonin from comment #40) > (In reply to Sergey Y. Afonin from comment #39) > > Я бы, кстати, по возможности, попробывал бы раздел нулями затереть, > > форматнуть и вернуть файлы обратно. Ну и предварительно его как есть > > забакапить через dd, и, если что, так же вернуть обратно через dd. > > И, может быть, копию радела Егору отдать, для опытов. Вдруг прокатит? Я уже получил от Константина дамп таблицы разделов и ESP. Ничего подозрительного там не обнаружил. (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #38) > что именно мне нужно проверить? Добавьте, пожалуйста, в начало файла /boot/efi/EFI/altlinux/grub.cfg строки: set pager=1 set debug="xfs,disk" Далее при загрузке появится лог поиска файловых систем. Вам нужно найти устройство, которое успешно проходит валидацию xfs суперблока, строки: ... kern/disk.c:196:disk: Opening `<имя устройства>'... fs/xfs.c:288:xfs: Validating superblock fs/xfs.c:300:xfs: XFS v5 superblock detected ... Далее нужно будет понять что не так с файловой системой на этом устройстве и почему grub думает, что там xfs. Мне будет достаточно дампа первых 2ух секторов (1KiB) этого устройства.
(In reply to Egor Ignatov from comment #41) > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #38) > > что именно мне нужно проверить? > > Добавьте, пожалуйста, в начало файла /boot/efi/EFI/altlinux/grub.cfg строки: > set pager=1 > set debug="xfs,disk" > > Далее при загрузке появится лог поиска файловых систем. Вам нужно найти > устройство, которое успешно проходит валидацию xfs суперблока, строки: > ... > kern/disk.c:196:disk: Opening `<имя устройства>'... > fs/xfs.c:288:xfs: Validating superblock > fs/xfs.c:300:xfs: XFS v5 superblock detected > ... > > Далее нужно будет понять что не так с файловой системой на этом устройстве и > почему grub думает, что там xfs. > Мне будет достаточно дампа первых 2ух секторов (1KiB) этого устройства. Константин, удалось что-нибудь выяснить?
(In reply to Egor Ignatov from comment #41) > (In reply to Sergey Y. Afonin from comment #40) > > (In reply to Sergey Y. Afonin from comment #39) > > > Я бы, кстати, по возможности, попробывал бы раздел нулями затереть, > > > форматнуть и вернуть файлы обратно. Ну и предварительно его как есть > > > забакапить через dd, и, если что, так же вернуть обратно через dd. > > > > И, может быть, копию радела Егору отдать, для опытов. Вдруг прокатит? > > Я уже получил от Константина дамп таблицы разделов и ESP. Ничего > подозрительного там не обнаружил. > > > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #38) > > что именно мне нужно проверить? > > Добавьте, пожалуйста, в начало файла /boot/efi/EFI/altlinux/grub.cfg строки: > set pager=1 > set debug="xfs,disk" > > Далее при загрузке появится лог поиска файловых систем. Вам нужно найти > устройство, которое успешно проходит валидацию xfs суперблока, строки: > ... > kern/disk.c:196:disk: Opening `<имя устройства>'... > fs/xfs.c:288:xfs: Validating superblock > fs/xfs.c:300:xfs: XFS v5 superblock detected > ... > > Далее нужно будет понять что не так с файловой системой на этом устройстве и > почему grub думает, что там xfs. > Мне будет достаточно дампа первых 2ух секторов (1KiB) этого устройства. да, по логам видно, что grub это заметил на sda2 (и sdb2): ❯ sudo dd if=/dev/sda2 of=./sda2-dump.img bs=512 count=1024 [sudo] password for lakostis: 1024+0 records in 1024+0 records out 524288 bytes (524 kB, 512 KiB) copied, 0.0163544 s, 32.1 MB/s ❯ file ./sda2-dump.img ./sda2-dump.img: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) ❯ sudo blkid /dev/sda2 /dev/sda2: UUID="57b59807-0857-f90a-0bf8-2e69a8a457cf" UUID_SUB="264881da-5ea6-de6f-7742-9723bccb4c36" LABEL="lks.home:md0" TYPE="linux_raid_member" PARTUUID="5b239ada-02" Но опять же, эти диски может и содержали xfs когда-то, но это было проблемой. Более того, к ним был применен wipefs, странно, что там какие-то остатки xfs все еще видны после этого.
Created attachment 16805 [details] grub нашел xfs
Вопрос на засыпку. А Grub, который грузился, про xfs знал? Если нет, может просто оторвать? Или корень (или отдельный /boot) на xfs имеет смысл?
