[EN] Still having boot Issues

[eriefisher]

As per a previous thread I acquired a used laptop. HP Elitebook 8470p. After an install issue, I tried to create a dual boot but failed, I let the installer take the whole disk. Post install I rebooted but "No bootable medium". So I booted back into the live stick and chrooted in and "grub-install" and "update-grub", rebooted and still "No bootable Medium". No errors reported. I used the live usb again but booted into the installed system. From the installed system, as root, I run "grub-install" and "update-grub" but still no boot. Again, no errors. I booted into the bios to see if there was anything that would prevent a boot but no luck. I did notice though that F9 will bring me to the boot menu and siduction is on the list. If I select it I can boot into the installed system without issue. Great news! So back into the installed system and check efibootmgr.

Code: [Select]

  root@hp8470p:/home/dan# efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000
Boot0000* siduction
Boot0006* Windows Boot Manager

Great, It at least shows up on the list. I tried to see if I could get it to boot on it's own on the next boot/reboot "efibootmgr -n 0000" and it booted fine into the installed system with any interaction from me. So my question is, How can I get it to boot on it's own?

Some info

Code: [Select]

System:
  Host: hp8470p Kernel: 6.5.7-1-siduction-amd64 arch: x86_64 bits: 64
    compiler: gcc v: 13.2.0 Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 wm: xfwm
    dm: SDDM Distro: siduction 2023.1.1 giants - xfce - (202309091902)
    base: Debian GNU/Linux trixie/sid
Machine:
  Type: Laptop System: Hewlett-Packard product: HP EliteBook 8470p
    v: A1029CD10000 serial: <superuser required> Chassis: type: 10
    serial: <superuser required>
  Mobo: Hewlett-Packard model: 179C v: KBC Version 42.38
    serial: <superuser required> UEFI: Hewlett-Packard v: 68ICE Ver. F.63
    date: 10/22/2015
Battery:
  ID-1: BAT0 charge: 67.4 Wh (100.0%) condition: 67.4/67.4 Wh (100.0%)
    volts: 12.4 min: 10.8 model: Hewlett-Packard Primary
    serial: 00001 2022/03/05 status: full
