I assume the step in those instructions that went wrong was: grubby --args="resume=UUID=dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8 resume_offset=2459934" --update-kernel=ALL
I don’t fully understand what that should have been nor will I guess what part of it you got wrong. But to boot despite that, I suggest:
In grub, you can edit the selected entry to remove whatever garbage that grubby command inserted and execute the entry without it.
Either after booting that way, or when booted from a USB, you need to remove the garbage from the actual files.
The files are all the ones in the loader/entries directory of your boot partition, so /boot/loader/entries if you have the system itself booted. If booted in a USB, you need to find and mount your boot partition, navigate there and edit those files.
I’m sure there are more expert ways to fix those files, possibly using some grubby command after you have somehow gotten the correct partition accessible as /boot. But I don’t know either those methods nor exactly what the bad contents of those files currently look like. So I would mount things so that I can edit those files and then clean them all up manually.
If you open one of those files and can’t tell what is garbage added by your wrong grubby command vs. what belongs there, my best suggestion is post the whole file into this thread.
The key thing to take away from this problem is this.
Any reference as you follow from an online link is only a suggestion or example and the commands should never be used verbatim but must be modified to fit your exact system needs. If you don’t understand what needs to be changed don’t use that command until you have ironed out the changes needed.
I hope my post did not Imply that I thought Sanji Bukai had used that command verbatim. I really doubt that is what happened.
I think I correctly estimated that garbage has been added into the files in /boot/loader/entries/ and from my review of the instructions, that step was the plausible place where such insertion of garbage would occur.
So I assume some attempt was made to modify that command to fit the specific computer, but that wasn’t done correctly.
I don’t fully understand what that whole set of instructions is doing. I think I would understand how to adapt such instructions to my own computer. But maybe I’m wrong.
I’m not going to fault someone else for thinking they understood enough and trying it and get a worse than expected mess to clean up. Documentation is rarely good enough to be used without some guessing and experimentation.
I’m aware of the many online instructions (such as just liked above) setting up for and using chroot and dnf reinstall to fix a mess like this. Probably that is a better answer than my answer for this kind of situation.
But that answer is scary for all the same reasons that the original set of instructions that caused this problem is scary. It must be adjusted in non obvious ways to fit the individual system and it does things that are nowhere documented close to well enough to know what result to expect.
I’m personally far more comfortable with directly editing the text files that actually control grub2 during the boot. Then I know exactly what I’m adding or removing from those files.
I don’t know what dnf reinstall shim-* grub2-efi-* grub2-common does to existing incorrect files in /boot/loader/entries. (If that is well documented somewhere please give me a link).
On the real original issue here, I’ve said in many other posts that I’m not a fan of zram anyway. Those were quite an ugly set of hoops to jump through in order to keep using zram but have hibernate start working. I would just switch to using real swap space, so getting hibernate to work would be far simpler.