Back Story

I wanted to install minikube, and that wanted virtual box, and that gave errors complaining about AMD-V (hardware virtualization) being unavailable, even after I found that in the bios and turned it on. Wisdom on the web said that the version of my Bios (F1) had a bug in AMD-V, and any version after F3 was also broken WRT virtualization, and didn't work well with 1950x processors (being more focused on the 29XX line). Soo.... I flashed to F3j


Now when I boot grub comes up just fine, and gives me the expected list of options (Ubuntu, Advanced Ubuntu options, mem check stuff, Windows 10) Windows works, and if I go into Ubuntu Advanced Options and select a recovery image it boots fine, however if I allow timeout or select the default Ubuntu option it boots, showing a purple screen and no progress (sometimes) or very fast scrolling text that stalls out one a message about clocksource: Switched to clocksource tsc. During this dead boot state neither the mouse or the keyboard (razer led lit models) light up and Ctrl-Alt-Del has no effect. The only recourse is to hold the power button for several seconds to force a reboot

What I've tried

My searching here and elswhere on the web suggests that this might be because EFI variables were being used and flashing removed them. These reports however all mention other motherboards, so I am not confident this is the problem. However in recovery mode I find that efibootmgr won't run complaining that EFI Variables are not supported on this system. So I've been trying to get that enabled... I loaded up the bios, and I've tried fiddling with the following options:

  1. I changed Storage Boot Option Control to UEFI Only from Legacy setting
  2. I switched Boot Option 1 and Boot Option 2, and there appears to be no difference as to whether Samsung 960 or UEFI 5.0 is first
  3. I changed the BBS Priorities to put UEFI first.
  4. Reading of issues with IOMMU settings I also tried moving this from auto to enabled

None of these has had any noticible effect.

System Details

  • Ubuntu 18.04 LTS dual booting via GRUB with Windows 10 successfully for the last 2 years.
  • Rev 1.0 Gigabyte Aorus Gaming 7 X399 motherboard
  • Ryzen ThreadRipper 1950x cpu
  • Samsung 960 nvme 500mb main drive
  • Samsung 970 nvme secondary drive
  • 48GB mem, 1080ti card, etc peripherals probably not relevant...

The Question(s)

  • Has anyone upgraded the bios on this hardware set (or at least on a Aorus X399) successfully? If so did you have this problem, and if you did how did you get around it.
  • Any boot linux boot gurus out there have any ideas how to get things back to normal?

I took a backup of the bios (using the quick boot tool in the bios) so restoring that might get me back to normal booting, but then I am still stuck on the Minikube install.

Update: after trying a BBS order with 960 Samsung first (the normal boot drive) I am now getting this when attempting a normal boot from grub: enter image description here The windows boot and boot from recovery/resume continue to work

Also Note: the UEFI:Verbatim 5.0 boot option is the memory stick I used to load the loader (didn't realize that was the name attached to my memory stick, thought it was some built in thing)

Update with requested info

gus@ns-l1:/$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-4.15.0-76-generic root=UUID=d44cf192-4f87-499a-b58a-573f498fc38a ro recovery nomodeset
gus@ns-l1:/$ cat /proc/partitions 
major minor  #blocks  name

   7        0      55952 loop0
   7        1       9284 loop1
   7        3     144044 loop3
   7        4      93560 loop4
   7        5      45960 loop5
   7        6     163996 loop6
 259        0  500107608 nvme1n1
 259        1     512000 nvme1n1p1
 259        2  250961856 nvme1n1p2
 259        3     884736 nvme1n1p3
 259        4          1 nvme1n1p4
 259        5  247745536 nvme1n1p5
 259        6 1000204632 nvme0n1
 259        7  716800000 nvme0n1p1
 259        8  283403264 nvme0n1p2
   7        8      55952 loop8
   7        9     144044 loop9
   7       10       9284 loop10
   7       12     160440 loop12
   7       13      45240 loop13
   7       14      93504 loop14
   7       15      15112 loop15
   7       16      15112 loop16
gus@ns-l1:/$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-4.15.0-76-generic root=UUID=d44cf192-4f87-499a-b58a-573f498fc38a ro recovery nomodeset
gus@ns-l1:/$ cat /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p5 during installation
UUID=d44cf192-4f87-499a-b58a-573f498fc38a /               ext4    errors=remount-ro            0   1
/swapfile                                 none            swap    sw                           0   0
UUID=710a8b10-00f4-4de9-88d6-d5b76f7593c5 /mnt/data       f2fs    defaults                     0   0
UUID=1F11D42B4B32AACA                     /mnt/win    ntfs    rw,noexec,nouser,auto,async  0   0

I notice that the UUID seems to match what's in fstab.

  • Also worth noting: There doesn't seem to be anything I can't do or degraded in recovery mode. Ran full Solr Test Suite in a normal amount of time, and when I train an neural network, it still uses the GPU... and I can run a game on full graphics with no issues.
    – Gus
    Feb 9, 2020 at 19:18
  • Have been running after recovery boot without rebooting for several weeks now.
    – Gus
    Feb 28, 2020 at 15:03
  • Have you tried disabling secure boot? This looks like it could be having problems with being allowed to load your kernel modules.
    – Joe
    Mar 2, 2020 at 7:08
  • Last screenshot looks like it's almost done, it just doesn't find the root FS and specifying a different one with root=/dev... would work. Can you paste /proc/partitions and /proc/cmdline?
    – golimar
    Mar 2, 2020 at 9:50

2 Answers 2


Checkout golimar comment first and be sure the wanted UUID is present:

It seems to be a problem with your nvme setup. The last message before dying is "Identify Controller failed" and after that, it can't find the UUID which makes sense if your system can't read correctly from it.

  • Check your bios options if you support booting from nvme SSD (which should be fine because your windows works, but double check)
  • If you updated your firmware you should also update your chipset driver (and vice versa)

To diagnose and fix try the following:

boot with an ubuntu usb thumbdrive, check with "blkid" what devices can be seen, some bios changes might have flipped the disk from AHCI to something weird that linux doesn't like, or the UUID might have changed. If you can't see the disk at all then check that it's set to AHCI. I've known some NVMe systems configured to use Intel's RST but from linux perspective the disk is unavailable.

Your can then overcome this hurdle either temporarily with grub or by mounting and modifying the original root filesystem. Grub option offered here:

When you identify the root drive make a note of it's path as a /dev/sdXX device, then pause grub during startup and change the UUID part of the command line to "root=/dev/sdXX" instead, then continue with the boot. If you get your system up and running once with this method you can then fix /etc/fstab and rerun the grub installation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .