Description of problem: 1: Filesystem larger than partition! - System may could possibly break in future due to the filesystem size error. 2: Kernel say it use utf8 which is not recommended on FAT. - Another program editing EFI may make havoc for Mageia or vice versa) ___Spotted in system log during boot: okt 01 17:51:59 svarten kernel: FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! okt 01 17:51:59 svarten kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. But, checking the log from previous shutdown, it report that it works: okt 01 06:55:22 svarten systemd[1]: Unmounting /boot/EFI... okt 01 06:55:22 svarten systemd[1]: Unmounted /boot/EFI. ___Trying fsck anyway: # LC_ALL=C fsck -V /dev/sdb1 fsck from util-linux 2.33.2 [/usr/sbin/fsck.vfat (1) -- /boot/EFI] fsck.vfat /dev/sdb1 fsck.fat 4.1 (2017-01-24) Seek to 237483520:Invalid argument Aww, what now? ___Steps to Reproduce: (How i got here) 1. I had a Mageia 6 64 bit system: on the SSD /dev/sdb there was a /boot ext4 partition, and a LUKS encrypted partition containing a pv for LVM containing /, /home, swap. Online upgrade failed and install was originally mga4 so time to install fresh anyway, so: 2. Upgraded to mga7.1 using classic installer iso on USB. Previous system used mbr partition table, but i now chose to go for EFI. I reused LUKS and the LVM, in which I kept /home, made a new / smaller than before, and a new larger swap. Deleted the separate /boot partition, created a /boot/EFI fat32 per default as installer suggested but much smaller (14MB), and then a new /boot ext4 partition for the rest of space (200MB) up to the LUKS. Completed install, rebooted, and system have run perfectly for a couple of weeks now. Both diskdrake and Gparted report sdb1 to be 14MB as i set it. But df tell wrong size: /dev/sdb5 200M 67M 119M 37% /boot /dev/sdb1 223M 122K 223M 1% /boot/EFI Actually df report sdb1 to be the size that the old /boot had in mga6. ( Hmmm possibly i did not delete old /boot, but instead shrunk it and used it for /boot/EFI ... Anyway it should have worked. ) So df list the filesystem size and not the partition size? Now in GParted, i unmount /dev/sdb1, and order a filesystem check: It say filesystem is larger than its volume. I tell it to ignore and libparted say it can not change the file system to this size. GParted also say when i ask it to show information of that partition, that it cant read it. Version-Release number of selected component (if applicable): Used: Mageia 7.1 classic installer 64 bit iso I think the source code is shared with diskdrake? How reproducible: Have not tried
BTW, interestingly the partitioning also changed extended partition start so there is still only one partition outside it (the /boot/EFI). https://bugs.mageia.org/show_bug.cgi?id=22546#c17
This is confusing. Could the root be: > Previous system used mbr partition table, but i now chose to go for EFI. If the computer can do EFI, best to use it (and GPT) all round and forget about MBR. Is the BIOS set for 'compatability mode'? It looks as if you are using /dev/sdb (all of it?) for Mageia. If so, what has /dev/sda ? And how does the system boot? With EFI, the 'boot partition' is essential for EFI booting, and is a dedicated FAT partition called the 'EFI System Partiton', or ESP. That is what one talks about; its top level directory is \EFI . The ESP is conventionally mounted in Linux as /boot/efi, but /boot/EFI for Mageia (so that the top level EFI directory becomes /boot/EFI/EFI). > Deleted the separate /boot partition, created a /boot/EFI fat32 per default > as installer suggested = the ESP > then a new /boot ext4 partition Why? You did/do not need a separate partition to mount on /boot, which directory is usually an integral part of the root partion '/'. Can you please post the output of: # fdisk -l /dev/sda and # fdisk -l /dev/sdb (In reply to Morgan Leijström from comment #1) > BTW, interestingly the partitioning also changed extended partition > start so there is still only one partition outside it (the /boot/EFI). I do not understand this. Extended partitions do not exist with EFI/GPT.
CC: (none) => lewyssmithKeywords: (none) => NEEDINFO
Thank you for looking at this Confusing, yes, and EFI etc is not my cup of tea... Hmm now i dont remember why i think it really do use EFI for boot now but it was my intention to try and installer seem to have tried to play along. Anyhow, i upgraded from mga6 to 7 by doing fresh install and keeping /home. Therefor i did not want to repartition, so still using MBR -not using GPT. Maybe one or more of me/BIOS/GRUB/Installer got/is confused. Anyhow, the current problem that is visible is that the filesystem on /dev/sdb1 (/boot/EFI, FAT32) is larger than the partition. There is only one file in sdb1: /boot/EFI/EFI/mageia/grubx64.efi , 123 kiB. --- The system is from year 2011, possibly never touched the disk partitions on the SSD until now, only changes inside LVM (moved out /tmp and /var to other disk, resizing the rest), and added spinning disks as below. Previous fresh OS install was Mageia 4, using MBR, and partitioning as below except /boot/EFI. Still running on original SSD which of course grew too small for everytning. sda is 2TB spinning rust - a large drive for archiving isos and such, mounted /mnt/WDred sdb is an SSD, now holding: § sdb1 14MB , 123 kB FAT32 mounted as /boot/EFI (suggested by installer, i just made it smaller as i saw on first install attempt it contained very little.) § sdb2 extended container for § sdb5 ext4 200 MB mounted as /boot I did not try if Mageia 7 can boot on / even when it is in an encrypted LVM. § sdb6 an LUKS encrypted partition, used for LVM, containing: /, /home, swap sdc is also spinning rust now holding a LVM containing /tmp and /var --- $ sudo LC_ALL=C fdisk -l /dev/sda Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: WDC WD20EFRX-68E Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x293bc551 Device Boot Start End Sectors Size Id Type /dev/sda1 2048 3907028991 3907026944 1.8T 83 Linux $ sudo LC_ALL=C fdisk -l /dev/sdb Disk /dev/sdb: 223.6 GiB, 240057409536 bytes, 468862128 sectors Disk model: OCZ VERTEX-PLUS 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: dos Disk identifier: 0x000a8785 Device Boot Start End Sectors Size Id Type /dev/sdb1 * 2048 32129 30082 14.7M ef EFI (FAT-12/16/32) /dev/sdb2 34776 468857024 468822249 223.6G 5 Extended /dev/sdb5 34816 465884 431069 210.5M 83 Linux /dev/sdb6 471040 468857024 468385985 223.4G 83 Linux $ sudo LC_ALL=C fdisk -l /dev/sdc Disk /dev/sdc: 149.1 GiB, 160041885696 bytes, 312581808 sectors Disk model: TOSHIBA MK1652GS 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: dos Disk identifier: 0x00082046 Device Boot Start End Sectors Size Id Type /dev/sdc1 2048 312576704 312574657 149G 8e Linux LVM
Summary: Installer partition stage created strange /boot/EFI partition => Installer partition stage created /boot/EFI filesystem larger than partition + utf8Keywords: NEEDINFO => (none)
Could you attach the /root/drakx/report.bug.xz file from your Mageia 7 system.
CC: (none) => mageia
Created attachment 11306 [details] report.bug.xz
Thank you Martin for jumping in (pre-empting my assignment!) ----------------------------------------------------------- Thank you Morgan for all the information. We can certainly discount all discs except sdb. Can you confirm that your BIOS is MBR-oriented? Probably so, since you have always lived with all the discs MBR. In spite of the problem you report, can you say that the system boots and runs OK? This problem has almost certainly arisen from mixing BIOS/MBR and EFI - especially the latter with MBR rather than GPT. I cannot comment on trying to have an ESP (what you call /boot/EFI) on an MBR disc, beyond saying it looks like asking for trouble. > Maybe one or more of me/BIOS/GRUB/Installer got/is confused. Neatly summarised. Can you remember on what device you asked for Grub2 to be installed during bootloader configuration? Normally Grub sits on the disc's MBR, outside other partitions; but /dev/sdb1, created as the ESP when you chose EFI booting, is shown as the boot partition; which works when you ask at bootloader installation for Grub to be put specifically on a partition['s boot sector]. > There is only one file in sdb1: /boot/EFI/EFI/mageia/grubx64.efi This is quite correct for a real EFI/GPT setup. > sdb6 an LUKS encrypted partition, used for LVM, containing: / ... I see now why you created a separate conventional partition to mount on /boot; perhaps booting would not work in LUKS+LVM ? Can you try: # efibootmgr and if it works, post its output. If it does not exist or work, just say so. ---------------------------------------------------------------- > the current problem that is visible is that the filesystem on > /dev/sdb1 (/boot/EFI, FAT32) is larger than the partition This is not true: > Device Boot Start End Sectors Size Id Type > /dev/sdb1 * 2048 32129 30082 14.7M ef EFI (FAT-12/16/32) > Both diskdrake and Gparted report sdb1 to be 14MB as i set it. The actual problem seemsto be that 'df' shows the wrong partiton size; also GParted reports strange things when you unmount & check the partition. I am assigning this to the ISO team (CC Mageia tools), for their expertise on the installer, where Grub might be, whether any EFI element is involved in the booting, and partitioning in general. Please re-assign if appropriate.
In the report.bug.xz I see ================================= * starting step `doPartitionDisks' * fdisk before: Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: WDC WD20EFRX-68E Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x293bc551 Device Boot Start End Sectors Size Id Type /dev/sda1 2048 3907028991 3907026944 1.8T 83 Linux Disk /dev/sdb: 223.6 GiB, 240057409536 bytes, 468862128 sectors Disk model: OCZ VERTEX-PLUS 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: dos Disk identifier: 0x000a8785 Device Boot Start End Sectors Size Id Type /dev/sdb1 * 2048 32129 30082 14.7M ef EFI (FAT-12/16/32) /dev/sdb2 34776 468857024 468822249 223.6G 5 Extended /dev/sdb5 34816 465884 431069 210.5M 83 Linux /dev/sdb6 471040 468857024 468385985 223.4G 83 Linux ================================== So did you repartition the disk and format the ESP before running the installer?
" The actual problem seems to be that 'df' shows the wrong partiton size; also GParted reports strange things when you unmount & check the partition." And also fsck fail Question is what is wrong... --- "So did you repartition the disk and format the ESP before running the installer?" I forgot to say this was the second install try. I have forgotten why i was not satisfied with the first run, but sdb{1,2,5} was made/changed with mga7.1 disk that day. I did not use any other tool than the installer. I may have used another partitioner last time i made a fresh install, that was Mageia 4... --- [root@svarten morgan]# efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0002,0001 Boot0000* mageia Boot0001 CD/DVD Drive Boot0002* Hard Drive ---- This is my workstation, so personally i just want to feel it is reliable. Of we can hunt down a bug that may affect others, good. - But just no hazardous debugging please... The syslog message disturbs me: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. - but fsck fail as i reported... Other tools to try? For multiboot users the utf8 warning may be significant!
I can boot on a USB stick with http://www.system-rescue-cd.org/ for checking something, if that may give anything.
"can you say that the system boots and runs OK?" YES :) And for over two weeks now. I was just too busy to bug this before.
A thought: Is it possible there somehow exist both MBR and GPT tables now, with contradicting information, and different programs select differently where they get their info from...?
Without the first installer log, we can't be sure, but my guess at what happened is that you created and formatted the ESP with the original suggested size. You then resized the partition, but didn't reformat it. So you still have a filesystem that occupies the original partition size. The filesystem size is stored on the disk in the filesystem metadata, so does not change if you change the partition table. To fix, make a backup of /boot/EFI, unmount it, use diskdrake or command line tools to reformat the partition (this should automatically use the new partition size), remount, then copy back the files. To be safe, make a backup of your new /boot partition before you start. I have seen the message about FAT filesystems not being properly unmounted for years. There's a flag in the FAT metadata that should be set when the volume is unmounted, and it isn't. I've never seen any problems caused by this, so have never taken the time to investigate why.
(In reply to Martin Whitaker from comment #12) > Without the first installer log, we can't be sure, but my guess at what > happened is that you created and formatted the ESP with the original > suggested size. You then resized the partition, but didn't reformat it. So > you still have a filesystem that occupies the original partition size. The > filesystem size is stored on the disk in the filesystem metadata, so does > not change if you change the partition table. This looks very likely; and thank you for the comprehensive analysis. (In reply to Morgan Leijström from comment #9) > I can boot on a USB stick with http://www.system-rescue-cd.org/ for checking > something, if that may give anything. Or you could use the Mageia Classic ISO USB in 'Rescue' mode. But Martin has suggested what to do.
Thank you Martin, that is a perfect analysis i believe - i remember now: The default size of /boot/EFI partition left too little for /boot partition which i think i need, and the only way to get space was to make /boot/EFI smaller. So myself/diskdrake forgot to format it. Should I open a bug for that? [root@svarten morgan]# su - [root@svarten ~]# cp -a /boot/EFI . 10:52:17 diskdrake[25301]: running: umount /boot/EFI 10:52:17 diskdrake[25301]: modified file /etc/mtab 10:52:21 diskdrake[25301]: running: mkdosfs -F 32 /dev/sdb1 10:52:21 diskdrake[25301]: running: blkid -o udev -p /dev/sdb1 10:53:19 diskdrake[25301]: created directory /boot/EFI (and parents if necessary) 10:53:19 diskdrake[25301]: running: mount -t vfat UUID=FC5C-861E /boot/EFI -o check=relaxed [root@svarten ~]# ls /boot/EFI [root@svarten ~]# pwd /root [root@svarten ~]# cp -a EFI/EFI /boot/EFI [root@svarten ~]# ls -l /boot/EFI/EFI/mageia/ totalt 121 -rwxr-xr-x 1 root root 123392 sep 23 01:58 grubx64.efi* [root@svarten ~]# umount /boot/EFI [root@svarten ~]# fsck /dev/sdb1 fsck från util-linux 2.33.2 fsck.fat 4.1 (2017-01-24) Warning: Filesystem is FAT32 according to fat_length and fat32_length fields, but has only 29586 clusters, less than the required minimum of 65525. This may lead to problems on some systems. /dev/sdb1: 3 files, 244/29586 clusters [root@svarten ~]# mount /dev/sdb1 [root@svarten ~]# - So i should optimally format it FAT16 instead. So i formatted it again using diskdrake selecting FAT16. As designed, esp flag then did not get set, so i used GParted to do that. Put again back the contents, checked, and on question removed dirty bit. [root@svarten ~]# fsck /dev/sdb1 fsck från util-linux 2.33.2 fsck.fat 4.1 (2017-01-24) 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. 1) Remove dirty bit 2) No action ? 1 Perform changes ? (y/n) y /dev/sdb1: 3 files, 63/7495 clusters [root@svarten ~]# Still using utf-8 though, diskdrake wrote in fstab. Why did we opt for utf-8? (which kernel suggest we should not) Rebooting to see if it works...
Hurray! § Booting § No complaint of not properly unmounted /boot/EFI § df list size correctly. Small issues to think about: A) Why did /boot/EFI not get reformatted? (Me or diskdrake - try later) B) For small ESP, diskdrake should either limit min size (is it 32M for FAT32?) or switch to FAT16 or use FAT32 with smaller cluster size. What is most compatible? C) Why do installer choose utf-8 in ESP? A quick web search give that iso8859-1 seem more used but i could be wrong. okt 09 11:44:43 svarten kernel: FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Whiteboard: (none) => EFI, ESPSummary: Installer partition stage created /boot/EFI filesystem larger than partition + utf8 => Installer/diskdrake creating /boot/EFI could be improved, see comment 15Severity: normal => enhancement
> Thank you Martin, that is a perfect analysis i believe You really did mess around with the partitioning of sdb1, which was the root of your troubles. Mixing EFI/GPT and MBR just complicated the issue.. (In reply to Morgan Leijström from comment #15) > § Booting > § No complaint of not properly unmounted /boot/EFI > § df list size correctly. So I think the bug can be closed. I reverted the title to the original problem. > Why did /boot/EFI not get reformatted? It depends how you went through the installation. Did you say "Use existing partitions"? If so, you can indicate re-formatting of the partitions(s) you want done. FAT32 is common for the ESP, even if smaller FATs may be eligible; for it is typically just 2-300 megabytes, even though it seldom needs to be that big. The ISO build/Installer people may consider your suggestions B & C for the ESP next time round. Remember you are the first person to complain on this front, and we has been doing EFI since Mageia 4. You may wish to open a new 'enhancement request' bug for these two aspects, for Installer.
Resolution: (none) => FIXEDStatus: NEW => RESOLVEDSummary: Installer/diskdrake creating /boot/EFI could be improved, see comment 15 => Installer partition stage created /boot/EFI filesystem giving wrong result from df and other partition programs
Bug 25549 - UEFI ESP partitions type, size, filesystem encoding, check