| Summary: | sys-fs/btrfs-progs-0.19: Missing symlink btrfsck -> fsck.btrfs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | haarp <main.haarp> |
| Component: | [OLD] Core system | Assignee: | Joe Peterson (RETIRED) <lavajoe> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | anton.bugs, bugs_gentoo_org.Tim_OKelly, timmy |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
haarp
2009-10-24 12:09:10 UTC
Well, it seems like this symlink was omitted on purpose. If you look into the btrfs-progs ebuilds you will find the following comment in src_install(): # fsck will segfault if invoked at boot, so do not make this link #dosym btrfsck /sbin/fsck.btrfs Of course you can maybe check if this is still true for latest btrfsck by creating the symlink manually and make the system doing a fsck on the next reboot (shutdown -F -r now). Reassigning to the btrfs-progs maintainer as he might shed some light on this. I just booted with the symlink and fsck.btrfs seemed to have worked just fine. I now had the time to do some testing with a btrfs-partition and there's still a (maybe small) problem. btrfsck doesn't accept any commandline options other than the partition to check which results in error messages when fsck.btrfs gets invoked at boot (Could not open -p). You're right. The problem is still there. I guess it's up to upstream to fix that Hey guys, yes, I had the symlink there originally, but because of the segfault, I removed it. Better at this point to do manual fsck's if you need to. But if upstream improves this, feel free to reopen this bug. Btrfs is not *supposed* to need regular fsck's anyway, AFAIK. *** Bug 327663 has been marked as a duplicate of this bug. *** I had created the symlink and fs check at boot went without errors (used systemd as init system). |
