Bluefin Installer Always Crashes

[omnibli]

Bluefin refuses to install on my HP EliteBook 840 G6. After an entire day of trying various iterations of the install, I have a feeling this is due to a very specific hardware issue rather than anything wrong with the Bluefin ISOs themselves. As such, I decided to post here first instead of jumping straight to the Github issue tracker. If it’s decided that this belongs over there, I am more than willing to open a new issue.

My brain works better in lists, so here’s a collection of information on the laptop, the things I’ve tried, and their results. There’s a sort of TL;DR question at the bottom.

• The laptop
  • I did buy it secondhand, but overall it is in good condition
  • It has two SSDs: a 25 GB drive and a 475 GB drive (intended to be ran as extended volume of 500 GB)
  • I ran SpinRite (level 3) on both drives, and both SSDs were found to be healthy with no damaged sectors
• Installing with bluefin-gts.iso / bluefin-latest.iso
  • The issue:
    • Without fail, the installer crashes when installing the Firefox Flatpak (app/org.mozilla.firefox/x86_64/stable)
    • The error references the flatpak_manager.py and flatpak_installer.py scripts
    • The exact error is a PayloadInstallationError exception which states Error reading file from descriptor: Input/Output error
    • After this error occurs, the installer will completely freeze the computer after about 3-5 minutes of being left idle
      • By completely freeze, I mean even doing ctrl+alt+f1 to open the tmux terminal doesn’t work
      • At this point, the laptop must be hard reset; alt+SysRq commands do nothing, so the kernel fully crashes as well
  • Troubleshooting I have done:
    • I have validated the checksum of the ISOs, and they are not corrupted
    • I have ran the installer’s built-in check and it succeeds
    • I have used the same bluefin-gts.iso to install Bluefin successfully in a VM
    • I have put the images on 3 different USB sticks, all failed in the same spot in the same way
    • I have told the installer to use each of the SSD’s individually instead of grouping them as one volume, both failed in the same spot in the same way
    • After looking at one of the flatpak_*.py scripts (I forget which one), I tried deleting the org.mozilla.firefox folder from the local Flatpak repo, but that didn’t seem to have any effect (it still tried to install FF, had the same exact error)
    • After the installer crashes, if I boot it a second time and select “Recover Bluefin system” from the Troubleshooting menu, it fails to find a valid system and just punts me into the shell
    • I have plugged the USB drives in to different USB ports on opposite sides of the laptop
• Installing with bluefin-dx-gts.iso
  • The issue:
    • This one doesn’t throw any specific errors, it just has a Fatal Python error: Segmentation fault message in the (1) main tmux terminal, followed by an error of the GUI crashing
    • The GUI crashes with installing runtime/org.gnome.Platform/x86_64/45 being listed as the current step
    • As with the previous crash, the entire laptop freezes and requires a hard reset about 3-5 minutes after the crash.
  • Troubleshooting I have done:
    • I have ran the installer’s built-in check and it succeeds
    • Honestly, not a lot else on this one. I don’t really have any leads into where the crash is happening or how it might be remedied
• Installing with aurora-latest.iso
  • The issue:
    • This one is the only one that has had some inconsistency to it
    • I have had it error on installing runtime/org.kde.Platform/x86_64/5.15-23.08
      • Much like the developer Bluefin ISO, this one just segfaults and freezes the entire laptop shortly thereafter
    • I have also had it get past that step and actually start installing Flatpaks
      • Unfortunately I didn’t document which Flatpak it crashed on specifically, and I can’t seem to get it past the previous error right now
      • However I do have a few photos from this crash, and the error says flatpak-error-quark: Aborted due to failure (While pulling runtime/org.kde.Platform/x86_64/5.15-23.08 [...] Invalid compressed data)
  • Troubleshooting I have done:
    • I have ran the installer’s built-in check and it succeeds
    • I have used this ISO to install Aurora successfully in a VM
    • I gave up on this one pretty fast since I… just can’t make heads or tails of it. Plus I’d prefer to install Bluefin over Aurora anyway.

