I am reporting a possible error with either the Manjaro installer or gparted. I discovered this problem after having to reinstall Manjaro because I was running out of room in my / partitiion. (I initially made my / partition too small.)
Below is a screenshot of my harddrive after getting the problem corrected.
You will notice that that the file system is “grub2 core.img” and the flags attached are “bios_grub”. If you have this configuration, then there is no problem. If the file system is “unknown” and there are no flags, then you’re dealing with some of the same software issues that I faced.
What seems to have precipitated this problem was that I performed the disk partitioning with gparted, setting up an 8mb, cleared partition with the bios_grub flag attached. I then went to the installer, selected the “manual installation” option and proceeded from there. I edited the edited the bios_grub partition, selected “unformatted” and made sure the bios_grub flag was attached. I then proceeded to mount the other partitions.
I re-installed Manjaro four or five times with the same result mentioned above.
It is only after I used the installer to delete the first three partitions, and then set them up with the installer that I got Manjaro to install correctly as shown in the screenshot above.
I don’t know where the problem lies. Only that the installer doesn’t seem to like the way gparted sets up the partitons.
Unfortunately, I did not take a screenshot of gparted before correcting the problem.
I do not know whether this applies to gparted, but many partitioning tools will warn you that the system needs to be rebooted after changing anything to the partition table, because the partition table is only read into memory at boot time, and especially so on a system that boots in legacy BIOS mode.
Therefore, if you use one partitioning tool to create partitions and then a different partitioning tool without having rebooted in the meantime, then the second partitioning tool doesn’t know what the new layout of the partitions on-disk is, because it’s using what the kernel says it is, and the kernel still holds the old information from when it was booted.
Actually, it’s bios_grub. It should be about 2 MiB in size and it should have the boot flag set.
A GPT drive that boots in legacy BIOS mode has a so-called protective MBR. This means that legacy partitioning software that cannot handle GPT partitions will then see one big “legacy” extended partition instead.
You do however have to tell the installer to put GRUB in the MBR — i.e. the area of the drive in front of the partition table header — because that’s where the boot.img of GRUB must go, and the grub2_core.img will then be written to the unformatted bios_grub partition. Without the bios_grub partition, GRUB will attempt to put its grub2_core.img right behind the boot.img, with as a result that it will overwrite the partition table.
I believe you should have completed the preparation, i.e. all settings in GParted upfront, then reboot and then start the installer. Unformatted >= 1MB partition (within the first 2 TB of the disk) and bios_grub flag set should be sufficient.
All of you are probably correct in that I should have rebooted after changing partitions with gparted and before using the installer. However, since my system is now working correctly, I won’t be checking to see if this is true.
In my defense, there are linux installation videos on youtube that show the installation procedure that I followed, without a reboot after changing partitions with gparted.
It might be helpful if a WARNING to this effect were included in the user-guide.
YouTube is not a good source for advice linked to installation of an OS, often the videos are simply describing something wrong or inaccurate, often the procedures are outdated. YouTube might be helpful for craft work or how to treat your pets but for quickly evolving systems like an OS and linked applications I would generally advise against following YouTube tutorials.