Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #189449 > unrolled thread

BIOS Can Not Find Disk

Back to article view | Back to linux.debian.user

Contents

  BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-01 20:00 +0100
    Re: BIOS Can Not Find Disk "Thomas Schmitt" <scdbackup@gmx.net> - 2017-12-01 21:00 +0100
      Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-02 19:30 +0100
        Re: BIOS Can Not Find Disk "Thomas Schmitt" <scdbackup@gmx.net> - 2017-12-02 20:30 +0100
    Re: BIOS Can Not Find Disk David Christensen <dpchrist@holgerdanske.com> - 2017-12-02 03:00 +0100
      Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-02 05:10 +0100
        Re: BIOS Can Not Find Disk David Christensen <dpchrist@holgerdanske.com> - 2017-12-02 20:40 +0100
          Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-03 04:50 +0100
            Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-04 00:40 +0100
            Re: BIOS Can Not Find Disk David Christensen <dpchrist@holgerdanske.com> - 2017-12-04 06:20 +0100
              Re: BIOS Can Not Find Disk David Christensen <dpchrist@holgerdanske.com> - 2017-12-04 06:30 +0100
                Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-04 15:40 +0100
                  Re: BIOS Can Not Find Disk David Christensen <dpchrist@holgerdanske.com> - 2017-12-05 01:50 +0100
                Re: BIOS Can Not Find Disk David Wright <deblis@lionunicorn.co.uk> - 2017-12-04 16:30 +0100
                  Re: BIOS Can Not Find Disk David Christensen <dpchrist@holgerdanske.com> - 2017-12-05 02:40 +0100
                    Re: BIOS Can Not Find Disk David Christensen <dpchrist@holgerdanske.com> - 2017-12-05 07:00 +0100
                      Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-06 00:20 +0100
                        Re: BIOS Can Not Find Disk David Christensen <dpchrist@holgerdanske.com> - 2017-12-07 07:00 +0100
                    Re: BIOS Can Not Find Disk David Wright <deblis@lionunicorn.co.uk> - 2017-12-05 23:30 +0100
              Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-05 22:50 +0100
          Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-04 03:40 +0100
        Re: BIOS Can Not Find Disk Michael Lange <klappnase@freenet.de> - 2017-12-02 22:40 +0100
          Re: BIOS Can Not Find Disk Felix Miata <mrmazda@earthlink.net> - 2017-12-03 00:20 +0100
            Re: BIOS Can Not Find Disk Michael Lange <klappnase@freenet.de> - 2017-12-03 00:40 +0100
              Re: BIOS Can Not Find Disk deloptes <deloptes@gmail.com> - 2017-12-03 05:50 +0100
            Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-03 11:00 +0100
              Re: BIOS Can Not Find Disk Felix Miata <mrmazda@earthlink.net> - 2017-12-03 12:50 +0100
                Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-03 18:40 +0100
                  Re: BIOS Can Not Find Disk Felix Miata <mrmazda@earthlink.net> - 2017-12-03 19:10 +0100
                    Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-03 20:40 +0100
                  Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-03 20:20 +0100
                    Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2017-12-03 22:00 +0100
                      Re: BIOS Can Not Find Disk Felix Miata <mrmazda@earthlink.net> - 2017-12-03 23:00 +0100
                        Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-03 23:50 +0100
                          Re: BIOS Can Not Find Disk Felix Miata <mrmazda@earthlink.net> - 2017-12-04 00:50 +0100
                            Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-05 00:50 +0100
                              Re: BIOS Can Not Find Disk Felix Miata <mrmazda@earthlink.net> - 2017-12-05 03:40 +0100
                                Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-06 23:20 +0100
                                  Re: BIOS Can Not Find Disk Felix Miata <mrmazda@earthlink.net> - 2017-12-07 00:10 +0100
                                    Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-07 21:50 +0100
                                      Re: (OT) BIOS Can Not Find Disk Felix Miata <mrmazda@earthlink.net> - 2017-12-08 00:10 +0100
        Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-03 11:10 +0100
          Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2018-02-21 04:10 +0100
            Re: BIOS Can Not Find Disk Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-02-21 23:20 +0100
              Re: BIOS Can Not Find Disk Dan Norton <dnorton@mindspring.com> - 2018-02-22 02:20 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#189533

On 12/02/2017 02:35 PM, David Christensen wrote:

[...]
>
> Where is /boot?
>

Possibly, this is a better answer:

$ df -Th
Filesystem                   Type      Size  Used Avail Use% Mounted on
[...]
/dev/sda1                    vfat      992K  855K  138K 87% /boot/efi
/dev/mapper/debian8--vg-tmp  ext4      268M  2.1M  247M 1% /tmp
/dev/mapper/debian8--vg-home ext4      9.1G  616M  8.0G 8% /home
/dev/mapper/debian8--vg-var  ext4      8.2G  1.4G  6.4G 17% /var
[...]

  - Dan

[toc] | [prev] | [next] | [standalone]

#189485

On Fri, 1 Dec 2017 23:07:15 -0500
Dan Norton <dnorton@mindspring.com> wrote:

(...)
> > What bootloader was installed -- LILO, GRUB, GRUB2, whatever? And,
> > where?
> >
> 
> 
> GRUB2 to sda1.
> 

I did not read this thread in detail, so maybe this has already been
discussed, but I have just now been thinking, shouldn't grub go
to /dev/sda instead of /dev/sda1 ?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

It would be illogical to kill without reason.
		-- Spock, "Journey to Babel", stardate 3842.4

[toc] | [prev] | [next] | [standalone]

#189489

Michael Lange composed on 2017-12-02 22:33 (UTC+0100):

> On Fri, 1 Dec 2017 23:07:15 -0500 Dan Norton wrote:

> (...)
>> > What bootloader was installed -- LILO, GRUB, GRUB2, whatever? And,
>> > where?

>> GRUB2 to sda1.

> I did not read this thread in detail, so maybe this has already been
> discussed, but I have just now been thinking, shouldn't grub go
> to /dev/sda instead of /dev/sda1 ?

 OP made it clear his is a multiboot context. Grub on sda works for a first
installation, but guess what happens with the next and subsequent installations
if you allow same with them? Just as traditionally experienced with
re-installation of Windows, each subsequent installation tries to, and typically
does, usurp control from the former, followed by updates to the prior at least
attempting to wrest it back, often with annoying, and time consuming, and
sometimes fatal, consequences. With the complication that is multiboot, some
kind of administrative intervention is inevitably needed.

The option the OP chose is to intervene ab initio. When Grub is installed to an
MBR primary partition, and the MBR contains legacy boot code, and a boot flag is
appropriately set, and the same policy is maintained, a subsequent installation
makes no attempt to usurp control from the first. Ultimate boot control remains
with whichever partition contains the boot flag, a very simple thing to change
when desired from any kind of boot.

EFI and GPT were supposedly created in part to simplify hosting multiple
operating systems, but as OP's threads prove, the real-world post-BIOS/MBR
firmware and partitioning schemes at best seem not to make multiboot any simpler.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#189490

On Sat, 2 Dec 2017 18:09:56 -0500
Felix Miata <mrmazda@earthlink.net> wrote:

> Michael Lange composed on 2017-12-02 22:33 (UTC+0100):
> 
> > On Fri, 1 Dec 2017 23:07:15 -0500 Dan Norton wrote:
> 
> > (...)
> >> > What bootloader was installed -- LILO, GRUB, GRUB2, whatever? And,
> >> > where?
> 
> >> GRUB2 to sda1.
> 
> > I did not read this thread in detail, so maybe this has already been
> > discussed, but I have just now been thinking, shouldn't grub go
> > to /dev/sda instead of /dev/sda1 ?
> 
>  OP made it clear his is a multiboot context. Grub on sda works for a
> first installation, but guess what happens with the next and subsequent
> installations if you allow same with them?

