Follow-up on Intel 11th Gen not booting from Live-ISO

Hi there,

This is my first post on this forum, so please be gentle if I do anything wrong. I’m not new to Linux, but quite new to Endeavour, and here I would like to share my experience of installing EOS on my second machine (having happily used EOS on my main machine and decided to use it on the second). It’s an Intel 11 NUC Essential with a Pentium Silver N6005.

inxi -FAZ --no-host

System:
  Kernel: 6.3.2-arch1-1 arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.5
    Distro: EndeavourOS
Machine:
  Type: Mini-pc System: Intel Client Systems product: NUC11ATKPE v: M49846-202
    serial: <superuser required>
  Mobo: Intel model: NUC11ATBPE v: M49844-202 serial: <superuser required>
    UEFI: Intel v: ATJSLCPX.0039.2023.0221.1502 date: 02/21/2023
CPU:
  Info: quad core model: Intel Pentium Silver N6005 bits: 64 type: MCP cache:
    L2: 1.5 MiB
  Speed (MHz): avg: 1396 min/max: 800/3300 cores: 1: 2000 2: 790 3: 2000
    4: 795
Graphics:
  Device-1: Intel JasperLake [UHD Graphics] driver: i915 v: kernel
  Display: x11 server: X.Org v: 21.1.8 driver: X: loaded: modesetting
    dri: iris gpu: i915 resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 23.0.3 renderer: Mesa Intel UHD Graphics (JSL)
Audio:
  Device-1: Intel Jasper Lake HD Audio driver: snd_hda_intel
  API: ALSA v: k6.3.2-arch1-1 status: kernel-api
  Server-1: PipeWire v: 0.3.70 status: active
Network:
  Device-1: Intel Wi-Fi 6 AX201 160MHz driver: iwlwifi
  IF: wlan0 state: down mac: fa:5e:d0:a1:70:fb
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8168
  IF: eno1 state: up speed: 1000 Mbps duplex: full mac: 88:ae:dd:03:68:8b
Bluetooth:
  Device-1: Intel Bluetooth 9460/9560 Jefferson Peak (JfP) driver: btusb
    type: USB
  Report: rfkill ID: hci0 rfk-id: 0 state: down bt-service: disabled
    rfk-block: hardware: no software: yes address: see --recommends
Drives:
  Local Storage: total: 465.76 GiB used: 86.81 GiB (18.6%)
  ID-1: /dev/nvme0n1 vendor: Kingston model: SNVS500G size: 465.76 GiB
Partition:
  ID-1: / size: 227.68 GiB used: 22.73 GiB (10.0%) fs: ext4
    dev: /dev/nvme0n1p2
Swap:
  ID-1: swap-1 type: file size: 512 MiB used: 0 KiB (0.0%) file: /swapfile
Sensors:
  System Temperatures: cpu: 49.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 206 Uptime: 56m Memory: available: 7.51 GiB
  used: 2.88 GiB (38.3%) Shell: Bash inxi: 3.3.27

So I tried to install EOS with the current Endeavouros_Cassini_Nova-03-2023_R1.iso on a USB stick with Ventoy. This went fine on my main machine, but on my second machine I got the same boot errors as described in this thread.

Yes, I know the first suspect in this kind of scenario is always Ventoy and/or some incompatible BIOS function, but after about 3 hours of fiddling around I finally found the boot parameter that allowed me to successfully install EOS on my second machine.

I had to

  • remove nouveau.modeset and radeon.modeset
  • add i915.modeset=1
  • add intel_iommu=on

to the Live-ISO boot parameters.

Or more simply:

Select the nomodeset boot option and replace nomodeset with i915.modeset=1

From there, everything went as smoothly as it did on my main machine, and I am now writing to you on the second machine, for which I almost decided to go back to Mint yesterday, but luckily I was patient and tried to find a workaround.

So I don’t know, and will leave it to the experts, if my post can provide any useful information for the future, but I think that non-booting Live-ISOs are one of the biggest turn-offs you can face when trying to install a new system, so maybe it can be of some help.

Cheers and thanks for such a smooth and elegant distro!

3 Likes

Hi @anon4913548 & welcome to the forum. Out of curiosity did you try any other tools other than ventoy? I have always had trouble using it compared to other tools like imagewriter or dd

No since I used Ventoy on at least a dozen other installs (Manjaro, Mint, Tumbleweed, siduction on three different machines … yes I am/was a hardcore distrohopper!) without any problems. And everything also went fine with Ventoy and EOS on my main machine (AMD based).

This was the first time I experienced boot problems in that particular configuration.

1 Like

Patience is a virtue we should all strive to achieve. Glad you persisted and were able to get EndeavourOS installed. I’m sure this process has helped you learn something along the way. :wink:

1 Like

Well, it sure did, since I got the final idea (intel_iommu=on) in the depths of the Arch forum. There is an answer to everything, you just have to find it :laughing:

What I still haven’t learned is the ‘why’.

All the articles about iommu (which stands for ‘input-output memory management unit’) are very technical, and I can’t figure out why all the other distros I tested didn’t have this problem. But the exact reason is for the experts if they are interested.

1 Like

IOMMU is a component in a memory controller that translates device virtual addresses into physical addresses.

Although it’s function relates more to virtualization so I’m not sure if this was the actual parameter that was needed. Did you try it without? So just the following.

Yes, I tried it without … or let me say, I think I tried it without, otherwise I wouldn’t have looked for another parameter.

However, I just tried booting from the Live-USB again with

  • remove nouveau.modeset and radeon.modeset
  • add i915.modeset=1

and it worked. :face_with_hand_over_mouth:

So either I was too tired yesterday to remember my steps exactly and/or I probably still had some conflicting parameters when I tried i915.modeset=1.

Either way, I guess this shows again how hard it is to catch this kind of thing when all you really want to do is boot and install EOS. I will edit my original post to reflect the new findings.

2 Likes