You are not logged in.
Note: I originally posted this at https://bbs.archlinux.org/viewtopic.php … 2#p1250922 but I realise that it is not really the same issue. It is really a new issue caused by that issue. So I'm posting it as a new issue. I hope this is acceptable. I think I should have done this in the first place.
I just had an unclean shut down where I was forced to power off by holding the power button. On reboot, I noticed that fsck could/did not correct all of the filesystem errors. (It corrected most as most were on ext4 and it replayed the journals, cleaned up orphans etc.) In particular, it did/could not repair an error to do with the EFI partition.
From the journal, I have:
Maw 28 22:06:13 MyComputer systemd-fsck[646]: dosfsck 3.0.16, 01 Mar 2013, FAT32, LFN
Maw 28 22:06:13 MyComputer systemd-fsck[646]: Unfinished long file name "楦瘭慦⁴†<U+FFFF><U+FFFF><U+FFFF><U+FFFF>ƕ䆔<U+FFFF><U+FFFF>".
Maw 28 22:06:13 MyComputer systemd-fsck[646]: (Start may have been overwritten by EFI)
Maw 28 22:06:13 MyComputer systemd-fsck[646]: Not auto-correcting this.
Maw 28 22:06:13 MyComputer systemd-fsck[646]: /dev/sda1: 56 files, 89964/261628 clusters
Does anybody know what this means or what I should do about it? That is, I know that it is a file system error which fsck will not correct in the cautious mode it uses automatically during boot but why does it think that EFI may have overwritten it? And what should be done about it?
I've tried googling bits of this but I cannot get any relevant results.
Last edited by cfr (2013-03-29 16:23:47)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
So I unmounted the ESP and tried dosfsck -a. Unsurprisingly, this refuses to auto-correct just as it does on boot. So I ran dosfsck -r to try to get more information/options:
# dosfsck -r /dev/sda1
dosfsck 3.0.16, 01 Mar 2013, FAT32, LFN
Unfinished long file name "楦瘭慦⁴†ƕ䆔".
(Start may have been overwritten by EFI)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name EFI)
? ^C
I'm wondering what this could belong to. Would this be associated with a file on disk or is it something to do with the information about the filesystem itself?
$ ls -laRh /boot/efi/
/boot/efi/:
total 350M
drwxr-xr-x 3 root root 4.0K Ion 1 1970 ./
drwxr-xr-x 6 root root 4.0K Maw 23 04:47 ../
drwxr-xr-x 5 root root 4.0K Maw 23 22:08 EFI/
-rwxr-xr-x 1 root root 350M Tach 18 19:08 systemrescuecd-x86-3.1.1.iso*
/boot/efi/EFI:
total 20K
drwxr-xr-x 5 root root 4.0K Maw 23 22:08 ./
drwxr-xr-x 3 root root 4.0K Ion 1 1970 ../
drwxr-xr-x 2 root root 4.0K Maw 20 2012 arch_grub/
drwxr-xr-x 4 root root 4.0K Maw 28 23:01 arch_refind/
drwxr-xr-x 2 root root 4.0K Rha 31 02:13 boot/
/boot/efi/EFI/arch_grub:
total 128K
drwxr-xr-x 2 root root 4.0K Maw 20 2012 ./
drwxr-xr-x 5 root root 4.0K Maw 23 22:08 ../
-rwxr-xr-x 1 root root 118K Tach 9 22:56 grubx64.efi*
/boot/efi/EFI/arch_refind:
total 192K
drwxr-xr-x 4 root root 4.0K Maw 28 23:01 ./
drwxr-xr-x 5 root root 4.0K Maw 23 22:08 ../
-rwxr-xr-x 1 root root 2.0K Maw 28 23:00 cfr.conf*
drwxr-xr-x 2 root root 4.0K Maw 23 21:45 drivers_x64/
drwxr-xr-x 2 root root 4.0K Maw 23 11:37 icons/
-rwxr-xr-x 1 root root 18K Maw 26 03:06 refind.conf*
-rwxr-xr-x 1 root root 152K Maw 23 11:37 refind_x64.efi*
/boot/efi/EFI/arch_refind/drivers_x64:
total 40K
drwxr-xr-x 2 root root 4.0K Maw 23 21:45 ./
drwxr-xr-x 4 root root 4.0K Maw 28 23:01 ../
-rwxr-xr-x 1 root root 32K Maw 23 21:45 ext4_x64.efi*
/boot/efi/EFI/arch_refind/icons:
total 1.2M
drwxr-xr-x 2 root root 4.0K Maw 23 11:37 ./
drwxr-xr-x 4 root root 4.0K Maw 28 23:01 ../
-rwxr-xr-x 1 root root 4.3K Maw 23 11:37 arrow_left.icns*
-rwxr-xr-x 1 root root 4.3K Maw 23 11:37 arrow_right.icns*
-rwxr-xr-x 1 root root 28K Maw 23 11:37 boot_linux.icns*
-rwxr-xr-x 1 root root 22K Maw 23 11:37 boot_win.icns*
-rwxr-xr-x 1 root root 5.4K Maw 23 11:37 func_about.icns*
-rwxr-xr-x 1 root root 6.7K Maw 23 11:37 func_exit.icns*
-rwxr-xr-x 1 root root 6.8K Maw 23 11:37 func_reset.icns*
-rwxr-xr-x 1 root root 7.0K Maw 23 11:37 func_shutdown.icns*
-rwxr-xr-x 1 root root 25K Maw 23 11:37 os_altlinux.icns*
-rwxr-xr-x 1 root root 33K Maw 23 11:37 os_arch.icns*
-rwxr-xr-x 1 root root 43K Maw 23 11:37 os_centos.icns*
-rwxr-xr-x 1 root root 38K Maw 23 11:37 os_debian.icns*
-rwxr-xr-x 1 root root 37K Maw 23 11:37 os_ecomstation.icns*
-rwxr-xr-x 1 root root 59K Maw 23 11:37 os_fatdog.icns*
-rwxr-xr-x 1 root root 29K Maw 23 11:37 os_fedora.icns*
-rwxr-xr-x 1 root root 42K Maw 23 11:37 os_freebsd.icns*
-rwxr-xr-x 1 root root 26K Maw 23 11:37 os_freedos.icns*
-rwxr-xr-x 1 root root 37K Maw 23 11:37 os_gentoo.icns*
-rwxr-xr-x 1 root root 33K Maw 23 11:37 os_gummiboot.icns*
-rwxr-xr-x 1 root root 37K Maw 23 11:37 os_haiku.icns*
-rwxr-xr-x 1 root root 33K Maw 23 11:37 os_hwtest.icns*
-rwxr-xr-x 1 root root 39K Maw 23 11:37 os_legacy.icns*
-rwxr-xr-x 1 root root 28K Maw 23 11:37 os_linux.icns*
-rwxr-xr-x 1 root root 36K Maw 23 11:37 os_linuxmint.icns*
-rwxr-xr-x 1 root root 27K Maw 23 11:37 os_mac.icns*
-rwxr-xr-x 1 root root 23K Maw 23 11:37 os_mandriva.icns*
-rwxr-xr-x 1 root root 29K Maw 23 11:37 os_netbsd.icns*
-rwxr-xr-x 1 root root 36K Maw 23 11:37 os_openbsd.icns*
-rwxr-xr-x 1 root root 34K Maw 23 11:37 os_redhat.icns*
-rwxr-xr-x 1 root root 29K Maw 23 11:37 os_refit.icns*
-rwxr-xr-x 1 root root 45K Maw 23 11:37 os_slackware.icns*
-rwxr-xr-x 1 root root 41K Maw 23 11:37 os_suse.icns*
-rwxr-xr-x 1 root root 27K Maw 23 11:37 os_ubuntu.icns*
-rwxr-xr-x 1 root root 30K Maw 23 11:37 os_unknown.icns*
-rwxr-xr-x 1 root root 40K Maw 23 11:37 os_win.icns*
-rwxr-xr-x 1 root root 7.0K Maw 23 11:37 tool_apple_rescue.icns*
-rwxr-xr-x 1 root root 6.0K Maw 23 11:37 tool_mok_tool.icns*
-rwxr-xr-x 1 root root 7.7K Maw 23 11:37 tool_part.icns*
-rwxr-xr-x 1 root root 6.6K Maw 23 11:37 tool_shell.icns*
-rwxr-xr-x 1 root root 18K Maw 23 11:37 transparent.icns*
-rwxr-xr-x 1 root root 3.4K Maw 23 11:37 vol_external.icns*
-rwxr-xr-x 1 root root 3.5K Maw 23 11:37 vol_internal.icns*
-rwxr-xr-x 1 root root 3.7K Maw 23 11:37 vol_optical.icns*
/boot/efi/EFI/boot:
total 128K
drwxr-xr-x 2 root root 4.0K Rha 31 02:13 ./
drwxr-xr-x 5 root root 4.0K Maw 23 22:08 ../
-rwxr-xr-x 1 root root 118K Tach 9 22:56 bootx64.efi*
Why is the root of the filesystem shown with a date of 1970? Is that normal? That is, is this because it is fat 32 rather than ext4 or is that a sign of something wrong?
EDIT: When it says it may have been overwritten by EFI, does it mean the directory EFI may have overwritten part of the name of whatever it is? I kept thinking it meant UEFI and I couldn't for the life of me figure out how dosfsck could even know that the partition had anything to do with EFI since it is just a fat 32 filesystem and dosfsck is not likely to be EFI aware, that I know of. [Not that this gives me any more idea how to resolve the issue. Just makes the issue less mysterious in one respect.]
Last edited by cfr (2013-03-29 02:47:11)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I don't have many of your answers, but I'll share the relevant parts that I see on my system using the same command you did:
sidney@sid-max-arch64 ~ $ ls -laRh /boot/efi/
/boot/efi/:
total 845K
drwxr-xr-x 4 root root 4.0K Dec 31 1969 ./
drwxr-xr-x 4 root root 1.0K Mar 21 14:24 ../
drwxr-xr-x 6 root root 4.0K Mar 28 11:28 EFI/
-rwxr-xr-x 1 root root 828K Mar 25 10:17 shellx64.efi*
drwxr-xr-x 4 root root 4.0K Feb 26 00:01 .Trash-0/
-rwxr-xr-x 1 root root 2 Feb 19 23:12 $UpgDrv$*
/boot/efi/EFI:
total 24K
drwxr-xr-x 6 root root 4.0K Mar 28 11:28 ./
drwxr-xr-x 4 root root 4.0K Dec 31 1969 ../
drwxr-xr-x 2 root root 4.0K Mar 26 10:47 arch/
drwxr-xr-x 3 root root 4.0K Mar 26 15:12 Boot/
drwxr-xr-x 3 root root 4.0K Feb 19 16:36 Microsoft/
drwxr-xr-x 3 root root 4.0K Mar 25 10:22 refind/
If you followed the recommendations in the beginner's guide, then you set the EFI partion mount with the only option being 'noatime', which is what I have done. I'm seeing 1969 in my system because I think I may have installed fresh awhile after you did perhaps. I wonder if the 'noatime' setting is the reason for the 1969 and 1970 dates? Maybe the default access time starts at December 1969 for some reason and since access time writing has been disabled the time stamps only change when something is modified. Of course, in my /etc/fstab I also have file checking disabled on that partition.
[EDIT] Here is what I get after I deleted some files and directories from the /boot/efi/ and /boot/efi/EFI/, thus modifying things:
sidney@sid-max-arch64 ~ $ ls -laRh /boot/efi/
/boot/efi/:
total 841K
drwxr-xr-x 3 root root 4.0K Mar 28 22:49 ./
drwxr-xr-x 4 root root 1.0K Mar 21 14:24 ../
drwxr-xr-x 6 root root 4.0K Mar 28 11:28 EFI/
-rwxr-xr-x 1 root root 828K Mar 25 10:17 shellx64.efi*
-rwxr-xr-x 1 root root 2 Feb 19 23:12 $UpgDrv$*
/boot/efi/EFI:
total 24K
drwxr-xr-x 6 root root 4.0K Mar 28 11:28 ./
drwxr-xr-x 3 root root 4.0K Mar 28 22:49 ../
drwxr-xr-x 2 root root 4.0K Mar 28 22:48 arch/
drwxr-xr-x 3 root root 4.0K Mar 28 22:49 Boot/
drwxr-xr-x 3 root root 4.0K Feb 19 16:36 Microsoft/
drwxr-xr-x 3 root root 4.0K Mar 28 22:49 refind/
Last edited by sidneyk (2013-03-29 03:55:19)
Offline
Yeah, I definitely do not get a really old year like that for my ESP.
I have noticed though that when I install syslinux with the syslinux-install_update script, setting the boot flag on the ESP makes things go a bit crazy. It doesn't result in the same error, but it does result in a whole bunch of inconsistencies that dosfsck cannot repair automatically. So if I simply run dosfsck interactively (-r) then revert to what it was before (I figure it was consistent before things go wrong), things seem all good. Also the boot flag stays set as well, though the ESP is marked in parted as bootable anyway, and that is how it is identified.
But I really am curious as to what this "long filename" is that it is referring to. The contents of your ESP seem normal...
Offline
Yeah, I definitely do not get a really old year like that for my ESP.
I have noticed though that when I install syslinux with the syslinux-install_update script, setting the boot flag on the ESP makes things go a bit crazy. It doesn't result in the same error, but it does result in a whole bunch of inconsistencies that dosfsck cannot repair automatically. So if I simply run dosfsck interactively (-r) then revert to what it was before (I figure it was consistent before things go wrong), things seem all good. Also the boot flag stays set as well, though the ESP is marked in parted as bootable anyway, and that is how it is identified.
But I really am curious as to what this "long filename" is that it is referring to. The contents of your ESP seem normal...
That was the part I wasn't sure of, but in the DOS / Windows world, it refers to a file name that is longer than the 8.3 DOS standard and may include spaces. Is that dosfsck you're talking about expecting 8.3 file names? Other than that, I don't really know.
Last edited by sidneyk (2013-03-29 04:50:59)
Offline
Thanks for all the replies.
I don't think it is objecting to anything on the partition as it lists everything else perfectly normally. Certainly nothing on my ESP has a space in the file name.
@WonderWoofy,
I don't quite understand what you mean about reverting to how it was before. How do I tell it to do that? I understand the -r thing. I'm just not sure which of those options will put it back correctly. Obviously option 2 is the do-nothing option so that won't fix anything. Option 3 doesn't seem right. EFI is EFI is EFI. So is option 1 the one I want?
Incidentally, there should be nothing on my ESP with a file name with characters like that in! I don't think there should be anything on the disk but I wouldn't want to swear to that one.
Last edited by cfr (2013-03-29 05:08:08)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Are you the one (cfr) that was using FAT16? The info I found suggests that FAT16 is limited to 8.3 file names and FAT32 can be up to 255 characters. Any info I found on dosfsck indicates that it is long file name aware. If you're not on FAT16, then it sounds like a long file name, i.e.>8.3, got it's bits corrupted somehow and now doesn't match the info in the FAT.
[EDIT] I think dosfsck is referring to EFI as part of a file name, in this case, and is saying that the short file name 'EFI' has overwritten things. I would probably choose option 3 and see if it works, worst case, you'll have to rebuild things in the EFI partition.
Last edited by sidneyk (2013-03-29 05:24:32)
Offline
This is fat 32. I was using fat 16 but I discovered it is OK with fat 32 with a sufficiently large ESP (i.e. 512M or bigger.)
The thing is, everything on there looks like I'd expect. So what can the fragment be a fragment of?
Last edited by cfr (2013-03-29 05:20:49)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
This is fat 32. I was using fat 16 but I discovered it is OK with fat 32 with a sufficiently large ESP (i.e. 512M or bigger.)
The thing is, everything on there looks like I'd expect. So what can the fragment be a fragment of?
If you had a dirty shutdown it could be that the file allocation table (FAT) got corrupted.
Offline
Since it doesn't appear that you are dual booting with Windows, then if it were me, if you are able to boot then I would do so and after bootup, just umount the EFI and repartition and reformat and rebuild it to be sure you have everything pristine and, hopefully, without errors. Be sure to double-check if any UUID changes or not.
Last edited by sidneyk (2013-03-29 05:40:05)
Offline
Since it doesn't appear that you are dual booting with Windows, then if it were me, if you are able to boot then I would do so and after bootup, just umount the EFI and repartition and reformat and rebuild it to be sure you have everything pristine and, hopefully, without errors. Be sure to double-check if any UUID changes or not.
This is what I would do too... simply out of fear that the corruption might be worse than it appears.
Offline
Why is the root of the filesystem shown with a date of 1970? Is that normal? That is, is this because it is fat 32 rather than ext4 or is that a sign of something wrong?
Hi, this is the UNIX epoch, or UNIX time, starting midnight January 1 1970 UTC/GMT.
1364553834 is the 'current' epoch in seconds started counting 1-1-1970!
For people still not understanding what the heck I talk about see this site.
Oh and cfr, nothing wrong there.)^^
Offline
sidneyk wrote:Since it doesn't appear that you are dual booting with Windows, then if it were me, if you are able to boot then I would do so and after bootup, just umount the EFI and repartition and reformat and rebuild it to be sure you have everything pristine and, hopefully, without errors. Be sure to double-check if any UUID changes or not.
This is what I would do too... simply out of fear that the corruption might be worse than it appears.
Thanks to both. This was my inclination, too, but I was not quite sure - especially since it is fat formatted and I'm less confident dealing with non-journalled file systems. (Too long on a Mac, I guess, with everything journalled!)
Incidentally, this has made me realise one advantage of a separate /boot and EFI. It lets you have the minimum possible on a partition with a non-journalled file system. I realise that's probably a fairly minor benefit but on my machine at the moment, it carries at least some weight!
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Incidentally, this has made me realise one advantage of a separate /boot and EFI. It lets you have the minimum possible on a partition with a non-journalled file system. I realise that's probably a fairly minor benefit but on my machine at the moment, it carries at least some weight!
Are you speaking of a separate /, /boot, and /boot/efi? If I remember correctly, you are an ext4 user. So I can understand trying to have as much as possible on /boot instead of /boot/efi, but I see no reason to split /boot from /. That is, with (I think) every bootloader these days, reading from ext4 is a universal as reading from ext2 has been historically. So splitting those two, in my mind, has no advantage.
Offline
cfr wrote:Incidentally, this has made me realise one advantage of a separate /boot and EFI. It lets you have the minimum possible on a partition with a non-journalled file system. I realise that's probably a fairly minor benefit but on my machine at the moment, it carries at least some weight!
Are you speaking of a separate /, /boot, and /boot/efi? If I remember correctly, you are an ext4 user. So I can understand trying to have as much as possible on /boot instead of /boot/efi, but I see no reason to split /boot from /. That is, with (I think) every bootloader these days, reading from ext4 is a universal as reading from ext2 has been historically. So splitting those two, in my mind, has no advantage.
/ is encrypted. /boot is also ext4 but outside the LUKS container. So it has the advantage of working!
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I discovered that the corruption was not, as I thought, an effect of the unclean shutdown. Perhaps it was the result of an earlier unclean shutdown. I guess I never noticed the error before because those messages scroll by so fast and I wasn't looking for corruption...
Anyway, I redid it and just hope I remembered to update everything that needs updating! As far as I can tell, that's fstab and grub.cfg. refind doesn't seem to have the UUID of the EFI partition in any of the config files I'm using.
Thanks again.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Don't forget that your efibootmgr entries are based on the old UUID of the ESP. So if you have an eibootmgr entry for your grub and refind, you need to recreate those (and it is probably wise to delete the old ones as well).
Offline
My comments:
Clearly there's been filesystem corruption, which dosfsck can't handle automatically. These things happen. To recover, I recommend first backing up (via tar, for instance), then using "dosfsck -r" and letting it fix things automatically. If this works, then great. If not, then create a fresh FAT filesystem and restore everything to it. (See below for one more thing you might want to try, though.)
As qinohe says, the 1969/1970 thing is the default date for Linux/Unix. I don't know the FAT internals very well, but my guess is that either FAT doesn't support a creation date or mkdosfs doesn't set it. The difference between 1969 and 1970 is almost certainly a time zone issue, since the dates are either December 31, 1969 or January 1, 1970. FWIW, my system also shows a date of December 31, 1969 for my ESP. (I'm in Rhode Island, USA, so it would have been a few hours before midnight 1969/1970 here when it became 1970 in Greenwich, England.)
The FAT size (12, 16, or 32) and 8.3 vs. long filenames are orthogonal issues -- that is, you can access any FAT size using either 8.3 or long filenames. In Linux, the FAT size is is detected automatically by the kernel's FAT driver and is set at creation time by mkdosfs (either automatically or as specified by -F). The filename length is handled by the filesystem type you use: "vfat" for long filenames or "msdos" for 8.3 filenames. You'll normally want to access an ESP with the "vfat" filesystem driver, since some critical directory names and filenames ("Microsoft", "archlinux", "refind_x64.efi", "*.icns", "*.conf", "gummiboot.efi", etc.) don't fit within the 8.3 filename constraints. You might, though, want to try mounting your ESP with the "msdos" driver before erasing it, if that's necessary, to see if there are any files you can access that way but not via the long filenames of the "vfat" driver.
Offline
I have a separate /boot partition setup because it seemed like a good idea with UEFI. I don't have any encryption setup or any LVM or RAID going on and use ext4 for my Linux partitions. I have systemd setup to automatically copy over updated kernels and initramfs to the /boot/efi/EFI/arch/ directory. I went with a separate /boot so that I could maybe encrypt the rest later, after I learn more about it. That way, since the kernel has the capability, the firmware is reading the EFI partition and finding the rEFInd executable, my default choice, which then starts to load the kernel and initramfs, all before the Linux system even mounts the EFI. I also have automatic checking turned off on the EFI partition in my fstab because I don't want to chance hosing my Windows boot loader which is also on the EFI. Everything works nice and smooth and boots faster than MBR booting did. I have to look back and see if I had a particular reason for not just formatting the /boot partition as FAT32.
Last edited by sidneyk (2013-03-29 17:05:28)
Offline
Don't forget that your efibootmgr entries are based on the old UUID of the ESP. So if you have an eibootmgr entry for your grub and refind, you need to recreate those (and it is probably wise to delete the old ones as well).
I checked and efibootmgr is not using the UUID but the PARTUUID which has not altered.
@srs5694,
Thanks very much. Unfortunately, I'd already redone the file system before getting this so it is too late to try any of your suggestions.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I have a separate /boot partition setup because it seemed like a good idea with UEFI. ... I have systemd setup to automatically copy over updated kernels and initramfs to the /boot/efi/EFI/arch/ directory.... the firmware is reading the EFI partition and finding the rEFInd executable,
If you're using rEFInd as your boot manager, it's likely to be more efficient to do one of three things:
Convert your /boot partition to use FAT.
Copy files from /boot to /boot/efi, delete the duplicate kernels from /boot/efi/EFI/arch, remove your /boot partition (or at least delete its /etc/fstab entry), and reconfigure /etc/fstab to mount the ESP at /boot.
Install the ext4fs driver for EFI that comes with rEFInd.
Any of these approaches will enable rEFInd to read your kernel, initrd, and refind_linux.conf files directly from /boot, obviating the need to copy those files to /boot/efi/EFI/arch. This will simplify configuration and will help protect against potential partition-full conditions. (/boot could still fill up, of course, but as it is now, you're vulnerable both to /boot filling up and /boot/efi filling up.)
my default choice, which then starts to load the kernel and initramfs, all before the Linux system even mounts the EFI.
That's a logical necessity no matter how you boot -- the kernel must load before actions like Linux mounting a filesystem can occur.
Offline
sidneyk wrote:I have a separate /boot partition setup because it seemed like a good idea with UEFI. ... I have systemd setup to automatically copy over updated kernels and initramfs to the /boot/efi/EFI/arch/ directory.... the firmware is reading the EFI partition and finding the rEFInd executable,
If you're using rEFInd as your boot manager, it's likely to be more efficient to do one of three things:
Convert your /boot partition to use FAT.
Copy files from /boot to /boot/efi, delete the duplicate kernels from /boot/efi/EFI/arch, remove your /boot partition (or at least delete its /etc/fstab entry), and reconfigure /etc/fstab to mount the ESP at /boot.
Install the ext4fs driver for EFI that comes with rEFInd.
Any of these approaches will enable rEFInd to read your kernel, initrd, and refind_linux.conf files directly from /boot, obviating the need to copy those files to /boot/efi/EFI/arch. This will simplify configuration and will help protect against potential partition-full conditions. (/boot could still fill up, of course, but as it is now, you're vulnerable both to /boot filling up and /boot/efi filling up.)
my default choice, which then starts to load the kernel and initramfs, all before the Linux system even mounts the EFI.
That's a logical necessity no matter how you boot -- the kernel must load before actions like Linux mounting a filesystem can occur.
Yeah, at the time, I just followed the Arch Beginner's Guide which walks through a rEFInd setup as I described, since I wasn't too familiar with UEFI then. I find the setup easy enough with the systemd service and path units created. I also was trying to preserve easier access to the Ubuntu partition, which I have now eliminated. Even with both in there and Windows stuff, I was only consuming around half, if that, of the 300MB EFI partition. Now, with only Arch, rEFInd, Windows 7, and a EFI shell and backup boot method, I have plenty of space. Arch, of course, by default always just overwrites the previous kernel and initramfs with any updated versions because of the fact that they are always, at least currently, named the same, so even with the copying, I only ever have 1 set of Arch kernel and initramfs on the EFI. I agree that with my current setup with just Windows 7 and Arch, the easiest thing, if nothing else stops it, would be to convert my current /boot partition to FAT32 and mount EFI at /boot and get rid of the systemd services and adjust the rEFInd configuration to point at /boot or get rid of the /boot partition altogether and just mount EFI at /boot.
As far as that last bit, I was just pointing out that fact that the kernel must load before anything Linux is happening, in particular, the mounting of the EFI to wherever it's mounted. I was trying to highlight the fact and distinction that first, the EFI firmware is in control and loads the default boot manager option of rEFInd, then rEFInd takes over and starts the kernel and initramfs (if chosen), then the kernel and initramfs do their thing, all before the final Linux system is in control. The EFI may well be getting mounted initially with the initramfs, I'd have to check, but it's final status is set when the running linux system gains control.
It seems to me, that the only reason for mounting the EFI at all, particularly if you mount it at /boot or have auto copying setup to a different location, is just for the ability to read and write the kernel and initramfs when changes occur. Most of the time it's not being used for anything within the linux system, since /boot is only used (within the linux system and traditionally) to store the current kernel and initramfs and previously the boot loader (or parts of it). It's trivial to mount the /EFI just so you don't have to remember to do it manually to make changes. I'm booting the kernel from the EFI via the firmware via rEFInd, so I wouldn't even need a /boot partition or /boot directory at all, if it wasn't required to exist by the linux system.
Thanks for your clarifications. It all helps to further my understanding of the UEFI boot process and how it relates to Linux and such.
Last edited by sidneyk (2013-03-31 03:43:01)
Offline
Yeah, at the time, I just followed the Arch Beginner's Guide which walks through a rEFInd setup as I described, since I wasn't too familiar with UEFI then.
For the most part, the Arch wikis seem to be reasonable; but IMHO a setup that relies on manual copying of the kernel to the ESP, or even automated copying via a systemd script, is overly complex and is likely to be more trouble-prone than the alternatives.
As far as that last bit, I was just pointing out that fact that the kernel must load before anything Linux is happening, in particular, the mounting of the EFI to wherever it's mounted. I was trying to highlight the fact and distinction that first, the EFI firmware is in control and loads the default boot manager option of rEFInd, then rEFInd takes over and starts the kernel and initramfs (if chosen), then the kernel and initramfs do their thing, all before the final Linux system is in control. The EFI may well be getting mounted initially with the initramfs, I'd have to check, but it's final status is set when the running linux system gains control.
You're quite correct in this summary of what happens as the system boots.
It seems to me, that the only reason for mounting the EFI at all, particularly if you mount it at /boot or have auto copying setup to a different location, is just for the ability to read and write the kernel and initramfs when changes occur. Most of the time it's not being used for anything within the linux system, since /boot is only used (within the linux system and traditionally) to store the current kernel and initramfs and previously the boot loader (or parts of it). It's trivial to mount the /EFI just so you don't have to remember to do it manually to make changes. I'm booting the kernel from the EFI via the firmware via rEFInd, so I wouldn't even need a /boot partition or /boot directory at all, if it wasn't required to exist by the linux system.
You're right that neither the ESP nor /boot (if it's a separate partition) needs to be mounted most of the time. Most systems do keep them permanently mounted just because that reduces the odds of a screw-up like accidentally installing a new kernel without first mounting /boot (and the ESP, if the kernel needs to be copied there). I've seen some people suggest leaving /boot unmounted, or mounted read-only most of the time, as a security measure, but I'm skeptical that this would be a big improvement over normal root ownership and 755 permissions.
Historically, kernels were once stored in the root (/) filesystem, and some distributions still provide a link from /vmlinuz to /boot/vmlinuz-{version} for this reason. The /boot directory is technically required by the FHS, but I suppose you could create an FHS-nonconformant distribution that doesn't use this directory.
Offline
@srs5694 - So, today I went ahead and got rid of the systemd services that I had copied to update the kernels and initramfs in the EFI. Then, I deleted my /boot partition entirely, after backing things up. I changed my fstab to mount the EFI at /boot and made appropriate changes in the rEFInd config files to handle my kernel and initramfs in their default location - /boot and copied everything back over, eliminating the /EFI/arch/ directory I had before.
Everything works like a charm so far and now the normal kernel upgrade process shouldn't cause any headaches or require any extra steps. Probably not for the uninitiated, at least not without some automated installation that ensured everything was mounted properly that needed to be mounted first, but with a better understanding of what is happening and thinking through the possible problems that could come up all is working great.
I kind of don't like doing things in a way that seems to go against the intent of the UEFI specs as I understand them, but this is an efficient setup now. I don't even have to rename my kernels now, just had to make sure that rEFInd's config was setup to scan for non-efi named kernels. I would probably opt to keep things on the EFI in vendor specific directories, as intended by the spec, if I was going to try to run more than one Linux system from the same machine, but with only Arch on there, there is little chance of things getting overwritten or clobbered, at least no greater than on any system.
So, long and short of it, I now have no /boot directory or /boot partition until my kernel, in booting up, has reached the stage where it mounts the things contained in my fstab. After that, /boot is there for the duration of my session, as expected, ready for any pacman kernel updates and / or initramfs regeneration.
Offline
When I first set up UEFI on my machine, I chose to go the route of a direct efibootmgr entry (you know the f*cked up looking one with the double pipe conversion from ascii to unicode). For some reason, that version of my firmware would not write that correctly if I kept everything in the proper \EFI\arch directory, as it would truncate part of that path. So I had to keep everything on /boot just as you have done here sidneyk, and it was super simple and easy since Arch was my only OS on the machine.
I now keep things in the \EFI directories so that I can keep it more organized, as I have since put other things on (and subsequently taken them off). It also allows for me to keep numerous bootloaders and boot managers in the ESP all w/o making the root of it look all super crazy and disorganized.
To make things update correctly though is rather simple. I just use one path/service per kernel. When it is detected that it is written at /boot it moves it appending .efi, Then I have set mkinitcpio to write the initramfs according not to what is at /boot, but /boot/EFI/arch/*, and also to put the initramfs directly there. By doing this, if for some reason the path/service fails, so too will the creation of the initramfs, as it will then try to build with modules that are not there. This should be noticeable in my opinion, but if I fail to notice for some reason, I at least have the correct kernel/initramfs to get into the initramfs shell (ash), and quite probably the rescue.target.
Offline