Bug 51238

Summary: Новая версия ломает загрузку с разделом, содержащим остатки xfs superblock
Product: Sisyphus Reporter: Konstantin A Lepikhov (L.A. Kostis) <lakostis>
Component: grubAssignee: Egor Ignatov <egori>
Status: ASSIGNED --- QA Contact: qa-sisyphus
Severity: major    
Priority: P5 CC: asy, nickel, obidinog, placeholder, rider
Version: unstable   
Hardware: x86_64   
OS: Linux   
Bug Depends on:    
Bug Blocks: 51222    
Attachments:
Description Flags
grub.cfg
none
скриншот ошибки на экране
none
fdisk.log
none
fdisk -x
none
фото новой ошибки
none
grub-2.12-alt4 w/o xfs module
none
grub нашел xfs none

Description Konstantin A Lepikhov (L.A. Kostis) 2024-08-22 10:07:50 MSK
Привет!

Новая версия не грузится с nvme на ext4, при этом на экран сыпятся непонятные ошибки на XFS:

error: not a correct XFS inode.

после этих ошибок загрузка прекращается и все идет по кругу.

Версия, которая не работает: 2.12-alt3
Версия, которая еще работает: 2.06-alt19

Повторяю, у меня нет xfs, efi раздел на vfat + rootfs на ext4, созданы 2 раздела gpt на nvme.

