From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3ACBC1382C5 for ; Sun, 13 Dec 2020 14:17:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4BDF2E09E2; Sun, 13 Dec 2020 14:17:37 +0000 (UTC) Received: from mail-gw.thundermail.uk (mail-gw.thundermail.uk [149.255.60.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C8D72E09B5 for ; Sun, 13 Dec 2020 14:17:36 +0000 (UTC) Received: from mailgw01.thundermail.uk (mail-gw.thundermail.uk [149.255.60.66]) by mail-gw.thundermail.uk (Postfix) with ESMTPS id 51DA5600324C for ; Sun, 13 Dec 2020 14:17:33 +0000 (GMT) X-ASG-Debug-ID: 1607869052-055413665b1dc5080001-LfjuLa Received: from cloud307.thundercloud.uk (cloud307.thundercloud.uk [149.255.58.40]) by mailgw01.thundermail.uk with ESMTP id ROSTGgvh3EDe4c6n (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 13 Dec 2020 14:17:32 +0000 (GMT) X-Barracuda-Envelope-From: confabulate@kintzios.com X-Barracuda-Effective-Source-IP: cloud307.thundercloud.uk[149.255.58.40] X-Barracuda-Apparent-Source-IP: 149.255.58.40 Received: from lenovo.localdomain (230.3.169.217.in-addr.arpa [217.169.3.230]) by cloud307.thundercloud.uk (Postfix) with ESMTPSA id 97CCFC3F19D for ; Sun, 13 Dec 2020 14:17:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kintzios.com; s=default; t=1607869052; bh=S4OJAurQ6KJ3LqgpBQMdIA3PIBAx+Og5cGXRnms6DvM=; h=From:To:Subject; b=d0dubqcbWLb7NIZvYOtRDQYNufYJ/dA1i/fT+Bxb6vkbOaPPv6mfRIkDEhEzXC4uZ IwQAVKNQK7qwq+Qg+tbs6+99ymUNpzw6wlgl2bVYlQGbeGJm1wCw2MHOAW0vVQuXNi zaLxbgTafbaQ0MJ8RVXVzH6ebUacupxlsvw8ASj8= Authentication-Results: cloud307.thundercloud.uk; spf=pass (sender IP is 217.169.3.230) smtp.mailfrom=confabulate@kintzios.com smtp.helo=lenovo.localdomain Received-SPF: pass (cloud307.thundercloud.uk: connection is authenticated) From: Michael To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED] Date: Sun, 13 Dec 2020 14:17:18 +0000 X-ASG-Orig-Subj: Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED] Message-ID: <2630185.BEx9A2HvPv@lenovo.localdomain> In-Reply-To: <9b8cf567-8699-6f82-9eaf-83da02c1b456@sys-concept.com> References: <39170f4b-9baf-0b27-0e94-1404f7f2c0ec@sys-concept.com> <69d87162-fe94-6647-7d05-2cad0b28f68d@gmail.com> <9b8cf567-8699-6f82-9eaf-83da02c1b456@sys-concept.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14231878.tv2OnDr8pf"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-PPP-Message-ID: <20201213141732.2471356.81076@cloud307.thundercloud.uk> X-PPP-Vhost: kintzios.com X-Barracuda-Connect: cloud307.thundercloud.uk[149.255.58.40] X-Barracuda-Start-Time: 1607869052 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://149.255.60.66:443/cgi-mod/mark.cgi X-ASG-Orig-Subj: Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED] X-Virus-Scanned: by bsmtpd at thundermail.uk X-Barracuda-Scan-Msg-Size: 7266 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1.9 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86497 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Archives-Salt: af85551c-73b3-4d29-ac73-991dfb4331ec X-Archives-Hash: 1435ff66aea026cb0d247016a28853b5 --nextPart14231878.tv2OnDr8pf Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Michael To: gentoo-user@lists.gentoo.org Reply-To: confabulate@kintzios.com Subject: Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED] Date: Sun, 13 Dec 2020 14:17:18 +0000 Message-ID: <2630185.BEx9A2HvPv@lenovo.localdomain> In-Reply-To: <9b8cf567-8699-6f82-9eaf-83da02c1b456@sys-concept.com> References: <39170f4b-9baf-0b27-0e94-1404f7f2c0ec@sys-concept.com> <69d87162-fe94-6647-7d05-2cad0b28f68d@gmail.com> <9b8cf567-8699-6f82-9eaf-83da02c1b456@sys-concept.com> On Sunday, 13 December 2020 07:42:11 GMT thelma@sys-concept.com wrote: > On 12/12/2020 11:00 PM, Victor Ivanov wrote: > > On 13/12/2020 03:07, thelma@sys-concept.com wrote: > >> if you have UEFI system most likely your "boot" partition is some form > >> of "vfat" > > > > I strongly disagree with this statement. Most Linux distributions, > > including Gentoo, advise (or outright default to) having your /boot > > partition either separate, or having /boot as part of your root > > filesystem. And this is very sensible indeed. > > > > Personally, I would even go further by saying that /boot should be > > journaled (e.g. ext4). Most distros do that by default. Pre-UEFI /boot on a single partition/filesystem used to be formatted as ext2, primarily because /boot is a small fs in size, is written to only occasionally and unless it happened to crash while writing to it not much benefit would be had by adding the journal of ext3/ext4, while adding a fs overhead for the journal and making write operations last longer. VFAT is more fragile than ext2 (in my anecdotal experience) and in addition it does not support symlinks (or hard links). This creates a problem for some boot managers, e.g. GRUB. So, for Linux on conventional installations (Legacy BIOS + separate /boot fs + spinning disk setups) ext2 is a valid fs choice. When /boot is part of the / block device, then the fs type for /boot would necessarily be whatever is chosen for the / partition, as long as the boot manager has the corresponding driver to be able to load it. With the move from spinning disks to SSDs and problem of block size write amplifications cropped up. Last I looked (on 5.4.80-gentoo-r1) it seems ext2 still does not support TRIM, while FAT does: /usr/src/linux $ grep -lr FITRIM fs/ | cut -d/ -f2 | sort | uniq | xargs echo btrfs compat_ioctl.c ecryptfs ext4 f2fs fat gfs2 hpfs jfs nilfs2 ocfs2 xfs So, on spinning disks with a legacy BIOS the /boot partition can be on ext2. On SSDs it makes sense to have /boot on a fs which supports TRIM, e.g. any of the above fs. > > A UEFI set-up only requires the EFI system partition to be vfat. It does > > not require the kernel or the ramdisk to be on it. GRUB2 can be > > configured to install only its own EFI-related files on the EFI system > > partition, then reading the kernel and the grub config file from your > > /boot partition: > > > > # grub-install --efi-directory=/path/to/efi --boot-directory=/boot/efi > > /dev/[nvme...|sd...] > > > > You do not need CSM enabled for this. Right, on UEFI MoBos the ESP partition used by the UEFI firmware to locate and run *.EFI executables must be FAT32. Such .EFI executables stored on the ESP may be OS boot managers/loaders, or other UEFI compatible applications. The boot manager loaded by UEFI is then left to its own mechanisms (boot loader and fs drivers) to load whatever fs the kernel image resides on. NOTE: The UEFI firmware can boot natively linux kernel images without chainloading some 3rd party Boot Manager's .EFI executable like GRUB, rEFInd, syslinux, etc., as long as the EFI stub support has been enabled in the linux kernel and 'root=PARTUUID=...' has been added in the built-in kernel command line entry. > > Unfortunately, sometimes guides put the EFI partition mount point to be > > a directory within the /boot directory (e.g. /boot/efi) which itself can > > be the mount point for the boot partition. This can lead to people > > formatting both as vfat or indeed using the EFI partition itself in lieu > > of a separate /boot partition. I am not suggesting this is what happened > > in your case, but I have seen it happen. If /boot/efi is a directory (it should be according to the UEFI spec) then as far as I know directories cannot be formatted with a fs. > > Now if you use a different boot loader (e.g. rEFInd) it is up to that > > bootloader to have relevant support for the filesystem that your /boot > > partition is using. > > > >> fsck.fat 4.1 (2017-01-24) open: no such file or directory > >> > >> There is a similar related bug filed about it (but I don't know why is > >> it marked resolved) > >> https://bugs.gentoo.org/306119 > > > > I don't think this issue is related wrt the root cause. But > > force-checking for filesystem errors certainly revealed the issue for > > your case: you don't have the fsck.fat binary in your initramfs. As a > > result, the filesystem checking process fails, the boot process is > > interrupted prematurely, and you're dropped into a shell to investigate. > > This is normal behaviour when an error occurs before the boot process > > switches to the real root. > > > > One option is to disable filesystem checking for vfat - like you did, > > another is to make sure that the mkfs.fat binary is included in the > > ramdisk image. I am not sure how the latter would be best achieved with > > genkernel, perhaps others can advise on this. > > > > - Victor I have two UEFI systems which boot fine with an ESP formatted as VFAT and mounted under /boot. They could have been mounted under /boot/EFI, or /boot/ EFI/Gentoo, as an alternative too. The UEFI spec requires each OS loader image to be in a directory under \EFI\. The difference is I do not have a dump directive to back up the /boot fs, unlike Thelma/Joseph in my fstab. My typical fstab entry looks like this: /dev/sda1 /boot vfat noauto,noatime,discard 0 2 and the systems boot fine with it. The EFI Compatibility Support Module (CSM) still initialises hardware on the MoBo using the UEFI firmware, then loads this CSM emulation module to access device paths for legacy OSs which are not compatible with UEFI. So, it is an additional firmware layer which does not make much sense to use on modern MoBos running modern OS systems. I doubt there are many on this list who still boot WinXP natively on their PCs. ;-) > You are absolutely correct. I'm an old timer, before there was no need > for initramfs. Unless you have a special need for initramfs, e.g. separate /usr partition, adding a block device encryption layer, or some other drivers necessary to access/mount the device with the / partition, you can install and run gentoo without initramfs. > One of my 10-year old system is still running /boot with ext2; never had > a problem. > HD is making noise and they system was running 24/7. But it is slowly > failing, might be HD or memory. You can use sys-apps/smartmontools and run some tests followed by 'smartctl -a /dev/....' to find out if the disk reports imminent failure. > I was following the Gentoo handbook, maybe I didn't read it correctly > and/or miss the information on alternative setting. I didn't see any > explanation that I need to have support for "fsck.fat". > I better stay away from any "vfat" format on boot partition, and I don't > see a reason to have initramfs (another complexity). Gentoo is thankfully flexible enough to allow you to make your own choices on configuring your system. Whatever works for you best is a valid choice to make. :-) --nextPart14231878.tv2OnDr8pf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAl/WIm4ACgkQseqq9sKV ZxnYaBAA3T20Hni3UsOPyOkVA6Wwf9vvgpvT35xVX0Tz0nLsrddt9Jc0tGhCM9G2 Bf/AAF1OKHqtgZoKYyqAOXtPKfRhEsR40CKJwMGMUmtyAej+sNHawC39UvkCX9uT fk5sA3C0Z6sNMQ1W+L6C98Bvv1YCKiy/qVd/YwTcyyjJDIcf/UQUoWbHTHw9CScA 4AXMnbUTqFG9s8N5edlJ+783CNUKm0SG68K+jtaRhikQ6+4V/N7tOZRHorolUqCm L+lDa/Gxuo1IfUTiTkBmSWqWIynCLBI8fnJYAshmv+brsE1OZz/amg7LkAuyZJ6j cZF277Ifbu2cLDeX5p64dBdLDOoGblwMsxXkGhSO+0e640wxQjx2xakv9UdfHe+H UtxowSOBA0XysE7s4gEIM9iDlWkCCfD/KILkyfHmDOBOF8wwOh6k8NgLmhlW3+r2 mJRNzw9HmwJy9vjwoOPCybyHrK5KYR7Bt6v68CkGL0PdlQ8VSxTsi5CikGvkH5oi lTDCLfLOOQODitA+LpAwrCRjvH2rvtZxZhIuVMPHxwUOBjKZaZOUHI7UEh01brMJ jVNleDPI4a7f7KVSFQbEw88kq7oWIF3qvDGKQ/KNOsET9L6XguZfKOz9X6WOT8qR V13I27zY58MCGomav8uXDOHUuyok5KFSI8vmPcUpZqQ1AUgp+0k= =Ofmr -----END PGP SIGNATURE----- --nextPart14231878.tv2OnDr8pf--