You are not logged in.
Pages: 1
Hi Archers, I am new to this forum and have engaged in a quite difficult task for a novice in Arch: I am doing a fresh install of Arch on my laptop SSD using a btrfs filesystem. I have already succeeded once, but then had problems with a kernel rewrite and my ethernet card was not working... So I am installing the system once more and hope to get it right this time. I am in the "final phases" and while dealing with mkinitcpio -p linux, i get an error:
==> ERROR: file not found: `fsck.btrfs'
==> WARNING: No fsck helpers found. fsck will not be run on boot.
==> ERROR: Hook 'btrfs_advanced' cannot be found.
I guess the first part is not problematic, but the btrfs_advanced hook is giving me second thoughts as I cannot find any posts which describe my error. Is that a serious issue or should I ignore it? Also, when i finally boot into the system I want to make a snapshot of the working configuration so another linux kernel rewrite doesn't happen under my back... How can I do that? I want to install some of the packages in AUR, such as phc-intel, tp_smapi and I hope my installation doesn't leave me with an unworking sistem.
For your information, I followed these two links to set up my laptop:
https://wiki.archlinux.org/index.php/In … Btrfs_root
http://tincman.wordpress.com/2011/01/20 … ios-system
I use GRUB2 as a bootloader and I also documented my procedure thoroughly, if anyone is interested he can look up below:
http://matejzima.dyndns.org/2012/04/11/ … -archbang/
http://matejzima.dyndns.org/2012/04/10/ … -archboot/
http://matejzima.dyndns.org/2012/04/10/ … 200-w-ssd/
Some advice on my further steps would be helpful, as I am not yet befriended with Arch's internal workings. I used FreeBSD before, but never needed to make a kernel rebuild, nonetheless experienced a nonvoluntary mkinitcpio run when I installed from ports, so I need your take on that...
Offline
Hi. btrfs-progs maintainer here. I don't know where the btrfs_advanced hook is supposed to come from (it is not in the official package).
In most cases no hook is needed at all, but if you have your root partition on btrfs over several devices you might need the "btrfs" hook.
Offline
@tomegun: Hi, it is in the wiki: https://wiki.archlinux.org/index.php/In … Btrfs_root, under 6.2.3 mkinitcpio-btrfs, which is quite ambiguous on the part of GRUB2 and the "partitioning". "Subvolume creation" should definitely be written a bit more simplisticly and intuitively, at least when booting with GRUB2. As I have blindly followed the wiki, I did not yet try making a root subvolume and put a /boot partition inside there instead of tying to put it outside the volume. I guess this would simplify snapshoting (and backuping) the whole system from top on. Currently my __active subvolume's boot partition is empty, and if I do my reinstall in the future, I would definitely try putting it under "default subvolume". Is that a good idea? I got my epiphany while reading this well prepared wiki: http://www.funtoo.org/wiki/BTRFS_Fun#Pl … _snapshots . Definitely shows that the idea of subvolumes takes a bit of rewiring of the synapses to understand all the possibilities of subvolume mounting and snapshoting.
As of my previous kernel breakage: it was all my fault as I didn't bother installing sudo and carelessly ran "makepkg --asroot". Everything works beautifully now and I guess I've learnt from my early Arch mistake
Offline
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
ln -s /usr/bin/btrfsck /sbin/fsck.btrfs
This is a simple solution and should do no harm. Worked for me.
Offline
ln -s /usr/bin/btrfsck /sbin/fsck.btrfs
This is a simple solution and should do no harm. Worked for me.
Might silence the error message on boot and won't do any harm but probably will not really work either. Calling semantics of btrfsck and fsck.* differ.
Offline
jcci wrote:ln -s /usr/bin/btrfsck /sbin/fsck.btrfs
This is a simple solution and should do no harm. Worked for me.
Might silence the error message on boot and won't do any harm but probably will not really work either. Calling semantics of btrfsck and fsck.* differ.
I discovered this when I thought came upon the idea of making that links as well. You may not get an error when you make the initramd, but you end up with an error message on every boot, indicating that it is trying to use a given flag. Upon inspecting the btrfsck man page, I discovered that it does not accpet any flags.
Offline
I found this:
http://beefdrapes.partedmagic.com/sourc … fsck.btrfs
and seems to work ok.
Edit: It doesn't work so well when your root partition is btrfs. Obviously the partition is un-mounted and /sbin/btrfsck is not accessible.
Last edited by Anarconda (2012-08-26 18:59:51)
Scientia et sapientia patrimonium humanitatis sunt.
Offline
The link above is dead.
What is the solution? I temporary delete fsck from HOOKS. But it is not the solution.
How to include fsck and force it ignore btrfs?
Offline
That link has moved or is mistyped ..
Offline
Offline
Not sure if this is the right thing to do at all, but how about putting a 0 in the last field of fstab for btrfs partitions?
Offline
btrfs does not want fsck routinely run at bootup like extN filesystems want.
why do you say that ? it is not always a good idea to make fsck at the startup?
Offline
btrfs ensures consistency by virtue of being a CoW filesystem. If you have the space available to write new data, you write the new data, checksum it, and then do an atomic pointer swap in the underlying metadata to point to the newly written data. You are "guaranteed" consistency before and after the operation. I say "guaranteed", because ZFS followed this same mantra and found out that hardware defects can still cause inconsistencies in the data sets. For these rare cases, btrfs implemented a fsck tool. ZFS never did.
This is different from how Ext filesystems work -- in the case of corruption, you may not have consistent data state. Replaying the journal via fsck attempts to fix this. It's necessary to read the superblock and check for an inconsistent state on every mount. This is what fsck does for Ext filesystems.
Offline
btrfs ensures consistency by virtue of being a CoW filesystem. If you have the space available to write new data, you write the new data, checksum it, and then do an atomic pointer swap in the underlying metadata to point to the newly written data. You are "guaranteed" consistency before and after the operation. I say "guaranteed", because ZFS followed this same mantra and found out that hardware defects can still cause inconsistencies in the data sets. For these rare cases, btrfs implemented a fsck tool. ZFS never did.
This is different from how Ext filesystems work -- in the case of corruption, you may not have consistent data state. Replaying the journal via fsck attempts to fix this. It's necessary to read the superblock and check for an inconsistent state on every mount. This is what fsck does for Ext filesystems.
This is an abolsute jewel of information here. Thanks falconindy!
Offline
yes, thanks falconindy
Offline
ln -s /usr/bin/btrfsck /sbin/fsck.btrfs.
Don't do this, for the reasons stated by other replies. btrfs wiki recommends "ln -s /usr/bin/true /sbin/fsck.btrfs" if you want to silence such errors.
Offline
Or simply ignore the error and move on with your life.
And don't bump old theads with outdated information.
Offline
The fsck hook is meant to fsck the root partition before being mounted, so that you don't have to mount ro and then potentially wait for another boot if errors are found. It just makes more sense to fsck at that point. But if you use btrfs for your root filesystem, then you should probably just remove the fsck hook altogether. There is no reason to try to fsck the unfsckable, and the systemd-fsck@.service will take care of any other fsckable filesystems you may have.
Offline
Pages: 1