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.
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
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
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
If I understand right, it is a single boot system without windows.
Maybe it helps to remove the windows boot entry using the efibootmgr.
I just tried that and no difference but thank you.
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
Hmm, somehow I would only be able to attach 1 photo.
I try to send them via PM.
regards
Reiner
@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.
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.
Quote from: eriefisher on 2023/10/19, 15:11:33
[...]
/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.
Quote from: ro_sid on 2023/10/19, 17:11:43
Quote from: eriefisher on 2023/10/19, 15:11:33
[...]
/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??
Quote
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.
Quote
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.
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)
@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
Quoteroot@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!
QuoteYour referring to Reiner's post? I currently only have the on entry.
Yes, sorry, I only looked at the picture.
QuoteSo 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.
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?
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.
QuoteI 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.
QuoteI 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.
I see. I understand that I would still need F9 however, it doesn't work and I need to hard restart.
Quote from: eriefisher on 2023/10/20, 00:31:02
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.
I will run fsck and continue to scratch my head.
OK, fsck had no effect on things. It did report a "dirty bit" and removed it though. I decided to try another grub-install with options
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
However, the situation didn't improve any. I started reading through the thread again to see if I missed anything and looking at Reiner's pic. I went in to all the directories in /boot/efi/EFI and copied all the grubx64.efi files to bootx64.efi and then ran update-grub.
IT BOOTS ALL BY ITSELF--------WOOHOO!!!
Thank you @ReinerS and @ro_sid for your time and patience.
Quote from: eriefisher on 2023/10/20, 02:32:32
.... copied all the grubx64.efi files to bootx64.efi and then ran update-grub.
IT BOOTS ALL BY ITSELF--------WOOHOO!!!
:D
Thank you for posting this solution -- it fixed my System76 laptop too.
Good to hear @dibl.