linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Goffredo Baroncelli <kreijack@inwind.it>
Cc: Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: GRUB bug with Btrfs multiple devices
Date: Fri, 29 Nov 2019 10:57:40 -0700	[thread overview]
Message-ID: <CAJCQCtQaq7r2G7Ff--n5g2eVknPtKcQjebj-=eoNjM-18hwhKw@mail.gmail.com> (raw)
In-Reply-To: <35b330e9-6ed7-8a34-7e96-601c19ec635c@inwind.it>

On Thu, Nov 28, 2019 at 2:57 PM Goffredo Baroncelli <kreijack@inwind.it> 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

  reply	other threads:[~2019-11-29 17:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26  4:05 GRUB bug with Btrfs multiple devices Chris Murphy
2019-11-26 21:11 ` Goffredo Baroncelli
2019-11-26 23:53   ` Chris Murphy
2019-11-27  1:35     ` Chris Murphy
2019-11-27  6:07       ` Goffredo Baroncelli
2019-11-28  0:42         ` Chris Murphy
2019-11-28 17:58           ` Goffredo Baroncelli
2019-11-28 20:05             ` Chris Murphy
2019-11-28 21:57               ` Goffredo Baroncelli
2019-11-29 17:57                 ` Chris Murphy [this message]
2019-11-29 19:54                   ` Goffredo Baroncelli
2019-11-29 21:17                     ` Chris Murphy
2019-11-30  7:33                       ` Andrei Borzenkov
2019-11-30  8:12                       ` Goffredo Baroncelli
2019-11-30 16:38                         ` Chris Murphy
2019-11-27  6:09     ` Goffredo Baroncelli
2019-11-29 20:50     ` Andrei Borzenkov
2019-11-29 21:11       ` Chris Murphy
2019-11-30  7:31         ` Andrei Borzenkov
2019-11-30 16:31           ` Chris Murphy
2019-11-30 17:02             ` Andrei Borzenkov
2019-11-30 17:14               ` Chris Murphy
2019-11-30 17:34                 ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJCQCtQaq7r2G7Ff--n5g2eVknPtKcQjebj-=eoNjM-18hwhKw@mail.gmail.com' \
    --to=lists@colorremedies.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).