From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40CE4C432C0 for ; Fri, 29 Nov 2019 17:58:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 112F82158A for ; Fri, 29 Nov 2019 17:58:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=colorremedies-com.20150623.gappssmtp.com header.i=@colorremedies-com.20150623.gappssmtp.com header.b="A8IvzZJO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727169AbfK2R56 (ORCPT ); Fri, 29 Nov 2019 12:57:58 -0500 Received: from mail-wm1-f51.google.com ([209.85.128.51]:52054 "EHLO mail-wm1-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726980AbfK2R56 (ORCPT ); Fri, 29 Nov 2019 12:57:58 -0500 Received: by mail-wm1-f51.google.com with SMTP id g206so15036425wme.1 for ; Fri, 29 Nov 2019 09:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorremedies-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rsXjY7pLflFzD6Nh6fAqBVzcZS7mIb93Z2UzousvdLo=; b=A8IvzZJOlzWTwl7MhIrQB53Er2T3QT8nHwzdmFVp3FizkUM5t3dZE0OnhecrHfchej oCnq7HcxMhYyaqG9uPHMrWmWUUtbtmhZd6H6F/KnJszxDR7RvJVnWqaCc4D340R/MYnv cOgQIFIUTRoZagKMxvVfTFUH3IGZJ00ncNVeRRaIYG3gBwjfE5knFE+yUuRoLnBDNFEx vjUm2mlhQw1HJgb46JhTJNvQ0tw3vkbpvs+adPnMQPfrRD2izrqaxvn/I5Mr10PUQ3fh 68cG1NT1LT1hMfmvi0IqnPP4taRWejzBGZlsNzlUQwTNFi1m9rqG3R+CdjqKrO+/FQLL qU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rsXjY7pLflFzD6Nh6fAqBVzcZS7mIb93Z2UzousvdLo=; b=qgWPUri05NTMjNV9UC4c10hsN6zrw8g6Vrj5UAGqfDvyuc/tS94TzboQWURAd/Ac6d cM4PyrCCYvN1nfgluM/3TZytel5ZtkU0caIedZXufis1sNvbEGPhSsJ7VA3ZiqjqWzTr lYU8X5efAEdwekreuvxYXb/aZRU+wd+FmenKaMF6HMSLc2WwgI+SitHW3Wv09ySn54V+ m4IZqpGtI7ZstXPLTPqqtui2BGt/BCuau+sZTRYcX1CO85+1TQncOrFZ+mIayvpijepX /HET8ooTslb3hFdJ3kzoo0Hx6ZKi2pqb75sDxaQZez551ZuGU7CJmvcwJ09TDioU/FeK mJSA== X-Gm-Message-State: APjAAAVHJ+9IIOr3TBNyU2oqcUCAa1ULazlXVp1aIczG3jposKdawmeI l7kMk72AvGIuPy0QGcsRrs+2kqF1iGnp9HsBFnCbCw== X-Google-Smtp-Source: APXvYqw0V7RbkbmktaQpSfumtg17YhyQCu7qEWUNBwJ0T4+p8rJy9BSTP/DgctZAWyGcgqZCc+gr206hSrr4alTOGdM= X-Received: by 2002:a7b:c5d9:: with SMTP id n25mr16348265wmk.8.1575050276155; Fri, 29 Nov 2019 09:57:56 -0800 (PST) MIME-Version: 1.0 References: <12f98aaa-14f0-a059-379a-1d1a53375f97@inwind.it> <69aaf772-9eb0-945a-5277-40895e6901de@inwind.it> <35b330e9-6ed7-8a34-7e96-601c19ec635c@inwind.it> In-Reply-To: <35b330e9-6ed7-8a34-7e96-601c19ec635c@inwind.it> From: Chris Murphy Date: Fri, 29 Nov 2019 10:57:40 -0700 Message-ID: Subject: Re: GRUB bug with Btrfs multiple devices To: Goffredo Baroncelli Cc: Chris Murphy , Btrfs BTRFS Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Thu, Nov 28, 2019 at 2:57 PM Goffredo Baroncelli wrote: > > It seems that my supposition is true: the problem exists independently of btrfs. > It would be useful to see the debug (set debug=all + set pager=1) when doing "ls". It is a not so huge set of information (however it is composed by few pages). OK I did debug=all on the grub command line instead of in the grub.cfg, and it's much more manageable. https://photos.app.goo.gl/75Lbobg39R4D9QUk6 It's a very strange coincidence that these errors only began soon after the Btrfs volume becomes a two device fs. I forgot to mention that while grub.cfg is on hfsplus, Fedora GRUB now uses blscfg.mod by default which goes looking for BLS snippets, which happen to be on /boot/loader/entries, which is on Btrfs. So even drawing the GRUB menu does in fact need to read from the 2 device Btrfs. > Grub sees hd0..hd3 as disks of ~120GB; to be exactly, the size is 125753602048 bytes. The error is reported as unable to access sector 0xea3bfc8, which is locate at 0xea3bf00*512=125753491456 byte, which is less than the previous value... Looks to me that hd0, hd1, hd2, hd3, hd4 are all phantom devices. hd5 is the SSD, /dev/sda. cd0 is the empty dvd-rom drive. > > It seems that GRUB is correct in complaining. It is trying to access a valid disk location which return an error. > Why grub is trying to access this location ? My supposition is that grub is trying to probe a filesystem (or a partition type...) > > The problem seems to be related to the first 4 disks, which have all the same size and are "phantom" disks... > May be that the problem is that GRUB incorrectly detects disks ? > > > > But without rebooting, just repeating the ls for the same devices, I > > don't get the error for hd4 again. > > https://photos.app.goo.gl/M6yraHfgfAsMigaP8 > > My understanding is that GRUB tried to load some external modules (zfs, ufs2, ...) without success. However this tentative was attempted only the first time. This could explain the fact that the error appeared only one time. These errors may be misleading because the Fedora grubx64.efi doesn't contain them, and I've only copied a few GRUB modules from /usr/lib/grub/x86_64-efi to /boot/efi/EFI/fedora/x86_64-efi The default installation on Fedora doesn't copy external modules to the ESP at all, so only the ones already in the grubx64.efi are available. -- Chris Murphy