So I should just mount it, right? Cause I tried that but it failed to install ArchLabs so I am not too sure why that happened?
What version of the installer were you using?
I downloaded the latest ISO that will be
2020.05.04 and I also updated the
archlabs-installer (which gets renamed to
installer after the update) via this command
pacman -Sy archlabs-installer and I just did this yesterday.
Edit: I setted up an encrypted partition, and inside it I set up an LVM with 3 different partitions which were mounted as
/swap. I mounted the windows boot partition without formatting it.
You only need to mount the partitions that you will be writing to. I don’t think mounting the Windows partition is necessary.
If you need to split your hard drive with Windows 10 already on it, using a Linux Mint LiveCD or the Windows Partition Manager are usually good choices. Make a 1GB GRUB partition, and make a larger partition for your OS. Then mount the partitions before running the installer, and you’re good to go!
So I guess I then mount the GRUB partition as a
You can mount the partitions, but the method that normally works for me is this:
-before running archlabs-installer, run these two commands:
mkfs.vfat -F32 /dev/nvme0n1p1
mkfs.ext4 -q /dev/nvme0n1p2
remember to replace the above labeled partitions with your actual partitions
Now run archlabs-installer
-once you reach the main menu, skip down to option 4.1 “mount partitions” and follow the instructions to reformat your GRUB and ROOT partitions. Do NOT reformat your partitions using option 2 in the main menu.
-continue as normal
I ended up just creating another partition and mounting that as a
/boot partition and it works fine, both Windows and Linux are showing up on the GRUB boot menu.
Just out of curiosity, when the computer starts up, why does it chose to read the GRUB bootloader first over the Windows bootloader, especially when the Windows bootloader is located at
sda2 but the GRUB bootloader is located at
(someone correct me if I’m wrong, but here it goes)
Often in your BIOS settings you will have the option to boot to your hard drive, and to boot straight to the Windows Boot Manager located inside your hard drive.
If your BIOS is set to boot to your HDD/SSD drive first, with only Windows installed, it will go to Windows Boot Manager since it has nowhere else to go. When you install GRUB though, it tends to take over that boot option, leaving Windows to the “Boot Manager” option. This means the BIOS will normally first read the GRUB boot manager, no matter where it is on the drive.
If your BIOS was set to boot to the hard drive, then the prinmary boot manager for that option changed between the start of the Archlabs installation and the reboot.
Sorry if this is confusing LOL
When you install grub , there is an entry about it in the Partition Table
I thought the grub bootloader is stored on the partition though? This is for a UEFI system not legacy BIOS.
But there are two bootloader partitions, once is Windows, and one is GRUB, which are both on the same drive. So how would the BIOS know which bootloader to use? I am confused with that sorry mate.
Normally, GRUB can be accessed by booting to the hard drive option, while the Windows Boot Manager is clearly named in the BIOS.
For example, on my computer I access GRUB by booting to: “Samsung 970 EVO,” while I can access the Windows Boot Manager by booting to “Windows Boot Manager.” The names won’t be exactly alike but pretty close to this.
You also can run
sudo grub-mkconfig -o /boot/grub/grub.cfg
To update your GRUB menu. That way you can choose between Windows and Archlabs without having to use the BIOS boot menu.
There will be a boot entry flashed to the BIOS’ onboard memory when installing grub (and most other bootloader options), these can be changed and you could just boot each bootloader from the BIOS and it’s respective option. Bootloaders like grub allow chainloading other bootloaders.
You shouldn’t need to create multiple EFI partitions like this but I’d need to see what happened to figure it out. Sometimes windows makes the partition very small (~90M) and packs it full of locale/translation files so perhaps you just ran out of space, in this case your solution of multiple boot partitions is perfectly fine.
Ah I see, so that means that with the BIOS’s onbard memory, it by default will set to point to the partition where grub is installed?
Is this the CMOS?
What happens when the CMOS battery runs out? It would go back to its defaults then I guess it would not able to point to GRUB partition then?
With EndeavourOS (another Linux-based distro) all I have to do is mount the boot partition as
/efi/boot and set
boot flags and it works fine.
Not quite, you can point the BIOS to boot whatever you like either using a tool like
efibootmgror the BIOS menus themselves, grub just so happens to set itself as the default when installing using efibootmgr.
No the onboard flash memory is non-volatile and does not require power to retain info like bootloader entries. The CMOS is volatile (requires power to retain data) and holds things like: date/time, fan settings, overclocks, user profiles/settings, and boot order. If the battery were to die you would have to set the boot entry every time, you can test this without much risk by just removing the CMOS battery and try booting, it will just pick whatever it likes as a default and the date/time/settings will be defaulted.
I’m not sure what this has to do with anything, we’re not Endevour, how large is the EFI partition and how much free space does it have?
Ah I see.
Oh that is interesting, I didn’t realise there was a separate non-volitile memory.
99 MB. I guess I could try and extend the size of it before I mount it as
There’s usually at least two non-volatile. One holds the BIOS itself with optional dual-bios chips as backup, and one for user settings and the like I was referring to above.
99 free or 99 total? I think thats just the standard size that windows 10 creates. You can free up space by removing old unused bootloaders (don’t need a seperate grub install for every linux OS, just rebuild the config from whatever OS you originally installed grub on and it should be able to find their entries. the kernel images are big though)
I guess this doesn’t apply to legacy BIOSs?
Its consuming 33 MB of data and the partition has 99 MB of total storage, sorry I should have been more clear.
Ah I see, thanks