CPU:
  Info: quad core model: Intel Core i7-3610QM bits: 64 type: MT MCP
    arch: Ivy Bridge rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB
  Speed (MHz): avg: 1376 high: 2000 min/max: 1200/3300 cores: 1: 1422
    2: 1200 3: 1587 4: 1200 5: 1199 6: 1200 7: 2000 8: 1200 bogomips: 36716
  Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: AMD Thames [Radeon HD 7550M/7570M/7650M] vendor: Hewlett-Packard
    driver: radeon v: kernel arch: TeraScale-2 pcie: speed: 5 GT/s lanes: 16
    ports: active: LVDS-1 empty: DP-1, DP-2, DP-3, VGA-1 bus-ID: 01:00.0
    chip-ID: 1002:6841 temp: 47.5 C
  Device-2: Chicony Integrated HP HD Webcam driver: uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 bus-ID: 1-1.3:4 chip-ID: 04f2:b230
  Display: x11 server: X.Org v: 1.21.1.8 compositor: xfwm v: 4.18.0 driver:
    X: loaded: radeon unloaded: fbdev,modesetting,vesa dri: r600 gpu: radeon
    display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1600x900 s-dpi: 96
  Monitor-1: LVDS-1 mapped: LVDS model: AU Optronics 0x223e res: 1600x900
    dpi: 132 diag: 355mm (14")
  API: EGL v: 1.5 platforms: device: 0 drv: r600 device: 1 drv: swrast gbm:
    drv: kms_swrast surfaceless: drv: r600 x11: drv: r600 inactive: wayland
  API: OpenGL v: 4.5 vendor: mesa v: 23.2.1-1 glx-v: 1.4 es-v: 3.1
    direct-render: yes renderer: AMD TURKS (DRM 2.50.0 /
    6.5.7-1-siduction-amd64 LLVM 16.0.6) device-ID: 1002:6841
  API: Vulkan v: 1.3.250 surfaces: xcb,xlib device: 0 type: cpu
    driver: mesa llvmpipe device-ID: 10005:0000
Audio:
  Device-1: Intel 7 Series/C216 Family High Definition Audio
    vendor: Hewlett-Packard 7 driver: snd_hda_intel v: kernel bus-ID: 00:1b.0
    chip-ID: 8086:1e20
  Device-2: AMD Turks HDMI Audio [Radeon HD 6500/6600 / 6700M Series]
    vendor: Hewlett-Packard driver: snd_hda_intel v: kernel pcie: speed: 5 GT/s
    lanes: 16 bus-ID: 01:00.1 chip-ID: 1002:aa90
  API: ALSA v: k6.5.7-1-siduction-amd64 status: kernel-api
  Server-1: PipeWire v: 0.3.82 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
Network:
  Device-1: Intel 82579V Gigabit Network vendor: Hewlett-Packard
    driver: e1000e v: kernel port: 5020 bus-ID: 00:19.0 chip-ID: 8086:1503
  IF: enp0s25 state: down mac: a0:2b:b8:2e:74:30
  Device-2: Intel Centrino Advanced-N 6205 [Taylor Peak] driver: iwlwifi
    v: kernel pcie: speed: 2.5 GT/s lanes: 1 bus-ID: 25:00.0 chip-ID: 8086:0082
  IF: wlan0 state: up mac: 84:3a:4b:6f:00:04
Bluetooth:
  Device-1: Primax Rocketfish RF-FLBTAD Bluetooth Adapter driver: btusb v: 0.8
    type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 bus-ID: 1-1.2.3:7
    chip-ID: 0461:4d75
  Report: hciconfig ID: hci0 rfk-id: 0 state: up address: F0:65:DD:6B:65:17
    bt-v: 2.1 lmp-v: 4 sub-v: 420e
Drives:
  Local Storage: total: 223.57 GiB used: 18.77 GiB (8.4%)
  ID-1: /dev/sda vendor: Crucial model: CT240BX500SSD1 size: 223.57 GiB
    speed: 6.0 Gb/s serial: 2226E6434C7B
Partition:
  ID-1: / size: 210.05 GiB used: 18.77 GiB (8.9%) fs: ext4 dev: /dev/sda2
  ID-2: /boot/efi size: 299.4 MiB used: 152 KiB (0.0%) fs: vfat
    dev: /dev/sda1
Swap:
  ID-1: swap-1 type: partition size: 8.8 GiB used: 0 KiB (0.0%) priority: -2
    dev: /dev/sda3
Sensors:
  System Temperatures: cpu: 54.0 C mobo: N/A gpu: radeon temp: 47.5 C
  Fan Speeds (rpm): N/A
Info:
  Processes: 284 Uptime: 32m Memory: total: 8 GiB available: 7.71 GiB
  used: 2.58 GiB (33.5%) Init: systemd v: 254 target: graphical (5)
  default: graphical Compilers: gcc: 13.2.0 alt: 13 Packages: pm: dpkg
  pkgs: 2211 Shell: Bash v: 5.2.15 running-in: tilda inxi: 3.3.30


Code: [Select]

root@hp8470p:/home/dan# fdisk -l
Disk /dev/ram0: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram13: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram14: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram15: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
Disk model: CT240BX500SSD1 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D61EAE1F-7383-4DBF-B6C5-ACEFCA13E7CF

Device         Start       End   Sectors   Size Type
/dev/sda1       4096    618495    614400   300M EFI System
/dev/sda2     618496 450402086 449783591 214.5G Linux filesystem
/dev/sda3  450402087 468857024  18454938   8.8G Linux swap

[hendrikL]

If I understand right, it is a single boot system without windows.
Maybe it helps to remove the windows boot entry using the efibootmgr.

[eriefisher]

I just tried that and no difference but thank you.

[ReinerS]

The HP-BIOS is a little bit tricky.
I can provide you how I made the EFI-Structure, put a screenshot below.
Some BIOS-Setup to follow also.

regards

Reiner

[ReinerS]

Hmm, somehow I would only be able to attach 1 photo.
I try to send them via PM.
regards
Reiner

[eriefisher]

@ReinerS I see the two photos in the post. I will compare with mine. Was there more?? I don't see anything attached to the messages.

[eriefisher]

Comparing mine to what you posted previously.....

/boot/efi/EFI/boot is empty
/boot/efi/EFI/siduction contains grubx64.efi

Looks like this may explain it and why I can select "siduction" when using F9 while starting up. I'll dig some more.

[ro_sid]

[...]
/boot/efi/EFI/boot is empty
/boot/efi/EFI/siduction contains grubx64.efi
 
Looks like this may explain it and why I can select "siduction" when using F9 while starting up. I'll dig some more.

I have never understood, for what reason the EFI/boot directory is created (other than the following, but I would put the contents to the other path directly). When you copy (or move) the EFI/boot to (/boot/efi/)BOOT, then the disk itself, even without an UEFI entry (like "siduction") becomes bootable - this is the way how "external" storage becomes bootable. (Of course only booting whatever EFI/boot would boot.)

Two other things: please (binary) compare the "bootx64.efi" and "grubx64.efi" (in EFI/boot). They might be the same. What, with Linux, I sometimes see, is a (different) addtional entry "shimx64.efi", which is there for the case, that "secure boot" is activated. It, of course, can boot the corresponding (operating) system only, if it is fully "signed".
Then: the "grubx64" in "siduction" shows another date than that in "boot". Any explanation for that?

Finally: to see, what the UEFI "siduction" entry would/does boot, please show what "efibootmgr -v" says; this will show, which file is actually booted, too.

Thanks.

[eriefisher]

[...]
/boot/efi/EFI/boot is empty
/boot/efi/EFI/siduction contains grubx64.efi
 
Looks like this may explain it and why I can select "siduction" when using F9 while starting up. I'll dig some more.

I have never understood, for what reason the EFI/boot directory is created (other than the following, but I would put the contents to the other path directly). When you copy (or move) the EFI/boot to (/boot/efi/)BOOT, then the disk itself, even without an UEFI entry (like "siduction") becomes bootable - this is the way how "external" storage becomes bootable. (Of course only booting whatever EFI/boot would boot.)

So create BOOT and add "siduction" to it??

Two other things: please (binary) compare the "bootx64.efi" and "grubx64.efi" (in EFI/boot). They might be the same. What, with Linux, I sometimes see, is a (different) addtional entry "shimx64.efi", which is there for the case, that "secure boot" is activated. It, of course, can boot the corresponding (operating) system only, if it is fully "signed".
Then: the "grubx64" in "siduction" shows another date than that in "boot". Any explanation for that?

Your referring to Reiner's post? I currently only have the on entry.

Finally: to see, what the UEFI "siduction" entry would/does boot, please show what "efibootmgr -v" says; this will show, which file is actually booted, too.

Thanks.

Code: [Select]

root@hp8470p:/home/dan# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000
Boot0000* siduction HD(1,GPT,f8b4b4cb-db7b-4e98-b4cf-3ff042ecec2b,0x1000,0x96000)/File(\EFI\siduction\grubx64.efi)


[ReinerS]

@eriefisher:
I tried to send you more with 2 PMs.
As I was not sure whether the first one got sent, I did send another one with my Telegram and Mail accounts listed.

regards

Reiner

[ro_sid]

root@hp8470p:/home/dan# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000
Boot0000* siduction   HD(1,GPT,f8b4b4cb-db7b-4e98-b4cf-3ff042ecec2b,0x1000,0x96000)/File(\EFI\siduction\grubx64.efi)

Ok, thanks. So - the (only) program that gets executed for the entry "siduction" is /EFI/siduction/grubx64.efi!

Your referring to Reiner's post? I currently only have the on entry.

Yes, sorry, I only looked at the picture.

So create BOOT and add "siduction" to it??

Yes, you could e.g. do a "cp -a EFI/siduction BOOT", when the current directory is /boot/efi. [It could be, that you have to rename "grubx64.efi" to "bootx64.efi". I do not remember, since EFI/boot always contains bootx64.efi.]
If this works, you did not create a valid "siduction" entry, this is unaltered. But by selecting the disk(!) in the UEFI boot menu you would boot the grub(x64.efi) "grub". It would not explain, why you do not see the "siduction" entry there, though.

[eriefisher]

Well that didn't work either. I tried it both as is and renaming it. I still had to go into F9 and select it to boot. In fact the second attempt actually froze the machine. I had to hard restart.
I don't understand why the files are not created either during the install or post install in chroot or an actual system boot. The bios Just doesn't see the disc as bootable on it's own. I wonder if switching over to systemd-boot would have any effect?

[ro_sid]

Yes, of course you had to press F9, you always (would) have to do it to boot an actually remote/external disk.
My plan was, that you now (after creating "BOOT") get a second way to choose - other than "siduction" - to boot your system and then enter its "index" in the UEFI BootOrder in first place instead of "0000"="siduction"; let us say "000x"="disk1". Then "efibootmgr" should display "000x,0000" in BootOrder.

I don't understand why the files are not created either during the install or post install in chroot or an actual system boot.

I do not quite understand. Everything was installed correctly, already. Otherwise an F9 -> "siduction" boot would not work at all.
Your system 'just" does not honor to do it by itself, i.e. is somehow either ignoring the BootOrder or does not "believe" that the "0000" entry is bootable, when working in "automatic" mode.

I wonder if switching over to systemd-boot would have any effect?

I can not tell you anything decisive about that, but believe to have read, that it (also) depends on UEFI. It just does not need a(nother) boot manager.

[eriefisher]

I see. I understand that I would still need F9 however, it doesn't work and I need to hard restart.

[ro_sid]

I see. I understand that I would still need F9 however, it doesn't work and I need to hard restart.

That is "no good"  , so just remove the "BOOT" thing/directory and you should be in the former state - no damage done.
The "BOOT" (directory-)entry is normally created by the "--removable" or even "--force-extra-removable" option in grub-install. So this should do construct it "correctly". But you have to "fiddle" with the grub-install command to do it. The UEFI variable entry is created by default with grub-install and can just be suppressed by "--no-nvram".

One (last?  ) idea: Do an "fsck" to the EFI-Partition. It is just a vfat partition and sometimes, when the (normally two) FATs do not agree, an "automatic" selection might refuse to boot it. The manual selection and even the "efibootmgr -n" do work in your case, obviously, so the question is, why not the "automatic" one.