Anyone had success with getting linux to boot from an nvme disk? I've been fighting with UEFI and Arch Linux all day now, trying to get a new computer to even recognize the nvme disk as a boot device. (Last time I encountered this problem I gave up and installed an ordinary HD to boot from.) For what it's worth, I have disabled Secure Boot, reformatted the nvme disk to have a new EFI partition without Windows, a swap partition, and a root partition; I'm trying to use efibootmgr (so no loading of a further bootloader), and, as far as I can tell, identified all the right partitions by device name or PARTUUID. Still no go. I even tried adding the parameter nvme_load=YES into the "root" part of the efibootmgr, and also adding nvme and vmd as modules in mkinitcpio.conf, all without any success. If necessary I'll just punt and install a regular HD to boot from, but that rather takes away from having an nvme disk in the first place. (Over the years I've learning to approach installing Linux with fear and loathing, with almost all the problems being with the bootloader -- from LILO through GRUB and GRUB2 now down to UEFI.) Any suggestions welcome! I didn't want to spend my weekend doing this. -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
On Fri, 19 Nov 2021 at 21:09, Peter King via talk <talk@gtalug.org> wrote:
Anyone had success with getting linux to boot from an nvme disk? I've been fighting with UEFI and Arch Linux all day now, trying to get a new computer to even recognize the nvme disk as a boot device. (Last time I encountered this problem I gave up and installed an ordinary HD to boot from.) For what it's worth, I have disabled Secure Boot, reformatted the nvme disk to have a new EFI partition without Windows, a swap partition, and a root partition; I'm trying to use efibootmgr (so no loading of a further bootloader), and, as far as I can tell, identified all the right partitions by device name or PARTUUID. Still no go. I even tried adding the parameter nvme_load=YES into the "root" part of the efibootmgr, and also adding nvme and vmd as modules in mkinitcpio.conf, all without any success. If necessary I'll just punt and install a regular HD to boot from, but that rather takes away from having an nvme disk in the first place.
(Over the years I've learning to approach installing Linux with fear and loathing, with almost all the problems being with the bootloader -- from LILO through GRUB and GRUB2 now down to UEFI.)
Any suggestions welcome! I didn't want to spend my weekend doing this.
Hi Peter. I'm pretty sure I have Linux installed on an NVMe disk somewhere. I apologize that I'm not sure where: most of my machines are "older," but not all - however, I have enough of them that I'm not sure where that NVMe disk is. The point is: if it's in this house, I installed Linux on it and it evidently wasn't a problem because I don't remember it. I would suggest downloading and installing a recent Fedora. You've chosen Arch: that's a hard row to hoe. I'm not saying you should change distros, but installing Fedora abstracts away a LOT of the difficult work Arch insists you do by hand (I've installed both, recently). If installing Fedora works, A) you've proven this computer can be made to work with Linux, and B) the hard drive may be formatted in a useful way for another attempt at Arch. Or you could (and I think this might be wise initially) install Arch as a secondary OS to Fedora. With that in mind, you could use Fedora to format two 32G OS partitions, and an all-the-rest-of-the-drive partition as /home/. Just a thought. -- Giles https://www.gilesorr.com/ gilesorr@gmail.com
I have several workstations at the office running Ubuntu 20.04LTS off NVMes using a completely default UEFI configuration (Secure boot enabled). So the issue is not Linux in general but Arch in particular.
On Nov 20, 2021, at 10:37, Giles Orr via talk <talk@gtalug.org> wrote:
On Fri, 19 Nov 2021 at 21:09, Peter King via talk <talk@gtalug.org <mailto:talk@gtalug.org>> wrote:
Anyone had success with getting linux to boot from an nvme disk? I've been fighting with UEFI and Arch Linux all day now, trying to get a new computer to even recognize the nvme disk as a boot device. (Last time I encountered this problem I gave up and installed an ordinary HD to boot from.) For what it's worth, I have disabled Secure Boot, reformatted the nvme disk to have a new EFI partition without Windows, a swap partition, and a root partition; I'm trying to use efibootmgr (so no loading of a further bootloader), and, as far as I can tell, identified all the right partitions by device name or PARTUUID. Still no go. I even tried adding the parameter nvme_load=YES into the "root" part of the efibootmgr, and also adding nvme and vmd as modules in mkinitcpio.conf, all without any success. If necessary I'll just punt and install a regular HD to boot from, but that rather takes away from having an nvme disk in the first place.
(Over the years I've learning to approach installing Linux with fear and loathing, with almost all the problems being with the bootloader -- from LILO through GRUB and GRUB2 now down to UEFI.)
Any suggestions welcome! I didn't want to spend my weekend doing this.
Hi Peter.
I'm pretty sure I have Linux installed on an NVMe disk somewhere. I apologize that I'm not sure where: most of my machines are "older," but not all - however, I have enough of them that I'm not sure where that NVMe disk is. The point is: if it's in this house, I installed Linux on it and it evidently wasn't a problem because I don't remember it.
I would suggest downloading and installing a recent Fedora. You've chosen Arch: that's a hard row to hoe. I'm not saying you should change distros, but installing Fedora abstracts away a LOT of the difficult work Arch insists you do by hand (I've installed both, recently). If installing Fedora works, A) you've proven this computer can be made to work with Linux, and B) the hard drive may be formatted in a useful way for another attempt at Arch. Or you could (and I think this might be wise initially) install Arch as a secondary OS to Fedora. With that in mind, you could use Fedora to format two 32G OS partitions, and an all-the-rest-of-the-drive partition as /home/.
Just a thought.
-- Giles https://www.gilesorr.com/ <https://www.gilesorr.com/> gilesorr@gmail.com <mailto:gilesorr@gmail.com> --- Post to this mailing list talk@gtalug.org <mailto:talk@gtalug.org> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk <https://gtalug.org/mailman/listinfo/talk>
Thanks to Giles and Alex for reporting their experiences, with Fedora and Ubuntu respectively. Since the computer runs off a live USB flash drive with Arch, it is capable of doing so -- it really must be something very very particular in getting the nvme disk recognized early enough on in the boot process, something that these other distros take care of automatically. The "obvious" suggestion, given the symptoms, are that some driver needs to be loaded right away to allow linux to recognize the nvme disk as bootable. The culprits most often suggested are the nvme and the vmd modules. I did try putting them in mkinitcpio and then rebuilding the initramfs image that Arch then uses to boot, without success. But perhaps I should try that again with a little more patience and care. I have Arch running just fine on all my other computers, having fallen back there when I finally ran out of patience with Gentoo over some of their architecture decisions, so if possible I'd like to run Arch on this one. Giles's dual-boot suggestion is very clever and I may try that if another assault on the initramfs doesn't pan out. Thanks! -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
When USB booting was in its infancy, you had to give time for USB to settle down and come online. "rootdelay=" kernel option was what you used. Try that. On 11/20/21 1:56 PM, Peter King via talk wrote:
Thanks to Giles and Alex for reporting their experiences, with Fedora and Ubuntu respectively. Since the computer runs off a live USB flash drive with Arch, it is capable of doing so -- it really must be something very very particular in getting the nvme disk recognized early enough on in the boot process, something that these other distros take care of automatically.
The "obvious" suggestion, given the symptoms, are that some driver needs to be loaded right away to allow linux to recognize the nvme disk as bootable. The culprits most often suggested are the nvme and the vmd modules. I did try putting them in mkinitcpio and then rebuilding the initramfs image that Arch then uses to boot, without success. But perhaps I should try that again with a little more patience and care.
I have Arch running just fine on all my other computers, having fallen back there when I finally ran out of patience with Gentoo over some of their architecture decisions, so if possible I'd like to run Arch on this one. Giles's dual-boot suggestion is very clever and I may try that if another assault on the initramfs doesn't pan out.
Thanks!
--- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On 2021-11-20 13:56, Peter King via talk wrote:
The "obvious" suggestion, given the symptoms, are that some driver needs to be loaded right away to allow linux to recognize the nvme disk as bootable.
Also, check your BIOS version. My (fairly elderly) motherboard needed a BIOS update to boot from nvme. Stewart
Stewart, I hate to hijack a thread, but it is possible any personal replies from you are getting blocked. reaching out because there is a person overseas who might wish to buy one of the dectalk USB boxes you once wrote of building here. Can you drop me an off line post, and if it bounces let me know here so I can share another way to reach me? Thanks, Karen On Sat, 20 Nov 2021, Stewart C. Russell via talk wrote:
On 2021-11-20 13:56, Peter King via talk wrote:
The "obvious" suggestion, given the symptoms, are that some driver needs to be loaded right away to allow linux to recognize the nvme disk as bootable.
Also, check your BIOS version. My (fairly elderly) motherboard needed a BIOS update to boot from nvme.
Stewart --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On 2021-11-20 18:39, Karen Lewellen wrote:
reaching out because there is a person overseas who might wish to buy one of the dectalk USB boxes you once wrote of building here.
briefly (in case my mails to you are getting blocked: I will try an offlist response): I'm no longer involved in assistive tech, as the funding for my position ran out in March. I do, however, now run a mail-order electronics company. Unfortunately, the speech board is no longer made and the few that suppliers have in stock are expensive. cheers, Stewart
Hi Stewart, Thanks for connecting this way. If you do not mind writing anyway, please do. These units retail for about $900 u. s., a price this person was prepared to pay. Meaning expensive for one person may be doable for another. Cheers, Kare On Sun, 21 Nov 2021, Stewart C. Russell via talk wrote:
On 2021-11-20 18:39, Karen Lewellen wrote:
reaching out because there is a person overseas who might wish to buy one of the dectalk USB boxes you once wrote of building here.
briefly (in case my mails to you are getting blocked: I will try an offlist response): I'm no longer involved in assistive tech, as the funding for my position ran out in March. I do, however, now run a mail-order electronics company. Unfortunately, the speech board is no longer made and the few that suppliers have in stock are expensive.
cheers, Stewart
--- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On Fri, Nov 19, 2021 at 09:09:53PM -0500, Peter King via talk wrote:
Anyone had success with getting linux to boot from an nvme disk? I've been fighting with UEFI and Arch Linux all day now, trying to get a new computer to even recognize the nvme disk as a boot device. (Last time I encountered this problem I gave up and installed an ordinary HD to boot from.) For what it's worth, I have disabled Secure Boot, reformatted the nvme disk to have a new EFI partition without Windows, a swap partition, and a root partition; I'm trying to use efibootmgr (so no loading of a further bootloader), and, as far as I can tell, identified all the right partitions by device name or PARTUUID. Still no go. I even tried adding the parameter nvme_load=YES into the "root" part of the efibootmgr, and also adding nvme and vmd as modules in mkinitcpio.conf, all without any success. If necessary I'll just punt and install a regular HD to boot from, but that rather takes away from having an nvme disk in the first place.
(Over the years I've learning to approach installing Linux with fear and loathing, with almost all the problems being with the bootloader -- from LILO through GRUB and GRUB2 now down to UEFI.)
Any suggestions welcome! I didn't want to spend my weekend doing this.
I tried it 4 or 5 years ago when I was building a machine for a friend with NVMe. I tested the Debian installer at the time since it had recently added nvme support and I wanted to see if it worked. No problems. That was a desktop system with an Asus motherboard. I know some laptops have done idiotic things to do with intel's raid controller that makes linux have trouble even detecting the nvme disk. efibootmgr is of course NOT a boot loader, it is a configuration tool for setting the UEFI nvram for which boot loaders you want. You still need a bootloader (normally grub2). grub2 normally automatically takes care of telling efibootmgr what nvram settings it needs. -- Len Sorensen
| From: Peter King via talk <talk@gtalug.org> | Anyone had success with getting linux to boot from an nvme disk? Installation just worked for me (Fedora). But I've only installed them in recent computers. Mind you, I might be using knowledge that I don't remember I'm using. Back in the Haswell days, firmware would not boot from NVMe. I don't remember when that changed but it was several Intel generations ago. Computers built as complete units (i.e. not sold as parts to be assembled) sometimes have very limited firmware setup screens. In particular it can sometimes be very hard to set a boot target. But if I remember correctly, your computer was assembled from components by you or your dealer. One funny trick: have one ESP (EFI System Partition) on the system, even if there are two drives. I do that sometimes. That means that you steer the firmware between .efi files in that ESP rather than between drive-and-thus-ESPs. I'm not advocating this. | (Over the years I've learning to approach installing Linux with fear and | loathing, with almost all the problems being with the bootloader -- from | LILO through GRUB and GRUB2 now down to UEFI.) Do it enough and it becomes second nature? I claim to have no problems but I just upgraded to Fedora 35 on my main desktop and had the nvidia driver fail (because my card is too old). Grrr.
On Mon, Nov 22, 2021 at 5:34 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: Peter King via talk <talk@gtalug.org>
| Anyone had success with getting linux to boot from an nvme disk?
Installation just worked for me (Fedora). But I've only installed them in recent computers. Mind you, I might be using knowledge that I don't remember I'm using.
Back in the Haswell days, firmware would not boot from NVMe. I don't remember when that changed but it was several Intel generations ago.
Computers built as complete units (i.e. not sold as parts to be assembled) sometimes have very limited firmware setup screens. In particular it can sometimes be very hard to set a boot target. But if I remember correctly, your computer was assembled from components by you or your dealer.
One funny trick: have one ESP (EFI System Partition) on the system, even if there are two drives. I do that sometimes. That means that you steer the firmware between .efi files in that ESP rather than between drive-and-thus-ESPs. I'm not advocating this.
| (Over the years I've learning to approach installing Linux with fear and | loathing, with almost all the problems being with the bootloader -- from | LILO through GRUB and GRUB2 now down to UEFI.)
Do it enough and it becomes second nature?
I claim to have no problems but I just upgraded to Fedora 35 on my main desktop and had the nvidia driver fail (because my card is too old). Grrr.
If your needs are not overly complex nouveau does a reasonable job. If, on the other had, you are asking a lot from my graphics - - - - well then nouveau may not cut it. Nouveau does multi-monitor far better than nvidia, if your monitors are hdmi - - - - dunno how things will work. Regards
Long overdue follow-up: I never succeeded in getting Arch Linux to boot from an nvme disk, or, for that matter, from a regular SATA disk installed in the system -- trying to use efistub for the purpose. Eventually I gave up and installed grub2 on the SATA disk, it booted the first time through. I suppose it's something odd in the Arch install (other people reported success with other distros) or perhaps my incompetence at using efibootmgr -- though I have set it up on three other systems with no problems. Alternatively, it could be some funky feature of the computer itself (a Lenovo Legion 5 mid-tower). Anyway, the old ways are sometimes the best; grub2 does the job and only adds an annoying few seconds to the boot time. Since I plan to leave the computer on 24/7, that will only be a very occasional inconvenience. Thanks to everyone for your suggestions and advice! -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
On 09/12/2021 22:03, Peter King via talk wrote:
Long overdue follow-up: <snip> Anyway, the old ways are sometimes the best; grub2 does the job and only adds an annoying few seconds to the boot time. Since I plan to leave the computer on 24/7, that will only be a very occasional inconvenience.
I'm late to the party (everyone has already gone home apparently), but this is what I used to boot Arch directly with efi stub and an encrypted root partition: efibootmgr --disk /dev/nvme0n1 --part 1 --create --label "Arch linux" --loader /vmlinuz-linux --unicode 'root=cryptdevice=/dev/nvmen1p3:cryptroot root=/dev/mapper/cryptroot quiet audit=0 pcie_aspm=off rw initrd=\initramfs-linux.img' --verbose Cheers, Jamon
On Thu, Dec 09, 2021 at 10:18:47PM -0500, Jamon Camisso via talk wrote:
I'm late to the party (everyone has already gone home apparently), but this is what I used to boot Arch directly with efi stub and an encrypted root partition:
efibootmgr --disk /dev/nvme0n1 --part 1 --create --label "Arch linux" --loader /vmlinuz-linux --unicode 'root=cryptdevice=/dev/nvmen1p3:cryptroot root=/dev/mapper/cryptroot quiet audit=0 pcie_aspm=off rw initrd=\initramfs-linux.img' --verbose
Huh. I thought you had to use the PARTUUID for the root= section. At least, that's the distinct impression the Arch Linux Wiki wants to give you. Otherwise things look very similar to what I tried, except that I had added an initrd=\amd-ucode entry before the regular initrd entry, and no cryptroot stuff. I wonder what went wrong. -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
participants (10)
-
Alex Kink -
D. Hugh Redelmeier -
Giles Orr -
Jamon Camisso -
Karen Lewellen -
Lennart Sorensen -
o1bigtenor -
Peter King -
Stewart C. Russell -
William Park