So here’s a simple question amidst way too much information

Is there any way for me to remove org.mozilla.firefox from the list of Flatpaks to install in the regular Bluefin installer? My hope is that skipping the problematic Firefox Flatpak will let the installer finish without issue, and then I would be able to install Firefox through Flathub manually after the first boot configuration. I tried to do this by deleting the org.mozilla.firefox folder, but I assume that didn’t work either due to something akin to OverlayFS causing the files to not actually be deleted (more likely) or the Python script pre-caching the entire package’s data before the installer gives me shell access (less likely).

Any help is greatly appreciated! In my approximately 15 years of using Linux, I have never had this many issues with an install before… I feel like I am going insane lol

[j0rge]

Oh wow, this is definitely an odd one, I had to ready your post three times to believe it!

Can you try the upstream Fedora Silverblue installer? It might be easier to just install it from there and rebase to bluefin. We don’t support it but if it at least saves the laptop then we can walk through it.

[omnibli]

I will try that in the morning… It’s midnight where I live and my brain needs a break from staring at this infernal laptop.

[omnibli]

My dive into insanity continues…

I tried the SilverBlue 40 installer 3 times:

1. It crashed at the “Writing objects” step, I couldn’t get to any debugging info
2. This time, I stayed in the tmux terminal. I got a picture of the kernel crash, I’ll attach it below
3. The third attempt was the same as the first

At this point, I wondered if the BIOS was out of date. The BIOS claims to be on a revision from April 2024 - this is about 1 month behind the release date of the most recent firmware on HP’s website, but the version number is the same. I downloaded the firmware from HP anyway and tried to install it, but every firmware package it installed was the same version as what was already on the device (it showed a “upgrading X from version Y to version Y” message).

So by now I had completely lost my mind and needed something baseline functional to regain my sanity. I downloaded the Debian net installer ISO and… the kernel panics and crashes immediately upon selecting the installer in GRUB with VFS: Unable to mount root fs on unknown-block(1,0) . Supposedly this is some kind of initramfs issue? I couldn’t be bothered to look into this deeper, so I moved on to the Linux Mint installer. It was able to launch the graphical live environment fine, but about 85% of the way through the system install, it also has a message about crashing. Mint doesn’t show me any details about the crash, it just says “there was a crash, we’re sending logs to the dev team automatically.” Apparently, it crashed so hard the laptop turned off while I was typing this, so I can’t dig for the logs anymore.

I have absolutely no idea what to do with this thing. Win10 was happily installed on it when I bought it, so I know that the device is, in some capacity, fully operational. I’ve tried flipping a few of the system settings in the BIOS, like turbo boost and virtualization optimizations, but none of that has made an impact. I could pop it open and see if anything seems awry internally, but after nearly 36 hours of beating my head against this silver aluminum wall I’m starting to think that HP’s BIOS just sucks, or that the CPU microcode has some wonky flaw in it.

Here’s the promised crash picture… I don’t see anything particularly helpful in it, but I’m also not well versed in debugging kernel errors. Weirdly enough, it seems like the installer restarted itself at the end, and when I flipped back to the GUI environment, the first language select screen was visible (albeit at like 25% opacity and totally unresponsive).

[j0rge]

I would start with one of those memtest ISOs and run an overnight memory test, sounds a lot like a hardware issue.

[omnibli]

Memtest is still running, but there’s definitely a defective memory chip on one of the RAM modules… At ~600 MB until ~1 GB, memtest lit up with errors, but the rest of the 24 GB of RAM seemed fine. It’s on test 7/10 and the error count is up to 23,600,000 total errors. Interestingly, it says the max contiguous errors is 1 and the total number of bits wrong in the errors is 1. Maybe there’s just a bad column on it or something. I guess I’ll be buying a new set of RAM sticks soon.

Thanks for your help on this. If the new stick of RAM doesn’t fix it… I’m just going to salvage this thing for parts.