Если нужна какая-либо еще информация готов предоставить.
Comment 1 obidinog@basealt.ru 2024-08-22 10:42:24 MSK
Уточните, пожалуйста, какой образ вы используете?
Comment 2 Konstantin A Lepikhov (L.A. Kostis) 2024-08-22 11:23:40 MSK
(In reply to obidinog@basealt.ru from comment #1)
> Уточните, пожалуйста, какой образ вы используете?

не совсем понял вопрос, о каком образе речь, это загрузка реальной (не виртуальной) системы с nvme.
Comment 3 Egor Ignatov 2024-08-22 11:45:13 MSK
(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.
Comment 4 Konstantin A Lepikhov (L.A. Kostis) 2024-08-22 13:05:31 MSK
(Ответ для 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
Comment 5 Egor Ignatov 2024-08-22 14:15:09 MSK
А в системе нет других xfs томов? Может на внешнем носителе?
Comment 6 Konstantin A Lepikhov (L.A. Kostis) 2024-08-22 15:59:54 MSK
(In reply to Egor Ignatov from comment #5)
> А в системе нет других xfs томов? Может на внешнем носителе?

нет, никаких xfs томов в системе нет
Comment 7 Egor Ignatov 2024-08-22 17:16:17 MSK
Нашел в чем ошибка[1], в апстриме уже есть патч, исправлю в grub 2.12-alt4.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2254370
Comment 8 Konstantin A Lepikhov (L.A. Kostis) 2024-08-22 18:26:10 MSK
(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?
Comment 9 Egor Ignatov 2024-08-22 18:47:56 MSK
(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.
Comment 10 Egor Ignatov 2024-08-22 19:16:45 MSK
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #0)
> Если нужна какая-либо еще информация готов предоставить.

А у вас efi система или Legacy BIOS?
Comment 11 Konstantin A Lepikhov (L.A. Kostis) 2024-08-22 19:29:38 MSK
(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.
Comment 12 Egor Ignatov 2024-08-23 09:24:04 MSK
У меня не получилось воспроизвести данную ошибку.

Проверьте, пожалуйста, исправлена ли она в grub 2.12-alt4 из задания 355797.
Comment 13 Konstantin A Lepikhov (L.A. Kostis) 2024-08-23 10:42:33 MSK
(In reply to Egor Ignatov from comment #12)
> У меня не получилось воспроизвести данную ошибку.
> 
> Проверьте, пожалуйста, исправлена ли она в grub 2.12-alt4 из задания 355797.

проверил, ничего не изменилось, все так же не грузится и такая же ошибка:

error: not a correct XFS inode.
Comment 14 obidinog@basealt.ru 2024-08-23 11:40:25 MSK
Можете, пожалуйста, прислать вывод с blkid
Comment 15 Egor Ignatov 2024-08-23 11:58:33 MSK
(In reply to obidinog@basealt.ru from comment #14)
> Можете, пожалуйста, прислать вывод с blkid

А также файл /boot/grub/grub.cfg
Comment 16 Konstantin A Lepikhov (L.A. Kostis) 2024-08-23 14:33:14 MSK
(Ответ для 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"
Comment 17 Konstantin A Lepikhov (L.A. Kostis) 2024-08-23 14:34:33 MSK
Created attachment 16687 [details]
grub.cfg
Comment 18 obidinog@basealt.ru 2024-08-23 14:59:56 MSK
Пришлите, пожалуйста, еще выводы
fdisk -l /dev/nvme0n1
lsblk
Comment 19 Egor Ignatov 2024-08-23 15:10:06 MSK
(In reply to obidinog@basealt.ru from comment #18)
> Пришлите, пожалуйста, еще выводы
> fdisk -l /dev/nvme0n1
> lsblk

А также вывод команды:
mokutil --sb-state

Спасибо.
Comment 20 Konstantin A Lepikhov (L.A. Kostis) 2024-08-23 15:14:06 MSK
(Ответ для 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
Comment 21 Konstantin A Lepikhov (L.A. Kostis) 2024-08-23 15:16:41 MSK
Created attachment 16688 [details]
скриншот ошибки на экране
Comment 22 Egor Ignatov 2024-08-23 15:30:06 MSK
Похоже, что дело в том, что у вас nvme0n1p1 почему-то размечен и как fat32(vfat), и как fat16(msdos).

Похожая ситуация описана тут https://bkhome.org/news/202212/boot-partition-mounts-as-msdos-instead-of-vfat.html
Comment 23 Konstantin A Lepikhov (L.A. Kostis) 2024-08-23 16:54:29 MSK
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #21)
> Created attachment 16688 [details]
> скриншот ошибки на экране

может быть, но почему все работало в предыдущей версии grub? По мне это регрессия. В данном случае этот тип раздела видит только parted и blkid. И как это исправлять без пересоздания всего раздела EFI я не знаю.
Comment 24 Egor Ignatov 2024-08-23 18:19:41 MSK
(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`
Comment 25 Egor Ignatov 2024-08-23 18:27:51 MSK
(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`
Comment 26 Konstantin A Lepikhov (L.A. Kostis) 2024-08-24 11:31:30 MSK
Created attachment 16693 [details]
fdisk.log
Comment 27 Egor Ignatov 2024-08-26 08:31:31 MSK
(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` тоже нужен
Comment 28 Konstantin A Lepikhov (L.A. Kostis) 2024-08-26 10:00:31 MSK
Created attachment 16706 [details]
fdisk -x
Comment 29 Konstantin A Lepikhov (L.A. Kostis) 2024-08-29 23:58:42 MSK
Created attachment 16755 [details]
фото новой ошибки
Comment 30 Konstantin A Lepikhov (L.A. Kostis) 2024-08-29 23:59:16 MSK
Обсуждение пока зашло в тупик:

> /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 уже
мало связана. Что еще можно посмотреть?
Comment 31 Egor Ignatov 2024-08-30 10:02:24 MSK
(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 есть регресс, возможно новая версия
> выявила какую-то проблему в Вашей установке.
Comment 32 Egor Ignatov 2024-08-30 10:03:20 MSK
Created attachment 16756 [details]
grub-2.12-alt4 w/o xfs module
Comment 33 Konstantin A Lepikhov (L.A. Kostis) 2024-08-31 12:04:50 MSK
(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

Насчет "новая версия выявила какую-то проблему в Вашей установке" - если новая версия перестает работать таким образом да еще в коде, который вообще не должен выполняться, это регресс.
Comment 34 Sergey Y. Afonin 2024-09-01 10:22:20 MSK
(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 пока не пробовал.
Comment 35 Egor Ignatov 2024-09-02 11:42:54 MSK
(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 не обязательно.
Comment 36 Sergey Y. Afonin 2024-09-02 12:09:09 MSK
(In reply to Egor Ignatov from comment #35)

> Код xfs как раз должен исполняться при поиске файловой системы на машине

Должен-то он должен, только вот он не должен варианты FAT считать за XFS, находить там структуры этой ФС и считать их поломанными. Вообще я уже наступал на грабли с Grub, когда он находит не то и путается в показаниях:
https://www.altlinux.org/Update/p10#Grub_и_multiple_partition_labels
Баг правда не стал заводить.
Comment 37 Egor Ignatov 2024-09-02 13:08:33 MSK
(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 был когда-то раньше на диске.
Comment 38 Konstantin A Lepikhov (L.A. Kostis) 2024-09-03 19:41:40 MSK
(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 был когда-то
> раньше на диске.

что именно мне нужно проверить?
Comment 39 Sergey Y. Afonin 2024-09-03 23:18:36 MSK
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #38)

> что именно мне нужно проверить?

Я бы, кстати, по возможности, попробывал бы раздел нулями затереть, форматнуть и вернуть файлы обратно. Ну и предварительно его как есть забакапить через dd, и, если что, так же вернуть обратно через dd.
Comment 40 Sergey Y. Afonin 2024-09-03 23:21:03 MSK
(In reply to Sergey Y. Afonin from comment #39)

> > что именно мне нужно проверить?
> 
> Я бы, кстати, по возможности, попробывал бы раздел нулями затереть,
> форматнуть и вернуть файлы обратно. Ну и предварительно его как есть
> забакапить через dd, и, если что, так же вернуть обратно через dd.

И, может быть, копию радела Егору отдать, для опытов. Вдруг прокатит?
Comment 41 Egor Ignatov 2024-09-04 11:50:37 MSK
(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) этого устройства.
Comment 42 Egor Ignatov 2024-09-06 11:16:11 MSK
(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) этого устройства.

Константин, удалось что-нибудь выяснить?
Comment 43 Konstantin A Lepikhov (L.A. Kostis) 2024-09-06 13:52:00 MSK
(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 все еще видны после этого.
Comment 44 Konstantin A Lepikhov (L.A. Kostis) 2024-09-06 13:53:20 MSK
Created attachment 16805 [details]
grub нашел xfs
Comment 45 Sergey Y. Afonin 2024-09-11 10:39:44 MSK
Вопрос на засыпку. А Grub, который грузился, про xfs знал? Если нет, может просто оторвать? Или корень (или отдельный /boot) на xfs имеет смысл?