Im giving a go fedora silverblue on a new laptop but Im unable to boot (and since im a linux noob the first thing i tried was installing it fresh again but that didnt resolve it).

its a single drive partitioned to ext4 and encrypted with luks (its basically the default config from the fedora installation)

any ideas for things to try?

  • Max-P@lemmy.max-p.me
    23·
    25 days ago

    The error says /home is a symlink, what if you ls -l /home?

    Since this is an atomic distro, /home might be a symlink to /var/home.

    • Telorand@reddthat.com
      4·
      25 days ago

      Don’t you have that backwards? This is an atomic distro, and you’d want to mkdir /var/home then symlink /home from that, no? Otherwise, you’ll wind up with a home directory that is immutable.

    • evasync@lemmy.worldOP
      2·
      25 days ago

      editing the /etc/fstab didnt work (I just changed the path but not sure if the uuid plays any part) but ill give the rm/mkdir part a go

        • evasync@lemmy.worldOP
          2·
          24 days ago

          No but I rebooted the system after the change. do still need to update it regardless the reboot?

              • data1701d (He/Him)@startrek.websiteEnglish
                1·
                23 days ago

                You might be right. I was thinking of it in terms of a traditional distro, as I use vanilla Debian where my advice would apply and yours probably wouldn’t.

                From what I do know, though, I guess /etc would be part of the writable roots overlaid onto the immutable image, so it would make sense if the immutable image was sort of the initramfs and was read when root was mounted or something. Your command is probably the correct one for immutable systems.

      • DNOS@lemmy.ml
        1·
        24 days ago

        Make sure the uuid matches the uuid of the home partition you want, you can list uuids with blkid I think, big noob here too I just spent my last week trying to figure out why it wouldnt mount my boot partition and the problem was the UUID…

      • Possibly linux@lemmy.zipEnglish
        5·
        24 days ago

        Was that in the last 5 years? If it was btrfs is now far more stable. It has never blown up for me and it has in fact saved my data a few times.

      • secret300@lemmy.sdf.org
        3·
        25 days ago

        I’ve only had this happen once and it turned out it was because my ram was shitting out errors that were saved to disk so it ended up not being btrfs’s fault

            • dhhyfddehhfyy4673@fedia.io
              2·
              24 days ago

              Seems like this can be prevented from reaching that point by properly deleting old generations regularly though right?

                • mvirts@lemmy.world
                  1·
                  24 days ago

                  20 or 30 generations 😹

                  I have space for 1 😭

                  Edit: you’ve got me worried now, is the behavior you’re referring to normal running out of inodes behavior or some sort of bug? Is this specific to ext4 or does it also affect btrfs nix stores?

                  I’ve run across the information that ext4 can be created with extra inodes but cannot add inodes to an existing filesystem.

      • psmgx@lemmy.world
        1·
        25 days ago

        Lol same thing happened to me about 6 months ago. Overheating and/or a failing M2 and system corruption. btrfs got weird and troubleshooting only made it worse.

  • dustyData@lemmy.world
    2·
    24 days ago

    Did you reformat the disk before installing? I’ve seen similar fails when the disk is still encrypted. The installer can’t get a hold of a previously encrypted disk. If there’s no valuable data in the disk, load up a live distro run gparted and nuke the disk blank and pristine again, as gparted doesn’t care about encryption. Then try the installer again.

    • evasync@lemmy.worldOP
      1·
      24 days ago

      no, I just removed them with the live cd and repartitioned it (Im assuming its doing the same thing under the hood?)

      • dustyData@lemmy.world
        1·
        24 days ago

        You should let the installer do the partitioning. Silverblue and immutable systems are nitpicky about it. Specially if luks is involved. The whole point is that you shouldn’t meddle with the system at a low level at all.

          • dustyData@lemmy.worldEnglish
            1·
            24 days ago

            Sorry, I was not replying to you (not an insult). I assume you are interacting from Mastodon from the format of the comment, and getting pinged on replies to other comments (?). I mean, you do you, absolutely not going to diss people who want absolute control over their system. But immutable distros are fundamentally an entirely philosophically different approach from how traditional Linux distros have been packaged and managed in the past. That said, I didn’t make the installers, I’m just reporting what has been my recent experience toying with immutable distros. The whole point is to automate as much as possible of the deployment and management of an OS, and do the least amount of tedious manual troubleshooting. If you don’t like that, all the other distros are still there, they haven’t gone anywhere. The current recommendation for Fedora Atomic based distros is to use specialized tools like Universal Blue that allows the user absolute freedom to deterministically configure a Fedora install that results in an immutable OS. And the installer is actually pretty flexible to let you choose how you want the disks laid out. But, the idea is that you should let the installer do its job, that’s for what it was made. If you want to do everything by hand just use Arch, that’s what Arch is for.