You are not logged in.

#1 2013-03-28 23:57:02

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

[~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#2 2013-03-29 02:41:14

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#3 2013-03-29 03:41:34

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#4 2013-03-29 04:17:02

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#5 2013-03-29 04:30:19

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

WonderWoofy wrote:

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

#6 2013-03-29 05:07:03

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#7 2013-03-29 05:18:24

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#8 2013-03-29 05:19:53

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#9 2013-03-29 05:25:57

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

cfr wrote:

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

#10 2013-03-29 05:39:00

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#11 2013-03-29 06:28:23

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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.

Offline

#12 2013-03-29 10:52:30

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,494

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#13 2013-03-29 15:10:01

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

WonderWoofy wrote:
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

#14 2013-03-29 15:22:31

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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.

Offline

#15 2013-03-29 16:19:37

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

WonderWoofy wrote:
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

#16 2013-03-29 16:22:20

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#17 2013-03-29 16:39:48

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#18 2013-03-29 16:39:54

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#19 2013-03-29 16:59:05

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

#20 2013-03-29 17:32:40

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

WonderWoofy wrote:

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

#21 2013-03-30 18:02:43

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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.

Offline

#22 2013-03-31 03:38:50

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

srs5694 wrote:
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

#23 2013-04-01 02:31:58

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

sidneyk wrote:

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

#24 2013-04-01 04:35:40

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

@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

#25 2013-04-01 14:46:14

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [~solved] dosfsck: EFI overwritten long file name, not auto-correcting

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

Board footer

Powered by FluxBB