59
cant mount home on boot (lemmy.world)
submitted 2 days ago* (last edited 2 days ago) by evasync@lemmy.world to c/linux@lemmy.ml
41 comments fedilink hide all child comments

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?

top 41 comments
sorted by: hot top controversial new old
[-] Max_P@lemmy.max-p.me 21 points 2 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.

[-] evasync@lemmy.world 5 points 2 days ago

yes it is a symlink to /var/home

[-] mvirts@lemmy.world 5 points 1 day ago

So shouldn't you mount your home partition on /var/home instead?

[-] a2part2@lemmy.zip 3 points 23 hours ago

This feels like a winning strategy

[-] evasync@lemmy.world 1 points 2 days ago

the command returns my user dir and a lost+found dir

[-] lurch@sh.itjust.works 4 points 1 day ago

that actually sounds like it's already mounted

[-] possiblylinux127@lemmy.zip 1 points 2 days ago

What's in lost+found

[-] nanook@friendica.eskimo.com 6 points 2 days ago

There well may be hardware issues, but with ext4 it rarely corrupts the entire file system. You might end up with some data not flushed so you'll have some inodes that don't point to anything that you'll remove with fsck upon boot, but btrfs, I've had it corrupt and lose the entire file system. I've used ext2-through-ext4 for as long as they've existed and never lost a file system though back in the ext2 days I had to hand repair them a few times, but ext2 was sufficiently simple that that was not difficult, but within two weeks of turning up a btrfs file system it shit itself in ways I could not recover anything, the entire file system was lost. If I did not have backups, which of course I always do, I would have been completely fuxored. It is my opinion that btrfs and xfs, both of which have advantages, are also both not sufficiently stable for production use.

[-] nanook@friendica.eskimo.com 7 points 2 days ago* (last edited 2 days ago)

rm /home
mkdir /home
make /var/home a symlink to it.
Alternative, edit your /etc/fstab to mount on /var/home.

[-] Telorand@reddthat.com 4 points 2 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.

[-] nanook@friendica.eskimo.com 6 points 2 days ago

@Telorand I am not familiar with that distro, I am however familiar with how mount works. As far as what is immutable and what is not, you can set with chattr +i file/directory or chattr -i file/directory.

[-] evasync@lemmy.world 2 points 2 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

[-] data1701d@startrek.website 2 points 2 days ago

Did you update your initramfs after? The new fstab doesn’t apply until you refresh that

[-] evasync@lemmy.world 2 points 2 days ago

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

[-] data1701d@startrek.website 2 points 1 day ago* (last edited 1 day ago)

Edit: Probably try @nanook@friendica.eskimo.com's solution of systemctl daemon-reload first.

Yes. When booting, your system has an initial image that it boots off of before mounting file systems. You have to make sure the image reflects the updated fstab.

[-] nanook@friendica.eskimo.com 1 points 1 day ago

@data1701d @evasync You don't have to reboot to effect that, systemdctl daemon-reload will reload the /etc/fstab file.

[-] data1701d@startrek.website 1 points 1 day 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.

[-] nanook@friendica.eskimo.com 1 points 1 day ago

@data1701d It will work fine with Debian Bookworm, not sure about older releases, I don't know at what point they switched to systemd controlling that but definitely does work in Bookworm. It should work in most other modern Debian or Ubuntu derived systems as well, but not older versions as systemd taking over this functionality is relatively recent.

[-] data1701d@startrek.website 1 points 1 day ago

On another note, for actually doing it, it looks like Fedora uses Dracut, so you just need to run sudo dracut -f.

[-] DNOS@lemmy.ml 1 points 2 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...

[-] possiblylinux127@lemmy.zip 3 points 2 days ago

Isn't the default filesystem btrfs? Why did you go with ext4

[-] nanook@friendica.eskimo.com 4 points 2 days ago

@possiblylinux127 @evasync I can't speak for them, but I've had btrfs blow up in ways I could not fix. I didn't just lose a file but the entire file system. I have NEVER had this happen in many years with ext4.

[-] possiblylinux127@lemmy.zip 4 points 2 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.