Sure, I know that. A second linux install might override the "primary"
install's grub if you don't watch what you are doing, usually no big
issue though, it should still be possible to boot the primary OS and
reinstall this one's grub if desired. Windows is a pain in the neck of
course, still booting a Live system and reinstalling grub from a chroot
environment seems comparatively easy to me compared to the OP's
troubles ;)

But anyway, I just wanted to mention what struck me when I glanced
through the thread, I have seen similar discussions before where the sda
vs. sda1 issue was actually the problem and somehow was overlooked while
discussing more elaborate technical details.

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

There are always alternatives.
		-- Spock, "The Galileo Seven", stardate 2822.3

[toc] | [prev] | [next] | [standalone]

#189493

Michael Lange wrote:

> Windows is a pain in the neck of
> course, still booting a Live system and reinstalling grub from a chroot
> environment seems comparatively easy to me compared to the OP's
> troubles ;)

Agreed here and this is exactly what I do.
+ grub2 finds windows automatically and perhaps other systems

[toc] | [prev] | [next] | [standalone]

#189497

Le 03/12/2017 à 00:09, Felix Miata a écrit :
> Michael Lange composed on 2017-12-02 22:33 (UTC+0100):
> 
>> On Fri, 1 Dec 2017 23:07:15 -0500 Dan Norton wrote:
> 
>> (...)
>>>> What bootloader was installed -- LILO, GRUB, GRUB2, whatever? And,
>>>> where?
> 
>>> GRUB2 to sda1.
> 
>> I did not read this thread in detail, so maybe this has already been
>> discussed, but I have just now been thinking, shouldn't grub go
>> to /dev/sda instead of /dev/sda1 ?

Sounds like there is some confusion.
When we talk about the location of GRUB, we actually generally refer to 
the location of the boot image (1st stage), in a MBR or a PBR. Here sda1 
is a "BIOS boot" partition. GRUB cannot install its boot image in a BIOS 
boot partition. This type of partition is implicitly used by GRUB to 
install its core image (2nd stage) when installing the boot image in the 
MBR of a GPT disk.

So I guess that the OP means that the core image of GRUB is in sda1, and 
the boot image of GRUB is in the MBR of sda.

>   OP made it clear his is a multiboot context. Grub on sda works for a first
> installation, but guess what happens with the next and subsequent installations
> if you allow same with them? Just as traditionally experienced with
> re-installation of Windows, each subsequent installation tries to, and typically
> does, usurp control from the former, followed by updates to the prior at least
> attempting to wrest it back, often with annoying, and time consuming, and
> sometimes fatal, consequences. With the complication that is multiboot, some
> kind of administrative intervention is inevitably needed.
> 
> The option the OP chose is to intervene ab initio. When Grub is installed to an
> MBR primary partition, and the MBR contains legacy boot code, and a boot flag is
> appropriately set, and the same policy is maintained, a subsequent installation
> makes no attempt to usurp control from the first.

That does not match my experience. A subsequent installation does not 
care about what kind of boot code is in the MBR nor whether a boot flag 
is set. You just tell the installer where you want to install GRUB and 
that's all.

> EFI and GPT were supposedly created in part to simplify hosting multiple
> operating systems,

Not GPT. GPT was just created to handle large disks and large number of 
partitions without the extended partition kludge.

[toc] | [prev] | [next] | [standalone]

#189502

Pascal Hambourg composed on 2017-12-03 10:49 (UTC+0100):

> Felix Miata composed:
...
> So I guess that the OP means that the core image of GRUB is in sda1, and 
> the boot image of GRUB is in the MBR of sda.

 Based on OP's response to

https://lists.debian.org/debian-user/2017/11/msg00563.html

in

https://lists.debian.org/debian-user/2017/11/msg00935.html

I'm pretty sure that was not OP's intent, i.e., none of Grub at all in MBR.
...
>> The option the OP chose is to intervene ab initio. When Grub is installed to an
>> MBR primary partition, and the MBR contains legacy boot code, and a boot flag is
>> appropriately set, and the same policy is maintained, a subsequent installation
>> makes no attempt to usurp control from the first.

> That does not match my experience. A subsequent installation does not 
> care about what kind of boot code is in the MBR nor whether a boot flag 
> is set....

 Grub does not care about boot flags, but when depending on legacy (neutral[1])
MBR code to locate the partition from which to boot, as was the apparent plan by
the OP, it's crucial.

The installers of most Linux distros default to installing Grub to the MBR. Some
make it difficult to determine whether any other option even exists. It's been
several months since I last installed Stretch. I don't remember how it presents
bootloader installation location, or more importantly, if when partition is
selected on a device with no installed operating systems, a separate action is
required to ensure the MBR contains any boot code at all.

[1]
<https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F>
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#189517

On 12/03/2017 06:49 AM, Felix Miata wrote:

> Pascal Hambourg composed on 2017-12-03 10:49 (UTC+0100):
>
>> Felix Miata composed:
> ...
>> So I guess that the OP means that the core image of GRUB is in sda1, and
>> the boot image of GRUB is in the MBR of sda.
>   Based on OP's response to
>
> https://lists.debian.org/debian-user/2017/11/msg00563.html
>
> in
>
> https://lists.debian.org/debian-user/2017/11/msg00935.html
>
> I'm pretty sure that was not OP's intent, i.e., none of Grub at all in MBR.

Yes, no grub in mbr - unless installer insists.


> ...
>>> The option the OP chose is to intervene ab initio. When Grub is installed to an
>>> MBR primary partition, and the MBR contains legacy boot code, and a boot flag is
>>> appropriately set, and the same policy is maintained, a subsequent installation
>>> makes no attempt to usurp control from the first.
>> That does not match my experience. A subsequent installation does not
>> care about what kind of boot code is in the MBR nor whether a boot flag
>> is set....
>   Grub does not care about boot flags, but when depending on legacy (neutral[1])
> MBR code to locate the partition from which to boot, as was the apparent plan by
> the OP, it's crucial.
>
> The installers of most Linux distros default to installing Grub to the MBR. Some
> make it difficult to determine whether any other option even exists. It's been
> several months since I last installed Stretch. I don't remember how it presents
> bootloader installation location, or more importantly, if when partition is
> selected on a device with no installed operating systems, a separate action is
> required to ensure the MBR contains any boot code at all.
>
> [1]
> <https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F>

FWIW, this done just now:

# gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
   MBR: protective
   BSD: not present
   APM: not present
   GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): b
Enter backup filename to save: mbrforgpt
The operation has completed successfully.

Command (? for help): q

# ls -l mbr*
-rw-r--r-- 1 root root 17920 Dec  4 05:47 mbrforgpt

# mc -v mbrforgpt
The above shows 0x55AA at +0x1FE (Boot signature [1]).
Also, the search for 'ERROR:' is not found in the entire 17920 bytes of 
file mbrforgpt.

[1] https://en.wikipedia.org/wiki/Master_boot_record

Apparently, all is in readiness. It's simply that this PC is not loading 
the mbr or anything else from sda. Any other opinions?

[toc] | [prev] | [next] | [standalone]

#189518

Dan Norton composed on 2017-12-04 07:32 (UTC-0500):

 Note your posts are still coming from the future. Today ATM in zone -0500 it is
still the 3rd of December.

> Felix Miata wrote:

>> I'm pretty sure that was not OP's intent, i.e., none of Grub at all in MBR.

> Yes, no grub in mbr - unless installer insists.
...
> FWIW, this done just now:

> # gdisk /dev/sda
> GPT fdisk (gdisk) version 0.8.10

> Partition table scan:
>    MBR: protective
>    BSD: not present
>    APM: not present
>    GPT: present

> Found valid GPT with protective MBR; using GPT.

> Command (? for help): b
> Enter backup filename to save: mbrforgpt
> The operation has completed successfully.

> Command (? for help): q

 I don't see anything above to indicate a boot flag has been set anywhere. That
HP might have firmware that insists one exists.
http://www.lightofdawn.org/wiki/wiki.cgi/BIOSBootGPT

> # ls -l mbr*
> -rw-r--r-- 1 root root 17920 Dec  4 05:47 mbrforgpt

> # mc -v mbrforgpt
> The above shows 0x55AA at +0x1FE (Boot signature [1]).

 That proves a partition table exists, not whether there is requisite code in
the 446 bytes preceding the table.

> Also, the search for 'ERROR:' is not found in the entire 17920 bytes of 
> file mbrforgpt.

 'ERROR: ' you are encountering is coming from the BIOS/firmware, not anything
on the disk.

> [1] https://en.wikipedia.org/wiki/Master_boot_record

> Apparently, all is in readiness. It's simply that this PC is not loading 
> the mbr or anything else from sda. Any other opinions?

 <all, or you wouldn't be getting the ERROR: message. :-p
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#189524

On 12/03/2017 01:04 PM, Felix Miata wrote:
> Dan Norton composed on 2017-12-04 07:32 (UTC-0500):
>
>   Note your posts are still coming from the future. Today ATM in zone -0500 it is
> still the 3rd of December.
>
>> Felix Miata wrote:
>>> I'm pretty sure that was not OP's intent, i.e., none of Grub at all in MBR.
>> Yes, no grub in mbr - unless installer insists.
> ...
>> FWIW, this done just now:
>> # gdisk /dev/sda
>> GPT fdisk (gdisk) version 0.8.10
>> Partition table scan:
>>     MBR: protective
>>     BSD: not present
>>     APM: not present
>>     GPT: present
>> Found valid GPT with protective MBR; using GPT.
>> Command (? for help): b
>> Enter backup filename to save: mbrforgpt
>> The operation has completed successfully.
>> Command (? for help): q
>   I don't see anything above to indicate a boot flag has been set anywhere. That
> HP might have firmware that insists one exists.
> http://www.lightofdawn.org/wiki/wiki.cgi/BIOSBootGPT
>
>> # ls -l mbr*
>> -rw-r--r-- 1 root root 17920 Dec  4 05:47 mbrforgpt
>> # mc -v mbrforgpt
>> The above shows 0x55AA at +0x1FE (Boot signature [1]).
>   That proves a partition table exists, not whether there is requisite code in
> the 446 bytes preceding the table.
>
>> Also, the search for 'ERROR:' is not found in the entire 17920 bytes of
>> file mbrforgpt.
>   'ERROR: ' you are encountering is coming from the BIOS/firmware, not anything
> on the disk.

+1


>> [1] https://en.wikipedia.org/wiki/Master_boot_record
>> Apparently, all is in readiness. It's simply that this PC is not loading
>> the mbr or anything else from sda. Any other opinions?
>   <all, or you wouldn't be getting the ERROR: message. :-p

True, that! :-) There's that business about the pesky bit again. One in 1T.

[toc] | [prev] | [next] | [standalone]

#189523

Le 04/12/2017 à 13:32, Dan Norton a écrit :
> On 12/03/2017 06:49 AM, Felix Miata wrote:
> 
>> Pascal Hambourg composed on 2017-12-03 10:49 (UTC+0100):
>>
>>> Felix Miata composed:
>> ...
>>> So I guess that the OP means that the core image of GRUB is in sda1, and
>>> the boot image of GRUB is in the MBR of sda.
(...)
>> I'm pretty sure that was not OP's intent, i.e., none of Grub at all in 
>> MBR.
> 
> Yes, no grub in mbr - unless installer insists.

Then what you wrote earlier was wrong : GRUB is not installed in 
/dev/sda1, and this partition is useless. As I wrote earlier, a BIOS 
boot partition is used by GRUB to store its core image only when 
installing its boot image in the MBR of the disk. This partition 
replaces the unallocated "embedded area" located between the MBR and the 
first partition on MSDOS disks.

