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:
- I changed
Storage Boot Option Controlto
- I switched
Boot Option 1and
Boot Option 2, and there appears to be no difference as to whether
UEFI 5.0is first
- I changed the BBS Priorities to put UEFI first.
- Reading of issues with IOMMU settings I also tried moving this from auto to enabled
None of these has had any noticible effect.
- 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...
- 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: 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 gus@ns-l1:/$
I notice that the UUID seems to match what's in fstab.