Moving from legacy drivers (and legacy boot) to open drivers (and UEFI boot)

GaaSantAna · 17 January 2026 17:35

Hello.
I will post here (maybe tomorrow) a step-by-step guide to anyone who needs to update but hold the latest stable update because of the problem with 590xx.
But first, I need a help:
I am using 580xx on 1050Ti (my last update was in december/2025), and I need to change my PC from BIOS/legacy to UEFI. And, I will install a new GPU from AMD (another people with older Nvidia cards maybe want to do the same thing, so I believe that is good this be on this topic).
First, I need to update (with my Nvidia GPU) AND change to UEFI.
What is the correct order?
I was planning this:

Change to 570xx or 575xx
Reboot
Update the system
Reboot
Change to UEFI (after updating the system, to make sure that I will not break anything)
Reboot
Install open-drivers (in this case, Nouveau)
Reboot
Install a new GPU and test then (maybe I will need to install something but I am not sure).

Is this order right?

Wollie · 17 January 2026 21:09

First thing to do is a backup.

GaaSantAna · 17 January 2026 21:16

Like every single major modification on system. Of course it is already done…

Teo · 17 January 2026 23:45

There are several such topics and even the Announcement features a mini tutorial so i do not see the need.
Otherwise, UEFI has nothing to do with the graphics, and changing from legacy to uefi will prevent you boot if the system is installed as legacy.

GaaSantAna · 18 January 2026 00:17

My new GPU yes need a UEFI system.
I am following this tutotial, and a lot of other users had changing from legacy to uefi.

I am having a issue with this procedure:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi
Installing for x86_64-efi platform.
grub-install: error: /boot/efi doesn't look like an EFI partition.

Need help here. I am on a live usb with a chroot environment

Molski · 18 January 2026 00:25

That was for a specific user.

I can tell you that /boot/efi is not an EFI partition!

The mods around here prefer you make this a separate post.

Might need the output of your lsblk -f. (And inxi -v8z can help too.)

But chances are, inside the chroot you just need to:

mount /boot/efi

sudo not needed as you are already root. And your /etc/fstab should already be pointing in the right place for /boot/efi. (The FAT32 partition.)

GaaSantAna · 18 January 2026 00:31

That user was me!
I was following your instructions.
I had to convert from MBR to GPT (for a reason that I don’t know, system was on MBR…)

(in the following update the efi-boot partition was not mounted because I restarted, but I tried with it mounted)

lsblk -f                                                         ✔ 
NAME FSTYPE FSVER LABEL                UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0
     squash 4.0                                                                   0   100% /run/miso/sfs/livefs
loop1
     squash 4.0                                                                   0   100% /run/miso/sfs/mhwdfs
loop2
     squash 4.0                                                                   0   100% /run/miso/sfs/desktopfs
loop3
     squash 4.0                                                                   0   100% /run/miso/sfs/rootfs
sda                                                                                        
└─sda1
     ext4   1.0   HD                   0730390f-64f7-4722-8644-0b147af0a682                
sdb                                                                                        
├─sdb1
│    ext4   1.0                        d6ecda09-ff35-416a-9f44-94f281802154                
├─sdb2
│    vfat   FAT32                      39B8-499E                                           
└─sdb3
     swap   1     swap                 a95fd9bf-e175-4a17-8c3c-91e6b1210744                
sdc                                                                                        
└─sdc1
     ext4   1.0   SSD-VMS              0a8dbb6f-1615-4fe7-869d-f847134b304d                
sdd                                                                                        
├─sdd1
│ │  exfat  1.0   Ventoy               DCDE-6DE2                                           
│ ├─ventoy
│ │  iso966 Jolie MANJARO_GNOME_251RC1 2025-12-23-13-49-03-00                     0   100% /run/miso/bootmnt
│ └─sdd1
│    exfat  1.0   Ventoy               DCDE-6DE2                                           
└─sdd2
     vfat   FAT16 VTOYEFI              3105-B091                               4.6M    86% /run/media/manjaro/VTOYEFI

My system is on sdb (system, boot-efi and then swap)
and on manjaro-chroot -a

[manjaro-gnome /]# mount /boot/efi
mount: /boot/efi: can't find in /etc/fstab.

Looks like /etc/fstab is not point to right place.

The correct step by step should be this one?

After making a partition for swap and EFI:

sudo mkfs.fat -F 32 /dev/sdb2
sudo mkdir /boot/efi

sudo mount /dev/sdb2 /mnt/boot/efi
sudo manjaro-chroot /mnt /bin/bash
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi

Is that correct?

A GParted screenshot of my system:

EDIT:
Now it is moving on!

But, when I run lsblk -f /dev/sdb2 the output is

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sdb2                          299.2M     0% /boot/efi

There is no UUID to add on /etc/fstab
How can I add the UUID to /etc/fstab?

My /etc/fstab:

# <file system> <mount point> <type> <options> <dump> <pass>

UUID=d6ecda09-ff35-416a-9f44-94f281802154       /       ext4    defaults,noatime        0       1
UUID=b1b7c693-1d50-44de-b647-e3f032335bfa       swap    swap    defaults,noatime        0       0
tmpfs   /tmp    tmpfs   defaults,noatime,mode=1777      0       0
/dev/disk/by-uuid/0730390f-64f7-4722-8644-0b147af0a682  /mnt/0730390f-64f7-4722-8644-0b147af0a682       auto    nosuid,nodev,nofail,x-gvfs-show 0       0
/dev/disk/by-id/wwn-0x5001b448b0f9e4ef-part1    /mnt/wwn-0x5001b448b0f9e4ef-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0
/dev/sdc3       /mnt/sdc3       auto    uid=1000,nosuid,nodev,nofail,x-gvfs-show,noauto 0       0
/dev/disk/by-id/wwn-0x50014ee211983dcd-part1    /mnt/wwn-0x50014ee211983dcd-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0

Molski · 18 January 2026 00:51

Oops my bad. Getting crosswired!

Sorry, need a little more then.

Output of your /etc/fstab

And the output of: lsblk -o NAME,PTTYPE,FSTYPE,MOUNTPOINT,UUID

lsblk doesn’t show partition type any other way.

Wait, I now see an fstab.

Okay we should fix this.

GaaSantAna · 18 January 2026 00:54

[manjaro-gnome /]# lsblk -o NAME,PTTYPE,FSTYPE,MOUNTPOINT,UUID
NAME       PTTYPE FSTYPE MOUNTPOINT UUID
loop0                               
loop1                               
loop2                               
loop3                               
sda                                 
`-sda1                              
sdb                                 
|-sdb1                   /          
|-sdb2                   /boot/efi  
`-sdb3                              
sdc                                 
`-sdc1                              
sdd                                 
|-sdd1                              
| |-ventoy                          
| `-sdd1                            
`-sdd2

and /etc/fstab

# <file system> <mount point> <type> <options> <dump> <pass>

UUID=d6ecda09-ff35-416a-9f44-94f281802154       /       ext4    defaults,noatime        0       1
UUID=b1b7c693-1d50-44de-b647-e3f032335bfa       swap    swap    defaults,noatime        0       0
tmpfs   /tmp    tmpfs   defaults,noatime,mode=1777      0       0
/dev/disk/by-uuid/0730390f-64f7-4722-8644-0b147af0a682  /mnt/0730390f-64f7-4722-8644-0b147af0a682       auto    nosuid,nodev,nofail,x-gvfs-show 0       0
/dev/disk/by-id/wwn-0x5001b448b0f9e4ef-part1    /mnt/wwn-0x5001b448b0f9e4ef-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0
/dev/sdc3       /mnt/sdc3       auto    uid=1000,nosuid,nodev,nofail,x-gvfs-show,noauto 0       0
/dev/disk/by-id/wwn-0x50014ee211983dcd-part1    /mnt/wwn-0x50014ee211983dcd-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0

If I click with right button on /dev/sdb2 on GParted and go to UUID it shows D169-FE8A, but I don’t know if is the correct one.

Sorry about the constant edit on this post, but is 9:54pm here and I am very excited to install my new gpu!

Molski · 18 January 2026 01:32

We should change all your mounts to go off just the plain UUID. And I can’t even see a /boot/efi mount.

Going one line at a time..

/etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>

UUID=d6ecda09-ff35-416a-9f44-94f281802154       /       ext4    defaults,noatime        0       1
Good up to here.
UUID=b1b7c693-1d50-44de-b647-e3f032335bfa       swap    swap    defaults,noatime        0       0
Your swap is a95fd9bf-e175-4a17-8c3c-91e6b1210744 according to your lsblk
UUID=39B8-499E                             /boot/efi           vfat      umask=0077 0 2
You are missing /boot/efi! So add this line.
tmpfs   /tmp    tmpfs   defaults,noatime,mode=1777      0       0
Should be okay, but I think I’m used to different options here.

That should fix it anyway..

But your fstab does get a little funky.. And I don’t know what you’re trying to do. (But this shouldn’t stop you from booting and the like.)

/dev/disk/by-uuid/0730390f-64f7-4722-8644-0b147af0a682  /mnt/0730390f-64f7-4722-8644-0b147af0a682       auto    nosuid,nodev,nofail,x-gvfs-show 0       0
Just put in UUID=0730390f-64f7-4722-8644-0b147af0a682 if you want it matching the others but this is fine. And this mounts your other ext4 /dev/sda1 file system to:

/mnt/0730390f-64f7-4722-8644-0b147af0a682

If you want that?
/dev/disk/by-id/wwn-0x5001b448b0f9e4ef-part1    /mnt/wwn-0x5001b448b0f9e4ef-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0
/dev/sdc3       /mnt/sdc3       auto    uid=1000,nosuid,nodev,nofail,x-gvfs-show,noauto 0       0
/dev/disk/by-id/wwn-0x50014ee211983dcd-part1    /mnt/wwn-0x50014ee211983dcd-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0
/dev/sdc3 dosn’t exist. And using /dev/disk/by-id/ is awkward. I would just use their UUIDs, and mount them in more user friendly folder names, unless you want it like this.

So no idea where these fit in without a:

ls -l /dev/disk/by-id/wwn-0x5001b448b0f9e4ef-part

ls -l /dev/disk/by-id/wwn-0x50014ee211983dcd-part1

GaaSantAna · 18 January 2026 01:42

That’s my main system, so ok!

Following your previous post, I will change swap UUID to a new UUID, since the previous swap was deleted. So I need to just change to the new UUID, right

Will add this line right now!

I do now touched anything on this. Maybe is related to my install (this system was installed on 2022).

For the funky part:

sdc3 is another ssd that have some Virtual Machines images. Can I just ignore it, right?

I never touched this lines. I don’t know why they are there.

Again, never touched it… so for now I will ignore it and move on.

So, to my system get back to run:

add the /boot/efi file
Make swap
add the new UUID from swap in /etc/fstab/
sudo update-grub

Right?

After the changes:

/etc/fstab                                                                                     
# <file system> <mount point> <type> <options> <dump> <pass>

UUID=d6ecda09-ff35-416a-9f44-94f281802154       /       ext4    defaults,noatime        0       1
UUID=0da07dc7-e77b-4722-a1c3-89913f48d104       swap    swap    defaults,noatime        0       0
UUID=39B8-499E                             /boot/efi           vfat      umask=0077 0 2
tmpfs   /tmp    tmpfs   defaults,noatime,mode=1777      0       0
/dev/disk/by-uuid/0730390f-64f7-4722-8644-0b147af0a682  /mnt/0730390f-64f7-4722-8644-0b147af0a682       auto    nosuid,nodev,nofail,x-gvfs-show 0       0
/dev/disk/by-id/wwn-0x5001b448b0f9e4ef-part1    /mnt/wwn-0x5001b448b0f9e4ef-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0
/dev/sdc3       /mnt/sdc3       auto    uid=1000,nosuid,nodev,nofail,x-gvfs-show,noauto 0       0
/dev/disk/by-id/wwn-0x50014ee211983dcd-part1    /mnt/wwn-0x50014ee211983dcd-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0

Still need to do a sudo update-grub, right?

GaaSantAna · 18 January 2026 01:55

Some problems after reboot:

When on choroot:

 manjaro-chroot -a                                                ✔ 
==> Mounting (ManjaroLinux) [/dev/sdb1]
 --> mount: [/mnt]
 --> mount: [/mnt/boot/efi]
mount: /mnt/boot/efi: fsconfig() failed: /dev/disk/by-uuid/39B8-499E: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.

EDIT:
Was a simple error:

This UUID is different from the actual UUID from my PC, which is D169-FE8A

And it worked!
System on GPT, using UEFI!

 [ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"           ✔ 
UEFI

Tomorrow I will get back if a guide to whoever wants to move to a AMD GPU. It will make sense when I post tomorrow.

@Molski Huge thanks!
You save me today!
I should even buy you a coffee (laughs in portuguese)

Teo · 18 January 2026 02:31

We have a rule - one problem per topic. And you are mixing drivers, efi, and gpt. I at least removed the video tags.

GaaSantAna · 18 January 2026 02:36

Sorry about that.
The whole problem was: I have a Nvidia (old card), using a MBR/Legacy system. To get free from Nvidia, I get my hands in a AMD GPU, but I needed to change to UEFI first. And, more problematic than that: I did’t update since december because of Nvidia situation. So, it seems different problems (and they are), but for me it was actually one BIG problem.

My intention is to create a small step-by-step for anyone in my situation (old Nvidia GPU, problem with updates) and make it available here. But it is necessary, I can make another post not was “Support” but in another category.

Molski · 18 January 2026 04:23

You should comment out (to hopefully delete) everything else in your fstab if you’re not using it.

Your system can potentially take much longer to start up with bad entries too.

So put a # in front of each of all those:

GaaSantAna:

#/dev/disk/by-uuid/0730390f-64f7-4722-8644-0b147af0a682  /mnt/0730390f-64f7-4722-8644-0b147af0a682       auto    nosuid,nodev,nofail,x-gvfs-show 0       0
#/dev/disk/by-id/wwn-0x5001b448b0f9e4ef-part1    /mnt/wwn-0x5001b448b0f9e4ef-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0
#/dev/sdc3       /mnt/sdc3       auto    uid=1000,nosuid,nodev,nofail,x-gvfs-show,noauto 0       0
#/dev/disk/by-id/wwn-0x50014ee211983dcd-part1    /mnt/wwn-0x50014ee211983dcd-part1       auto    nosuid,nodev,nofail,noauto,x-gvfs-show  0       0

Then you can bring (one of) them back if need be.

It is attempting to mount four different file systems in 4 sub-directories under /mnt.

I know the first one is a valid ext4 file system looking at your lsblk -f, but there is no /dev/sdc3.
The other ones you have to see where the sym link leads to see it in: lsblk -f

You may have really a slow boot, and not even know it.

Kobold · 18 January 2026 11:37

I recently also bought a AMD GPU (AMD Power Color RX 9070), i read that some GPU’s (not all) don’t show a Post Screen with Legacy Bios… but when your PC can still boot into the OS, you will still later get a picture from your Monitor inside OS on your Desktop, or even earlier maybe while Grub show up? I don’t know..

Im actually not sure, if my new AMD GPU really require it to switch to UEFI. It also may depends on the Brands if they support UEFI and Legacy Boot or not, at least this was what i could read few year’s ago, as this Topic came up.

I also read somewhere that a AMD GPU should be run instantly without changing driver’s or deleting the old nvidia drivers. Is this info wrong?

Aragorn · 18 January 2026 11:49

That’s because some of them don’t have a VGA text console. Apple computers and some SGI workstations were like that. They rely on a framebuffer device instead, but legacy BIOSes don’t have a framebuffer, and so they cannot output raw VGA text to a graphics adapter that relies on said framebuffer.

However, this will be the case for legacy BIOS chips. Most (but not all) UEFI firmware initializes a framebuffer, and chances are that it will be preserved during legacy BIOS emulation, with the framebuffer emulating a VGA text console.

The kernel should normally detect the presence of the AMD GPU and automatically load the amdgpu driver. You can uninstall the Nvidia driver later.

Kobold · 18 January 2026 11:54

Yeah from the info’s which i could collect was that the newest AMD 9000 Gen GPU’s required Kernel 6.13 or higher.

So this Topic is more confusing, when there is 2 different objectives. 1 step at a time.

Aragorn · 18 January 2026 12:28

This is why we prefer the “one thread for one problem, experienced by one member” approach, as opposed to “Hi guys, I’ve got six problems since this update” or “Hi, can I join in? #MeToo!”.

GaaSantAna · 1 February 2026 04:12

If I had made a post for each problem, besides cluttering the forum, it would have been impractical. The problems are related to each other because, in the end, what really mattered was having a correct and well-done graphics card transition.

I really like using Manjaro; the team’s work is amazing. I use the forum for helping me (when needed) and read the documentation about updates. Everyone has their own life, and I don’t want to bother anyone. So maybe less sarcasm is a good way of dealing with people who don’t know as much as you do.

So, as promised, here is a step-by-step of what I did.

Since I was using Nvidia and my updates was delayed, first of all, I changed to open drivers (Nouveau) and the removed the Nvidia drivers.
Update the system and reboot
Moved to UEFI (there is a good tutorial in Manjaro Wiki, I used chroot trough a live USB). In my case, my disk was on MBR, had to move to GPT (this procedure has a risk of losing data).
Replaced the old GPU with the new one, and everything worked just fine, since the AMD drivers work out of the box.

Thanks everyone for the help and patience.