Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)SO
Posts
5
Comments
130
Joined
2 yr. ago

  • I’m pretty clueless at that point. Never seen something like it. Apologies for not actually being able to help out. Hopefully it will be resolved soon, though.

    Right? It's super strange. On a normal system I would try reinstalling GRUB and maybe manually generating the initramfs, maybe compile a new kernel, but idk if I can do that here.

    This is probably not the advice you’d like to hear, but I wonder if rebasing to uBlue’s Kinoite would make any difference. Regardless, wish you the best!

    That's actually really interesting, maybe getting away from the fedora ecosystem would help. I do think uBlue is downstream. But it wouldn't hurt

  • Perhaps I had to be more clear and explicit, boot twice So yeah it's not showing anything from the "first" broken deployment. Just to be empirical,

    • I ran date > time.txt && reboot
    • Tried to boot the new deployment, waited about 10 min
    • reset and booted into working deployment
    • ran journalctl -b -1 and the last entry was 2 seconds after the date output in step one.

    It is not even getting to systemd.

    I tried uninstalling the packages, and rebasing to silverblue. Nothing changed. I think I'm going to just put a pin in it and hope that the next update fixes something haha

    speaking of pins

    If you’re afraid of losing your working deployment, ensure to evoke the sudo ostree admin pin 1 command to pin it.

    This is so important and the first thing I did. I got screwed a few years ago when I first tried silverblue. Everyone talks about how you can just rollback, no one ever mentions that you can lose your last working deployment hahah thanks though

  • No Nvidia, just intel integrated graphics. Its a dell ispiron 7500.

    My system isn't pristine but it's not that bad, and I don't see how any of the packages would cause this problem. I can upgrade fine, there's no conflicts. I could see it messing up if I tried to layer a different bootloader but it's nothing like that. Here's my layered packages anyway

     
        
    LayeredPackages: alacritty bat btop distrobox fish flatpak-builder kpeoplevcard light lsd mako neovim parallel python3-neovim shellcheck swaybg swayfx swayidle swaylock syncthing
                               tailscale tmux virt-manager waybar wlogout wlsunset wofi
    
      

    journalctl shows nothing. That's what I meant by no logs, I should have been clearer. It's not even getting that far. It's like it's stuck in grub, but only when I try the new kernel.

    The only deviation from the vanilla kargs have been for troubleshooting this and I did it in the grub editor so they aren't persistent. I tried removing rhgb changed quiet to verbose and debug and loglevel=7 just to see if anything would happen. It still just hangs

  • i3 is configured to use the program dmenu by default. A common replacement for that is rofi. I use wofi on sway. Rofi has more features, wofi is pretty simple but you can customize with css.

    Sway will read the i3 config you already have if you put it in the sway config folder. Then just download dmenu if you want that same behavior. Some things like mod+enter is binded to i3-sensible-terminal, so if you don't have i3 installed on the box it won't find a terminal to open. The fix is to change the binding to your preferred terminal emulator.

    All in all the transition is pretty painless.

  • We did it at a wildlife rehab center I worked at. If we bought local we would clean out the local bug supply in a couple days. Which happened a couple times when we couldn't get them online or a package got lost.

    Not that I think that's what this is. The packaging could be better, but also you order a box of crickets you get a box of crickets....