[-] nanook@friendica.eskimo.com 1 points 2 days ago

@possiblylinux127 It was this year. Glad it's working for you. I'll stick with what works for me and has provided adequate performance for years.

[-] secret300@lemmy.sdf.org 3 points 2 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

[-] velox_vulnus@lemmy.ml 2 points 2 days ago

ext4 is just terrible for the inode issue, because you'll be forced to reformat and reinstall again. Anyone using NixOS or Guix with multiple store write operation should not go near it.

[-] Urist@lemmy.ml 4 points 2 days ago

NixOS and ext4 user here with no problems. Care to elaborate?

[-] velox_vulnus@lemmy.ml 5 points 2 days ago* (last edited 2 days ago)

NixOS and ext4 user here with no problems.

Yet. Just like most of the articles out there, this problem will start showing up around 5 months to a year, depending on how much storage you have and how much nixos-rebuild switch/guix system reconfigure you use - I had around 512GB, so I ran out of inodes quickly, and despite have lots of storage space, the system was unusable for me.

Here's the exact issue that even others have talked about:

TL:DR; is, your NixOS and Guix system will break due to high inode usage, preventing you to access shell even after clearing older generations. In most cases, you can not even clear older generations, simply because you ran out of inodes. More about filesystem has been discussed here.

[-] dhhyfddehhfyy4673@fedia.io 2 points 1 day ago

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

[-] velox_vulnus@lemmy.ml 1 points 1 day ago* (last edited 1 day ago)

No, those inodes still won't clear on their own - sure, you'll be able to prolong for a few weeks or months, but then you'll reach a point where you'll end up with just a single generation, and you can do nothing to clear space. The device will mislead you with free space, but they are not accessible, neither can you try to force freeing space by running disk operations manually where the stores are present - because a) that's a bad idea and b) you'll not have the permission to. That's what happened to me, and I had to reinstall the entire system again.

Besides, deleting generations regularly would defeat the point of having a rollback system. Sure, for normal desktop usage, you could live with preserving the last twenty to thirty generations, but this may be detrimental for servers that requires the ability to rollback to every generation possible, or low-end platform constrained with space, and therefore, limited generations.

[-] mvirts@lemmy.world 1 points 1 day ago* (last edited 1 day 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.

[-] velox_vulnus@lemmy.ml 1 points 1 day ago

From Re: Guix System ext4 index full:

Vincent Legoll 写道：

I think the filesystem (or directory) is full of inodes.

No, but it's a similar hard limit, and one that not even ‘df -i’ will warn you about.

Ext4's dir_index feature uses hash tables to look up directory entries, so that for directories with a very large number of items (like /gnu/store!), the kernel doesn't have to do the horribly slow equivalent of:

for i in *; do …; done

Unfortunately, once that hash table fills up, the premier stable Linux file system just… gives up and refuses to write any more data. In a very cryptic way.

The large_dir flag ‘increases the limit’ (the man page does not say by how much) but it doesn't go away.

Your hash table is full of eels,

T G-R

[-] mvirts@lemmy.world 1 points 1 day ago

Thank you for providing the quote!!

[-] psmgx@lemmy.world 1 points 2 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 points 2 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.

[-] nanook@friendica.eskimo.com 2 points 2 days ago* (last edited 2 days ago)

@dustyData @evasync When I install, I generally prepare the partitions ahead of time with gparted, whether or not I create an entirely new partition table depends upon whether it is the only OS on the disk or there are multiple. I'm not using any encrypted file systems, I need the machines to be able to boot without my being present to type in a password or pass phrase. So that is not an issue.

[-] evasync@lemmy.world 1 points 2 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 points 1 day 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.

[-] nanook@friendica.eskimo.com 2 points 1 day ago

@dustyData @evasync I've been working with Linux since 1992, I have a better idea of how I want my disks laid out then an installer script.

[-] dustyData@lemmy.world 1 points 1 day ago* (last edited 1 day 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.

[-] ravhall@discuss.online 0 points 2 days ago

That’s what she said.

this post was submitted on 14 Oct 2024
59 points (98.4% liked)

Linux

47744 readers
1177 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz