grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dell BIOS issue reading Disk Extended data


From: Jordan Uggla
Subject: Re: Dell BIOS issue reading Disk Extended data
Date: Wed, 31 Mar 2021 10:24:37 -0700

This should *not* be made default because grub's native drivers don't
get very much testing, and they do cause grub to hang on some
hardware, but you can likely get around this limitation with:

grub-install --target=i386-pc --disk-module native /dev/sdX

If you want to test it without installing grub in this way to your
primary drive(s), you can boot from a grub USB and run "nativedisk" at
the grub shell. This will switch from firmware based disk access to
entirely grub native driver access (while accounting for the device
name changes and updating $prefix accordingly). For safety reasons,
this will disable firmware based access to all drives.

This works by including grub's native drivers in the embedded
core.img. For GPT disks (or arrays), which I assume you're using with
8TB capacity, grub's core.img is embedded in the BIOS Boot Partition.
As long as the BIOS Boot Partition is within 2TB of the beginning of
the disk (usually, it's just the first partition, and is 1MiB large)
you'll be able to load it just fine through INT13 and from that point
on (if your hardware is supported) you'll no longer be depending on
the boot firmware or be affected by its disk access bugs.


On Wed, Mar 31, 2021 at 7:45 AM Guilherme Piccoli
<gpiccoli@canonical.com> wrote:
>
> On Tue, Mar 30, 2021 at 2:43 PM K, Narendra <Narendra.K@dell.com> wrote:
> > > On Fri, Jan 22, 2021 at 3:41 PM Limonciello, Mario
> > > <Mario.Limonciello@dell.com> wrote:
> > > >
> > > > >
> > > > > Hello Dell folks, I'm Guilherme Piccoli from Canonical - first of
> > > > > all, apologies for the out-of-nowhere communication. We've been
> > > > > investigating an issue that seems to date long time ago, and
> > > > > eventually we could narrow it to what appears to be a Dell BIOS bug.
> > > > > Notice I'm also looping a kernel x86 ML and grub-devel, just for the
> > > > > purpose of archiving such discussion in public lists, to help others
> > > > > that may find such an issue in the future.
> > > > >
> > > > > Since I don't have contacts of Dell representatives, I've just
> > > > > raised a list of people from Dell contributing to kernel in the last
> > > > > 2 years - maybe one of you could point me towards the path of a
> > > > > proper contact/channel to discuss such an issue. If not, I'm sorry 
> > > > > for the
> > > noise.
> > > > > Let me detail the problem we're observing - notice all of this is
> > > > > about legacy BIOS mode, not UEFI.
> > > >
> > > > Most of the guys you CC'ed from Dell work on client related things,
> > > > not servers.  So I'll move some of the client guys off of this thread 
> > > > into BCC.
> > > > @K, Narendra can you please raise this with the appropriate team?
> > > >
> > >
> > > Thanks Mario and K, Narendra - do we have any news about that?
> > > Cheers,
> >
> > Hi Guilherme,
> >
> > Sorry for the delay in responding.
> >
>
> No problem Narendra K, thanks for your response!
>
> > I checked with the team about the findings shared in this thread. Please 
> > find the details -
> >
> > The behavior seems to be working as designed. Legacy BIOS Option ROM 
> > implements logical block addressing support only up to 2TB.
> > The option ROM will respond with 2TB as the size when queried by INT13h 
> > function 48h. For booting from volumes > 2TB, UEFI is needed.
>
> So, just confirming, Dell doesn't support > 2TB offsets even using the
> extended 64-bit offset from service 48h? I just want to confirm that
> is a support limitation from Dell, I've tested another vendor and that
> works in their machine, I could address > 2TB devices.
>
> In case this is unsupported by Dell, do you have an official
> documentation I can refer, to our customer?
> Thanks again,
>
> Guilherme
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]