0

Again stumbling from one problem to the next. I recently installing OpenSuse13.2 parallel to win10. Worked nice. Then I decided to reintall, but Suse Leap, deleting the old Suse installation. At the end of the installation the computer just restarted and no boot option for Leap was shown. opensuse remains as option though. I had a similar problem with Ubuntu until I manually mounted the Efi partition and removed the ubuntu folder. Now I tried the same but I cannot delete as the partition always mounts as ReadOnly, even if I try sudo mount -o remount,rw /media/efi. Using mount | grep /media shows me that it starts as rw but is remounted to ro due to errors.

I guess this ReadOnly is also the reason why the Leap installation failed. Is this to filesystem errors? I read that some people used chkdsk on the EFI partition, but do not explain how. How would I do that? Or even better, is there a way to do it from a linux liveCD?

  • Laptop: MSI 16GF (only comes with recovery partition, no installation medium)
  • EFI on standard hard disk
  • Linux was on additional SSD

EDIT

I tired some fsck with the -n option to not make it worse, yet.

sudo fsck -n /dev/sda2
fsck from util-linux 2.26.2
fsck.fat 3.0.28 (2015-05-16)
0x41 Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
FATs differ but appear to be intact. Using first FAT.
/EFI/opensuse/MokManager.efi
 Contains a free cluster (19138). Assuming EOF.
/EFI/opensuse/MokManager.efi
 File size is 1276328 bytes, cluster chain length is 0 bytes.
 Truncating file to 0 bytes.
/EFI/opensuse/grub.efi
 Contains a free cluster (19450). Assuming EOF.
/EFI/opensuse/grub.efi
 File size is 918392 bytes, cluster chain length is 0 bytes.
 Truncating file to 0 bytes.
Reclaimed 793 unused clusters (3248128 bytes)
Free cluster summary wrong (62265 vs, really 63058)
 Auto-correcting
Leaving filessystem unchanged.
/dev/sda2: 430 files, 12718/75776 clusters

So, something went wrong on unmounting. Whether it was me or the Leap installation, does not change the fact that something is wrong.

Should I auto-correct these errors?

1 Answer 1

1

Here's the ultimate source of the problem:

0x41 Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

Chances are your Windows installation is set to use "Fast Startup," as is the default for Windows 8 and later. (Note that this is a Windows feature. Many EFIs have a feature with a similar name, but it's entirely unrelated.) To disable this feature, you must disable both it and the Hibernate feature. Many Web pages cover these subjects, but see here for a couple:

Once you've disabled this feature and rebooted a couple of times, the ESP should become usable. If not, I recommend you back it up (it's rather small), create a fresh FAT filesystem on it (using mkdosfs in Linux, for example), and restore your files. Do not delete and re-create the entire partition, though; that will change its GUID value, which will render NVRAM entries that point to your boot loaders invalid. Note also that re-creating the filesystem is simply a workaround for bad filesystem damage. If the Windows settings don't "take," the problem will recur, and re-creating the filesystem won't change that.

As background, know that Fast Startup turns a shutdown operation into a suspend-to-disk operation. This is fine if the only OS in use is Windows, but if you dual-boot, any shared partitions, including the ESP, will be left in a dangerously inconsistent state when you shut down or reboot from Windows. Disabling this feature slows the startup process but makes it safe to access shared partitions from both OSes.

6
  • Hi Rod, thanks for the detailed information. I have been aware of the "Fast Startup", which is already switched off, but not of the "Hibernate". I will switch that one off as well. I thought this is troublesome in case I mount the windows partition from linux. Did not thought that this affects the efi partition as well. Jan 13, 2016 at 20:42
  • Hello Rod, right now I am making several restarts. In any case I like the proactive mkdosfs approach, although it is sort of worrying. For the backup, do I just copy the files on the partition or is there something special to take care of. After unmounting would it just be mkfs.vfat -v /dev/sda2? To what extend is the efi partition "bootable" as mkdosfs states "mkdosfs can not create boot-able file systems"? (PS: I let fsck fix it. It now does not shows erros, but mount still does in error=remount-ro) Jan 14, 2016 at 8:22
  • Ok....it still states ` error=remount-ro` but I could delete the opensusefolder now. As I said I let fsck fix the errors, switched of hibernate, and did about 10 restarts. One (inclusive)or the other did it. So I will mark the answer as correct. Note, that I always wondered why it still was sda even if booting from usb? Now the usb is sda, and the disk is sdb. In any case, I would appreciate some info concerning my comment above though. Would it be good to make a dd if=/dev/sda2 of=usbStick/efi.img to put it back as it was, just in case? Cheers. Jan 14, 2016 at 8:29
  • Very funny, every time I try to figure out the question on mkfs.vfat and "bootable" I only find questions answered by Rod Smith. Jan 15, 2016 at 8:49
  • The term "bootable," in reference to FAT, almost always refers to BIOS-mode booting. (Nobody bothered to specify that because FAT partitions were almost always booted from BIOS-based computers until about mid-2011, when EFI became common.) EFI boots differently and requires nothing special in the filesystem per se, although there are lots of EFI quirks. A file-level backup of the ESP is adequate, although you may need to alter /etc/fstab after making a new filesystem to refer to a new serial number (UUID= in /etc/fstab). A dd backup will replicate whatever problems originally existed.
    – Rod Smith
    Jan 15, 2016 at 14:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .