Installed xfce from the iso.
Manjaro loaded the first time.
The next boot, Manjaro was stuck at launch.
grub rescue did not work either as the file systems were unrecognized.
If I plugged-in a flash in which manjaro was installed, then the boot-efi partition would become damaged which I would be able to repair using the manjaro install flash iso. But the boot-efi would become corrupt again later when I plugged it into the PC.
Had to re-install from manjaro-xfce-22.1.3.iso
I think I know why that happened but haven’t had a chance to try it.
Had installed from the 23.0.4 iso to /dev/sda
Then without disconnecting drive /dev/sda, installed Win10 to /dev/sdb
Windows used and modified the Manjaro EFI partition. <-- this is what caused the problem.
Disabling fast-boot via Control Panel > System and Security > Power Options > Choose what the power button does > uncheck Turn on fast start-up made no difference.
So the correct step is to disconnect the manjaro drive before installing linux on the second drive so that Windows creates it own boot efi partition.
Had even tried installing Windows first so it would create it’s own boot partition. Later after installation completed, installed manjaro from 23.0.4 iso to the same drive where I had created another FAT32 boot-efi partition with boot flag checked. Could boot to manjaro the first time. But later after booting to Win10, could no longer boot into manjaro.
Have a machine with the same setup as the paragraph immediately above but with Win7 and have had no problems.
Will retry 23.0.4 iso when get time.
It happened again to manjaro-xfce-22.1.3.
Again grub rescue was useless as none of the partitions had a linux file system.
The same happened to a flash drive with linux on it. However, with the flash drive, was able to repair the boot-efi partition as a linux file system was still present.
Not sure why /dev/sda1 had no linux file system to allow repair.
Fortunately, was able to restore the boot-efi partition on /dev/sda1 from a Clonezilla image.
Have dual boot Manjaro/Win10 on a laptop but never had this problem.
But that Win10 installation is from an earlier release where it was still possible to disable Win Update.
This Win10 installation is from Win10_22H2_English_x64v1.iso
Will now have to disable UEFI in BIOS to see if that is a solution.
Follow strictly this guide and you should be fine:
First, the disk should be gpt formatted, not msdos with MBR.
Make sure not to mix BIOS / UEFI install, both Windoze and Manjaro should be installed the same mode, i.e. in UEFI mode. To do so you have to boot the ISO USB stick in UEFI mode by selecting the entry with “UEFI” in the name when booting from your firmware.
That means UEFI mode must be turned-ON prior to installing the flash drive so that it will be recognized as UEFI device and immediately after installation is complete, on first boot, turn-OFF UEFI mode in BIOS before booting into manjaro.
grub rescue not possible when “Filesystem is unknown”
Still don’t understand what is happening because even without launching Windoze, /dev/sda1 gets corrupted when UEFI is enabled in BIOS.
Maybe it’s a firmware virus?
That would be a very bad idea when the system is installed in EFI mode as you will not be able to boot the system.
If you existing Windows is MBR - Manjaro must be MBR too - don’t try to mix EFI and MBR - very bad idea.
You can verify running
sudo fdisk -l /dev/sda
If the disk partition layout is DOS then it is MBR and you should disable EFI in firmware prior to install as doing so will ensure Manjaro will install as MBR.
You should install Manjaro with the latest iso: it is 23.0.4.
$ sudo fdisk -l /dev/sda
[sudo] password for
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WD Blue SA510 2.
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: gpt
Disk identifier: 80362724-9DC3-2C43-9EB4-E528F0D50BA5
Device Start End Sectors Size Type
/dev/sda1 2048 4196351 4194304 2G EFI System
/dev/sda2 4196352 20973567 16777216 8G Linux swap
/dev/sda3 20973568 125831167 104857600 50G Linux filesystem
/dev/sda4 125831168 335546367 209715200 100G Linux filesystem
/dev/sda5 335546368 557207551 221661184 105.7G Linux filesystem
/dev/sda6 557207552 976773119 419565568 200.1G Linux filesystem
$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WD Blue SA510 2.
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: gpt
Disk identifier: ED0C6F3E-AD68-43BE-AF76-F9DF615EA427
Device Start End Sectors Size Type
/dev/sdb1 2048 206847 204800 100M EFI System
/dev/sdb2 206848 239615 32768 16M Microsoft reserved
/dev/sdb3 239616 208882148 208642533 99.5G Microsoft basic data
/dev/sdb4 208883712 209952767 1069056 522M Windows recovery environment
/dev/sdb5 209952768 976771071 766818304 365.6G Microsoft basic data
$
But still I had to disable EFI in MB BIOS so that /dev/sda1 does not get overwritten.
And still I’m not clear why it is being over-written even if I don’t select Windows from the Grub boot menu?
Will update to that kernel later.
My suggestion to consider:
When manjaro is selected from the Grub boot menu under dual boot, then manjaro should query the filing system of the EFI partition.
If the result is “Filesystem is unknown”, then manjaro should restore the manjaro EFI partition automatically from a clonezilla image that manjaro creates and stores somewhere after an update-grub command.
That way, it would not be necessary to turn-off EFI mode in MB BIOS.
And,
I have noticed, the same happens to manjaro live flash drives after selecting ‘UEFI flashdiskname’ from MB BIOS.
So it would be nice to have these clonezilla images linked by dev ID so that the appropriate clonezilla image is used to restore the filing system of the boot media.
You have messed your system. When you turn off EFI mode - you effectively install in BIOS mode.
It is possible - for newer systems - to use either BIOS/GPT or EFI/GPT they cannot be combined.
If you use firmware CSM or compatibility mode the system - not the ISO - will choose the BIOS mode over EFI mode if the media supports both - which Manjaro media does.
They are mutually exclusive as the BIOS uses an unformatted partition of partitition type EF02 to store the bootloader and the EFI uses an FAT32 formatted partition to store the efi loader.
You cannot combine the two boot modes into one bootloader - that is how it is - and this will not change.
The only effective method of ensuring EFI installation with Manjaro media is to ensure EFI mode is the only boot method - that is configured in your firmware.
I suggest you be more careful with your choices during installation.
If you - for what ever reason - need to take special considerations you must select the manual partition scheme, assign possible existing partition to your configuration and ensure the format option is unchecked.
You have messed your system. When you turn off EFI mode - you effectively install in BIOS mode.
You mean: When you turn off EFI mode in BIOS - you effectively install in MBR mode?
So how do I fix my system?
Both Windows and Linux installations were done with EFI enabled in BIOS to allow both install medias to create a GPT partition table on the respective drives. If EFI was disabled in BIOS, the install media could only create MBR partitions tables.
EFI was disabled after installation because, otherwise, the Boot-EFI partition of my Linux drive was becoming corrupt every-time I tried booting manjaro.
Stick to one mode - preferably UEFI.
Boot the live media that way, install that way, use that way.
I did that the first time. Windows then overwrote the Linux EFI-Boot partition so that the Linux boot partition was reporting “Filesystem is unknown”. Also, Windows installer did not create it’s own EFI-boot partition because it used the Linux EFI-Boot partition.
Whatever you do during your windoze installation is not the fault of Manjaro.
In the past many made this easier for themelves by simply installing linux after windoze, in recognition of the tendencies of windoze to hijack the bootloader et al.
But that does not mean they cannot share the same ESP.
And certainly - you must stick to one mode for it to work. You cannot install in UEFI then disable that and attempt to boot using traditional BIOS/MBR. Nor the other way around.
In the past many made this easier for themelves by simply installing linux after windoze, in recognition of the tendencies of windoze to hijack the bootloader et al.
Yes. I tried that also. Disconnected my Linux drive and with UEFI mode ON in BIOS, I first installed Windows. Then, I installed Linux, creating a separate EFI-Boot partition on that same drive.
It made no difference. The Linux EFI-Boot partition on that drive also got corrupted.
In the past many made this easier for themelves by simply installing linux after windoze, in recognition of the tendencies of windoze to hijack the bootloader et al.
So, I switched the USB SATA cables between the two drives so that /dev/sda is the Windows drive and /dev/sdb is the Linux drive.
$ sudo fdisk -l
[sudo] password for quest:
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WD Blue SA510 2.
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: gpt
Disk identifier: ED0C6F3E-AD68-43BE-AF76-F9DF615EA427
Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 239615 32768 16M Microsoft reserved
/dev/sda3 239616 208882148 208642533 99.5G Microsoft basic data
/dev/sda4 208883712 209952767 1069056 522M Windows recovery environment
/dev/sda5 209952768 976773119 766820352 365.6G Microsoft basic data
Disk /dev/sdb: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WD Blue SA510 2.
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: gpt
Disk identifier: 80362724-9DC3-2C43-9EB4-E528F0D50BA5
Device Start End Sectors Size Type
/dev/sdb1 2048 4196351 4194304 2G EFI System
/dev/sdb2 4196352 20973567 16777216 8G Linux swap
/dev/sdb3 20973568 125831167 104857600 50G Linux filesystem
/dev/sdb4 125831168 335546367 209715200 100G Linux filesystem
/dev/sdb5 335546368 557207551 221661184 105.7G Linux filesystem
/dev/sdb6 557207552 976773119 419565568 200.1G Linux filesystem
$
Now I’m able to boot without corrupting the boot-efi partition on my Linux drive.
Are you installing to external devices?
In this context - Linux does not corrupt anything - it is entirely unknown what the issue is.
But as @cscs already ponted out - Windows installed after Linux is likely to break but there is really no signs.
After years of speculation and hypothesising it could be that MS Windows is using some kind of hybrid installation - which creates a 16M partition to a BIOS loader which either load the kernel directly or load the efi loader when then load the kernel.
Always disable CSM (compatibility BIOS/MBR/GPT mode) and stick to EFI
Are you installing to external devices?
No. Both are internal drives.
OK then it is not USB cables but SATA - I got confused by the USB cables phrase