UEFI preferably.
I can only assume it’s OK now, but for peace of mind, open your Terminal and run:
sudo dmesg | grep -i "EFI v"
If the command returns something then your Manjaro is booting as UEFI; if it returns nothing at all, you’re not.
You could paste your updated system information, if you like; but I suspect booting with the UEFI Ventoy while performing various repairs has helped.
Glad it worked out.
Regards.
It appears to be UEFI during this particular bootup:
sudo dmesg | grep -i "EFI v" ✔
[ 0.000000] efi: EFI v2.8 by American Megatrends
Can the Ventoy UEFI replace the MBR boot?
Your computers Firmware settings determine whether the system boots as UEFI or as legacy (Bios).
That is not a function of Ventoy.
When Ventoy is installed to some USB memory stick, you can choose whether the partition type will be MBR style or whether it shall be GPT style.
A system set to boot using legacy Bios rather than UEFI might not be able to boot fom a Ventoy disk formatted as GPT.
I haven’t tinkered with these options - my USB device is an old stick with only 4 GB and I always went with the default, which is not GPT partition style but MBR style.
In light of the above, this question:
does not make sense for me.
Or, perhaps I should be asking:
what do you mean, what are you asking about?
These are exactly my thoughts! I’ve seen references on here re. creating a Ventoy USB in either Legacy or (U)EFI mode; this had me 
.
Note: I use GPT on all systems regardless of boot mode. This one is running in BIOS (Legacy) and was used to create the medium for installing another, using (U)EFI mode.
It all started when I made my Manjaro installation USB through rufus, where even though I set it as GPT it gave me an error but made the installation USB anyways. Apparently the USB was set to MBR at the output. It’s assumed that I installed Manjaro on MBR the whole time even though it’s on a 2 terabyte drive as well as CSM being disabled on BIOS.
Sometimes when I boot up, grub (and then TTY based on the problem I was having earlier) would display with really low resolution resembling MBR. Then at other times if for example I rebooted from Windows 10 and arrive at grub, grub itself and then TTY (again from the problem I was trying to solve) would display at a higher resolution resembling UEFI.
Mod edit: This is a wrong assumption
Does this mean that the bootup is alternating between MBR and UEFI or is something else going on here?
I do not know Rufus - never used it.
Either I use Ventoy
or I simply copy the ISO to the USB using a simple command like:
sudo cp xyz.iso /dev/sdx
It doesn’t matter which partition type is used on the USB - as long as your machine can read it.
It was simply speculation on my part that some older Bios implementations would not be able to read GPT partitions - and I was apparently wrong about that.
With dd or cp (the example) there is only what is in the ISO - no extra file system.
… by whom?
the command output further up said “efi” …
You are likely confusing the maximum partition size ( 2 TB ) with MBR style partitions
with the file size limit of certain file systems
which is 4 GB for FAT32 file systems
and 16 EB for exFat, for example.
I’d say no, but this being your machine, not mine, I can’t be sure.
… something else it is 
by soundofthunder based on this:
I eventually wiped that particular USB device and used Ventoy on it, now it has the Manjaro installer on GPT so I am wondering if I’m going to have to reinstall Manjaro with the ventoy USB instead of continuing where things are right now. Either way I am just as confused as you are.
… but the thread is marked as solved?
If it isn’t I’d opt for a reinstall at this point.
The partition type (GPT or MBR) on your Ventoy device is of no consequence.
The original problem is solved, what we’re discussing right now was brought up by soundofthunder upon observation.
Either way it looks like the problem was never really there to begin with, here is what (sudo parted -l) displayed:
Model: ATA Samsung SSD 870 (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 2097kB 317MB 315MB fat32 boot, esp
2 317MB 2000GB 2000GB ext4 root
Looks like I dodged a bullet thinking that MBR on the rufus device was going to cause problems.
Just gonna run through these steps pointing out their actual definitions
Must they? Maybe some would have trouble via chroot, but most should not.
That is ‘install or reinstall default packages’
That is an uninstall command.
Should be included in (what was) the first step.
This really should not be needed unless somehow sddm was disabled or replaced.
So lets also reiterate these steps in a more reasonable order.
To my knowledge all of these commands can be run from either TTY or chroot.
( But they of course make no sense to simply run on a disconnected live ISO )
[ -f /var/lib/pacman/db.lck ] && rm -f /var/lib/pacman/db.lck
sudo pacman-mirrors -f && sudo pacman -Syu
sudo mhwd-kernel -r linux66-rt
sudo pacman -Rns linux-nvidia-meta
bash <(curl -s https://gitlab.com/cscs/mapare/-/raw/main/mapare) -IA
(select the correct desktop environment [KDE in this case])
sudo mhwd -f -a pci nonfree 0300
systemctl enable sddm
sudo mkinitcpio -P && sudo update-grub
** - Note that -f will query all mirrors from the existing mirror pool.
So if it was ever augmented or malformed this command would not reset it.
In that case you may use pacman-mirrors -c all or pacman-mirrors --continent, with the second attempting to geolocate.
Ah well I did my best explaining what I understood from all of it, thanks for the correction.
This is a false assumption and leads to wrong conclusions!
You can not detect BIOS/UEFI boot by graphical resolution !
yes - of course it is
… a assumption for one
and a wrong one at that as well 