[GTALUG] New Build Computer?

D. Hugh Redelmeier hugh at mimosa.com
Sun Jul 26 22:41:50 EDT 2020


| From: Peter King via talk <talk at gtalug.org>

| So in the end I went with a Ryzen 3700X CPU and the Asus Prime X570-Pro
| motherboard, adding in an NVMe drive as well for my boot/root device.  The
| results have been mixed.
| 
| The Good News: When I boot the Arch Linux installation image from a flash
|                drive, then chroot into my old root filesystem, it all seems
| 	       to run smoothly (within the limitations of the chroot).
| 	       Nice and zippy, with good heat monitoring hardware and so
| 	       on.
| 
| The Bad News:  The Asus BIOS will not recognize any of the SATA drives or
|                the NVMe drive as bootable.  I don't know why, since the
| 	       BIOS does see all the drives otherwise.  After some google
| 	       search, I tried enabling CSM, which at least got me as far
| 	       as seeing the other drives in the boot priority list, but,
| 	       again, none are bootable.  My current guess is that it's the
| 	       Secure Boot option, which was enabled by default, and which
| 	       I have no idea how to turn off.  But maybe it's something
| 	       else -- after putting an EFI partition on the NVMe drive 
| 	       and installing the kernel, I did use efibootmgr from inside
| 	       the chroot to try to write the efivars that would select
| 	       that NVMe drive to boot from, but efibootmgr --verbose 
| 	       seemed to indicate that the option was written to the USB
| 	       flash drive instead ... ?


Superstitious mode:

- update the motherboard firmware if there is newer firmware.
  Sometimes things like this are bugs in the firmware.

MBR booting and UEFI booting are very different.  Your old system (and
its disks) might have been set up for MBR booting.  Your new system by
default will only do UEFI booting. You can change this by turning on
CSM and "legacy booting".  Could this be the source of your problems?

- your new system's UEFI firmware, by default, will only offer to boot
  from things that have an ESP (EFI System Partition, a FAT
  filesystem).

- CSM should only be needed if you boot MBR-style (i.e. not UEFI)

- was your old system (from which the disks were removed) using MBR or
  UEFI booting?  If it was using MBR, and you wish to boot from those
  disks, you will need to enable "legacy booting" or whatever
  euphemism the firmware uses.

- it isn't clear to me that it is a good idea to boot using MBR except
  for a short-term rescue mission.  MBR is the (now distant) past.

- MBR partitioning is a dead weight -- it puts low limits on disk
  sizes.  Luckily, Linux uses GUID partitioning these days, with just
  enough gunk to get an MBR BIOS to boot.  So even if your disks are
  set up for MBR booting, they probably use GUID partitioning.

- I don't know an easy way of converting an already installed
  MBR-bootable Linux system into a UEFI-bootable system.

- It might make sense to install a bootable Linux system with at least
  the ESP on your new NVMe
  drive.  UEFI booting involves running some .efi file from the ESP.
  That Linux could mount the filesystems from your old disks (but not
  /boot/esp).


More information about the talk mailing list