[toc] | [prev] | [next] | [standalone]

#189526

On 12/03/2017 02:16 PM, Pascal Hambourg wrote:
> Le 04/12/2017 à 13:32, Dan Norton a écrit :
>> On 12/03/2017 06:49 AM, Felix Miata wrote:
>>
>>> Pascal Hambourg composed on 2017-12-03 10:49 (UTC+0100):
>>>
>>>> Felix Miata composed:
>>> ...
>>>> So I guess that the OP means that the core image of GRUB is in 
>>>> sda1, and
>>>> the boot image of GRUB is in the MBR of sda.
> (...)
>>> I'm pretty sure that was not OP's intent, i.e., none of Grub at all 
>>> in MBR.
>>
>> Yes, no grub in mbr - unless installer insists.
>
> Then what you wrote earlier was wrong : GRUB is not installed in 
> /dev/sda1, and this partition is useless. As I wrote earlier, a BIOS 
> boot partition is used by GRUB to store its core image only when 
> installing its boot image in the MBR of the disk. This partition 
> replaces the unallocated "embedded area" located between the MBR and 
> the first partition on MSDOS disks.
>

Then, to proceed, remove /dev/sda1 partition followed by grub-install?

[toc] | [prev] | [next] | [standalone]

#189527

Dan Norton composed on 2017-12-03 15:54 (UTC-0500):

> Pascal Hambourg wrote:

>> Dan Norton composed:

>>> Yes, no grub in mbr - unless installer insists.

>> Then what you wrote earlier was wrong : GRUB is not installed in 
>> /dev/sda1, and this partition is useless. As I wrote earlier, a BIOS 
>> boot partition is used by GRUB to store its core image only when 
>> installing its boot image in the MBR of the disk. This partition 
>> replaces the unallocated "embedded area" located between the MBR and 
>> the first partition on MSDOS disks.

> Then, to proceed, remove /dev/sda1 partition followed by grub-install?

 If sda1 is a type EEh partition, doing that will probably dig your hole too
deep to escape from, absent a full partition table wipe. :-(
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#189528

Le 03/12/2017 à 22:51, Felix Miata a écrit :
> Dan Norton composed on 2017-12-03 15:54 (UTC-0500):
> 
>> Pascal Hambourg wrote:
> 
>>> Dan Norton composed:
> 
>>>> Yes, no grub in mbr - unless installer insists.
> 
>>> Then what you wrote earlier was wrong : GRUB is not installed in
>>> /dev/sda1, and this partition is useless. As I wrote earlier, a BIOS
>>> boot partition is used by GRUB to store its core image only when
>>> installing its boot image in the MBR of the disk. This partition
>>> replaces the unallocated "embedded area" located between the MBR and
>>> the first partition on MSDOS disks.
> 
>> Then, to proceed, remove /dev/sda1 partition followed by grub-install?

Removing the partition won't help. It is just useless, it does not harm.

>   If sda1 is a type EEh partition, doing that will probably dig your hole too
> deep to escape from, absent a full partition table wipe. :-(

What are you talking about ? ee is the identifier for the GPT protective 
partition in the MSDOS partition table of the protective MBR. This 
partition is hidden. I am talking about the only real sda1 partition 
that is visible, the one defined in the GPT partition table and is shown 
by fdisk as "BIOS boot". Please do not make things even more confused 
than they are.

[toc] | [prev] | [next] | [standalone]

#189530

Pascal Hambourg composed on 2017-12-03 23:40 (UTC+0100):
...
>>> Then, to proceed, remove /dev/sda1 partition followed by grub-install?

> Removing the partition won't help. It is just useless, it does not harm. 

>>   If sda1 is a type EEh partition, doing that will probably dig your hole too
>> deep to escape from, absent a full partition table wipe. :-(
> 
> What are you talking about ? ee is the identifier for the GPT protective 
> partition in the MSDOS partition table of the protective MBR. This 
> partition is hidden. I am talking about the only real sda1 partition 
> that is visible, the one defined in the GPT partition table and is shown 
> by fdisk as "BIOS boot". Please do not make things even more confused 
> than they are.

To imply that removing a type EEh sda1 might be innocuous and use the term "real
sda1 that is visible" (visible how, in what context(s)?) is to interject
additional confusion. With its removal, sda2 might, depending on the details of
how it was done (how many different partitioning tools have already been
employed on OP's MBR sector?), become sda1, sda3 become sda2, etc., in addition
to voiding its protection and possibly invalidating the table.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#189564

Le 04/12/2017 à 00:40, Felix Miata a écrit :
> Pascal Hambourg composed on 2017-12-03 23:40 (UTC+0100):
> ...
>>>> Then, to proceed, remove /dev/sda1 partition followed by grub-install?
> 
>> Removing the partition won't help. It is just useless, it does not harm.
> 
>>>    If sda1 is a type EEh partition, doing that will probably dig your hole too
>>> deep to escape from, absent a full partition table wipe. :-(
>>
>> What are you talking about ? ee is the identifier for the GPT protective
>> partition in the MSDOS partition table of the protective MBR. This
>> partition is hidden. I am talking about the only real sda1 partition
>> that is visible, the one defined in the GPT partition table and is shown
>> by fdisk as "BIOS boot". Please do not make things even more confused
>> than they are.
> 
> To imply that removing a type EEh sda1 might be innocuous and use the term "real
> sda1 that is visible" (visible how, in what context(s)?) is to interject
> additional confusion.

You're the only one bringing additional confusion.
Nobody but you talked about doing such a stupid thing as removing a type 
ee partition. Dan and I only talked about removing the BIOS boot 
partition sda1.
sda1 cannot be a type ee partition. Type ee can exist only in the MBR, 
and real partitions sda1, sda2... exist in the GPT table.

> With its removal, sda2 might, depending on the details of
> how it was done (how many different partitioning tools have already been
> employed on OP's MBR sector?), become sda1, sda3 become sda2, etc., in addition
> to voiding its protection and possibly invalidating the table.

IME removing a primary partition in MSDOS or any partition in GPT with 
common partitioning tools does not renumber the remaining partitions.

[toc] | [prev] | [next] | [standalone]

#189567

Pascal Hambourg composed on 2017-12-05 00:41 (UTC+0100):

> You're the only one bringing additional confusion.
> Nobody but you talked about doing such a stupid thing as removing a type 
> ee partition. Dan and I only talked about removing the BIOS boot 
> partition sda1.

 In https://lists.debian.org/debian-user/2017/12/msg00089.html

Following is the entirety of what Dan wrote:

 "Then, to proceed, remove /dev/sda1 partition followed by grub-install?"

Nothing in that post makes it unambiguous that an MBR (MSDOS) partitioned disk
was not the subject of discussion.

> sda1 cannot be a type ee partition. Type ee can exist only in the MBR, 
> and real partitions sda1, sda2... exist in the GPT table. 

 The post Dan's quote came from, standing alone, as a whole, was confusion.
Absent clear indication of GPT context, the term "BIOS boot partition" is
ambiguous. It could easily enough be construed as the 16 bytes at LBA 0 address
01BEh, which in BIOS/MSDOS partitioning context is sda1.

Regardless, no partition needed to be removed, regardless of type, whether legal
or not, and better safe than sorry, which was why I wrote what I wrote.

[I wrote]
>> With its removal, sda2 might, depending on the details of
>> how it was done (how many different partitioning tools have already been
>> employed on OP's MBR sector?), become sda1, sda3 become sda2, etc., in addition
>> to voiding its protection and possibly invalidating the table.

> IME removing a primary partition in MSDOS or any partition in GPT with 
> common partitioning tools does not renumber the remaining partitions.

 I can't speak to how common it may or may not be, but I've used at least one
partitioning tool that expressly features an ability to rearrange partition
entries in an MBR table in either logical or arbitrary order. That definitely
can produce renaming/renumbering as a result, hence what I wrote: "depending on
the details..."
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#189608

Le 05/12/2017 à 03:33, Felix Miata a écrit :
> Pascal Hambourg composed on 2017-12-05 00:41 (UTC+0100):
> 
>> You're the only one bringing additional confusion.
>> Nobody but you talked about doing such a stupid thing as removing a type
>> ee partition. Dan and I only talked about removing the BIOS boot
>> partition sda1.
> 
>   In https://lists.debian.org/debian-user/2017/12/msg00089.html
> 
> Following is the entirety of what Dan wrote:
> 
>   "Then, to proceed, remove /dev/sda1 partition followed by grub-install?"
> 
> Nothing in that post makes it unambiguous that an MBR (MSDOS) partitioned disk
> was not the subject of discussion.

In the context of a GPT partitioned disk, anyone else understands 
without any doubt that /dev/sda1 refers to the partition #1 defined in 
the GPT partition table, not in the protective MBR.

>> sda1 cannot be a type ee partition. Type ee can exist only in the MBR,
>> and real partitions sda1, sda2... exist in the GPT table.
> 
>   The post Dan's quote came from, standing alone, as a whole, was confusion.
> Absent clear indication of GPT context,

Please read again the initial post. It contains absolutely clear 
indication that the disk has a GPT label.

> the term "BIOS boot partition" is ambiguous.

No it is not. It has a perfecly clear definition, and even an entry in 
Wikipedia : <https://en.wikipedia.org/wiki/BIOS_boot_partition>

  It could easily enough be construed as the 16 bytes at LBA 0 address
> 01BEh, which in BIOS/MSDOS partitioning context is sda1.

There is no such "BIOS boot" partition type defined in DOS/MBR partition 
types.

[toc] | [prev] | [next] | [standalone]

#189614

Pascal Hambourg composed on 2017-12-06 23:16 (UTC+0100):

> Felix Miata composed:

>> Nothing in that post makes it unambiguous that an MBR (MSDOS) partitioned disk
>> was not the subject of discussion.

> In the context of a GPT partitioned disk,                               

 That context was missing from post you're complaining about.

> anyone else understands
> without any doubt that /dev/sda1 refers to the partition #1 defined in 
> the GPT partition table, not in the protective MBR.

>>> sda1 cannot be a type ee partition. Type ee can exist only in the MBR,
>>> and real partitions sda1, sda2... exist in the GPT table.

>>   The post Dan's quote came from, standing alone, as a whole, was confusion.
>> Absent clear indication of GPT context,

> Please read again the initial post. It contains absolutely clear 
> indication that the disk has a GPT label.                             

 When the (long) entire thread is read, it eventually becomes apparent that the
OP switched back and forth between GPT and MBR.

The initial thread post was not relevant to the purpose of my post, which was
intended to clarify meaning of the thread post I replied to standing alone.
Critical in my post is it was addressing exclusively the content of the replied
to post. I wasn't writing exclusively for the benefit the OP or thread readers.
On the contrary, I was writing primarily to the mailing list archive, for those
finding it via web search and trying to understand it entirely based on what it
contained.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#189658

Le 07/12/2017 à 00:03, Felix Miata a écrit :
> 
>> In the context of a GPT partitioned disk,
> 
>   That context was missing from post you're complaining about.

That was your post, and it had plenty enough context :
- BIOS boot partition only exists in GPT
- type EE is used in GPT protective MBR

Anyway, people writing to a thread are not going to keep all the context 
in all posts. If a disk is GPT, we're not going to repeat that the disk 
is GPT in every post. Read the whole thread to get the whole context.

>   When the (long) entire thread is read, it eventually becomes apparent that the
> OP switched back and forth between GPT and MBR.

No, when he suggested to remove the BIOS boot partition, the disk was 
GPT all along and hadn't switched to DOS/MBR yet.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web