Kernel panic
Fresh install, it says something about unable to unpack initramfs and then that screen. I used fedora media written to create usb.
I installed fedora 43 before this and it worked just fine.
I have seen this screen before but in a regular fedora install. I had to go into systemd-multi thing in cli to uninstall all nvidia mentions and then boot in nomodeset. But as I said it didn’t happen in fedora 43. Also I don’t know how to go into cli mode in bazzite or if it would even work at all.
I don’t have other options in grub because is a fresh install.
I have disabled tpm and ftpm. Secure boot is disable. Xmp disabled as well 🙁 any ideas?
38 Replies
I don't know, but that's an awesome picture and cat.
the initramfs is a little zip file
essentially it contains some tools
basically everything needed for a little Linux systemIrootfsO
it's role is to serve as a temporary system load some drivers just enough to find the actual system
on the drive or really wherever
if the initramfs doesn't load you have no rootfs to start with
& so you get this error
That makes sense yeah 🙂 but how can I fix it? I installed multiple times and always got this
hmm what is the error you get about not being able to unpack the initramfs?
after all that's the root of the issue
initramfs unpacking failed: invalid magic at start of compressed archive. But it quickly hides and show that other screen in the ss
oh yeah
it should make sense to you now
you might not know what "magic" means
file magic is just some letters or numbers that determine the tyoe of a file
Right, so it can’t open a file that loads at the beginning 😭 but still I don’t know what to do. Thanks for the info though.
it can't open the initramfs
which technically isn't the first file to load the first file to load is the kernel
the kernel is what shows you the kernel panic message
now you might wonder why does the kernel load anyways
even though there's no initramfs
well that's because Linux can technically work without an initramfs
if the correct drivers are built into the kernel
but most Linux systems are too complex
have lots of different drivers for lots of different hardware
so most OSes bundle an initramfs
essentially it sounds like the initramfs is just corrupt
did you re download the ISO before trying to reinstall again?
Yes I redownload and recreated the usb with fedora media writer.
hmmmm
Regular iso, not live
even either system on the ISO live or not has an initramfs
those load fine
so why not the installed copy?
Yeah install completed with no errors at all. It’s just after first boot
tecmically before first boot?
Well yes 😄
i do have a silly idea
what if we were to yoink the working initramfs from the ISO & put it where the installed system expects
fun fact somebody was crazy enough to put the main system on a google drive
for a Linux distro
the initramfs really is just a little OS
it if it has the correct files in there can connect to the internet
Yeah, no you really don't want to do that
That thing is ducktaped
i expected it to be the same ish as the installed one
minus some drivers here & there
as i recall the Nix OS one is the same or at least pretty similar installed vs live
Eh, maybe, with the addition of dracut-live modules, but yeah would say probably won't go as smooth as you might think
Nixos has an already mature system to build their isos from
I kid you not when I'm saying our setup is held by tears as glue
the thing i noticed
is the installed ISO has the equivalent of scan-iso/filename
The what?
the ability to mount & boot a Nix OS iso given the path as a kernel argument
i thought that debian/ubuntu only had this as part of the live-boot package
We have an EFI section, where the grub bootloader is, and then an iso96whatever where the squashfs of the live session root filesystem resides. Then we have the dracut modules that set a writable overlayfs over the rootfs.
That's how we set it up, whenever we are doing something similar or not that gains that capability I'm unsure
i may not understand the structure but sounds like what every distro ever does
the kernel is on the ISO9660 filesystem & there's an efi.img file that acts as the EFI partition to store the grub binaries
grub then loads the kernel & initramfs
Yeah about the same then
the initramfs uses a loopback device to mount the squashfs file as root
overlayfs + a tempfs folder is used to make rootfs writabke
you know what's funny
every modern distro i cam recall off the top of my head
uses squashfs in some way shape or form to boot the installer
most just do the squashfs root+overlayfs technique
except alpine
for which the initramfs is always
/
& extra packages are loaded from archives stored in a folder
but even alpine uses squashfs
to store kernel modules
it gets mounted at /.modloop & a folder or maybe the whole thing gets bind mounted to /lib/modulesthis is what chatgpt told me is missing for ventoy support and it also said dracut is preconfigured to use it
so is that true, or is this a joke because it's AI output
its not a joke
i cant tell if its true i did not verify it
you know how
/ gets mounted as a squashfs image
well the same thing can be done for the ISO itselffor our current isos its not squashfs
its erofs
For what I read, that's a Casper thing
:glorp:
which is like squashfs+
and thats the root
No, pretty sure is squashfs
you really skimped on it
and i was proud
We gave up in the erofs, wasn't any better than ootb squashfs
Needs a lot of fine tweaking
essentially the usual flow is
bootloader > kernel+initramfs > initramfs mounts underlying partition finds squashfs > mounts squashfs as root with rw overlay
what i mean by boot it's own ISO is
bootloader > kernel+initramfs > initramfs mounts a passed in underlying partition > initramfs finds passed in iso on underlying partition > iso is mounted the same way squashfs can be > squashfs is found > squashfs is mounted as / with overlay
really the same thing as normal boot except the ISO is found & mounted as a fike
instead of being assumed to written to a plugged in device
ventoy confuzzles me
instead of just mounting the ISO from a path as i've explained above & which is supported ootb by most distros it makes a virtua;l drive using LVM
by patching the initramfs at boot time
a distro need not support mounting it's own ISO from a path
to work with ventoy
ventoy patches something similar in at boot time
so GPT is wrong about this i thinkWell, whole day trying to fix it. Going back to fedora and no pc in the living room for me 😣 thanks anyway guys