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?
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. – mikuszefski – 2016-01-13T20:42:36.697
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) – mikuszefski – 2016-01-14T08:22:26.270
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 wassda
even if booting from usb? Now the usb issda
, and the disk issdb
. In any case, I would appreciate some info concerning my comment above though. Would it be good to make add if=/dev/sda2 of=usbStick/efi.img
to put it back as it was, just in case? Cheers. – mikuszefski – 2016-01-14T08:29:21.770Very funny, every time I try to figure out the question on
mkfs.vfat
and "bootable" I only find questions answered by Rod Smith. – mikuszefski – 2016-01-15T08:49:11.813The 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
). Add
backup will replicate whatever problems originally existed. – Rod Smith – 2016-01-15T14:56:33.097Thanks. Reading other EFI articles, including many of yours, I guessed that there is no specific boot part on the partition. So thanks for confirming. Also thanks for confirming that a basic file copy is enough. I thought about the dd, having an intact system in mind, or at least having a backup of something where Win10 was starting. Sure, if this system contains an error, I will just copy that. Appreciate your time and detailed explanation. Cheers – mikuszefski – 2016-01-18T13:54:52.123