Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #189449 > unrolled thread
| Started by | Dan Norton <dnorton@mindspring.com> |
|---|---|
| First post | 2017-12-01 20:00 +0100 |
| Last post | 2018-02-22 02:20 +0100 |
| Articles | 20 on this page of 45 — 8 participants |
Back to article view | Back to linux.debian.user
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 1 of 3 [1] 2 3 Next page →
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-01 20:00 +0100 |
| Subject | BIOS Can Not Find Disk |
| Message-ID | <uRYHv-7Wc-3@gated-at.bofh.it> |
Maybe this is the wrong forum, but please bear with me a little bit. This post was sent from a desktop with jessie installed. The problem is it will not boot normally. Network booting has been disabled in the NVRAM setup. After POST there is a one-liner which says it can not find disk. It can be booted with a supergrub2 cd, however. # fdisk -l Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24 Device Start End Sectors Size Type /dev/sda1 2048 411647 409600 200M BIOS boot /dev/sda2 411648 16783359 16371712 7.8G Linux swap /dev/sda3 16783360 151001087 134217728 64G Linux LVM /dev/sda4 151001088 285218815 134217728 64G Linux LVM /dev/sda5 285218816 419436543 134217728 64G Linux LVM /dev/sda6 419436544 553654271 134217728 64G Linux LVM /dev/sda7 553654272 1953525134 1399870863 667.5G Linux filesystem This post is being written with Debian 8 installed on /dev/sda3, above. Apparently, BIOS does not see a bootable device. In the dim past, fdisk could set a partition as "active", which was its euphemism for "bootable". However now: # fdisk /dev/sda Welcome to fdisk (util-linux 2.25.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): a a: unknown command Additional info: # uname -v #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) HP Pro 3400 Series MT BIOS version 7.16 dated 03/23/2012 with no update found. How can /dev/sda1 be defined so that the bios will see it as bootable? Thanks, - Dan
[toc] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-12-01 21:00 +0100 |
| Message-ID | <uRZDz-4U-9@gated-at.bofh.it> |
| In reply to | #189449 |
Hi,
Dan Norton wrote:
> # fdisk -l
> ...
> Disklabel type: gpt
> In the dim past, fdisk
> could set a partition as "active", which was its euphemism for "bootable".
I guess, this applies only to MBR partition tables, not to GPT as on your
disk.
As Pascal stated, there is a bit defined in GPT to be the equivalent of
the "active" bit in MBR partitions. But it looks like "BIOS boot" in the
output of fdisk indicates a particular GPT partition type GUID.
Line 164 and 165 in
https://github.com/karelzak/util-linux/blob/master/libfdisk/src/gpt.c
say
/* Hah!IdontneedEFI */
DEF_GUID("21686148-6449-6E6F-744E-656564454649", N_("BIOS boot")),
Probably MBR code which will look for a boot indicator is not able to
interpret GPT.
Nevertheless, afaik GRUB installs an MBR which knows from where to get
its next program. So the question is rather how to install GRUB or repair
the existing installation. (Beyond my experience, i fear.)
Pascal Hambourg wrote:
> - Partition attribute bit 2 = legacy BIOS bootable.
> ...
> I just wonder how a BIOS would use that, though.
It's not the BIOS which reacts on the "active" bit. It's the MBR program
code which may or may not look for the bit. If it does, then it runs the
program code at the start of the partition.
Package "syslinux" has "mbr.bin" which is supposed to act that way:
http://git.zytor.com/syslinux/syslinux.git/tree/mbr/mbr.S
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-02 19:30 +0100 |
| Message-ID | <uSkI1-4SP-1@gated-at.bofh.it> |
| In reply to | #189452 |
On 12/01/2017 02:58 PM, Thomas Schmitt wrote:
> Hi,
>
> Dan Norton wrote:
>> # fdisk -l
>> ...
>> Disklabel type: gpt
>> In the dim past, fdisk
>> could set a partition as "active", which was its euphemism for "bootable".
> I guess, this applies only to MBR partition tables, not to GPT as on your
> disk.
>
> As Pascal stated, there is a bit defined in GPT to be the equivalent of
> the "active" bit in MBR partitions. But it looks like "BIOS boot" in the
> output of fdisk indicates a particular GPT partition type GUID.
> Line 164 and 165 in
> https://github.com/karelzak/util-linux/blob/master/libfdisk/src/gpt.c
> say
> /* Hah!IdontneedEFI */
> DEF_GUID("21686148-6449-6E6F-744E-656564454649", N_("BIOS boot")),
>
> Probably MBR code which will look for a boot indicator is not able to
> interpret GPT.
>
> Nevertheless, afaik GRUB installs an MBR which knows from where to get
> its next program. So the question is rather how to install GRUB or repair
> the existing installation. (Beyond my experience, i fear.)
>
>
> Pascal Hambourg wrote:
>> - Partition attribute bit 2 = legacy BIOS bootable.
>> ...
>> I just wonder how a BIOS would use that, though.
> It's not the BIOS which reacts on the "active" bit. It's the MBR program
> code which may or may not look for the bit. If it does, then it runs the
> program code at the start of the partition.
> Package "syslinux" has "mbr.bin" which is supposed to act that way:
> http://git.zytor.com/syslinux/syslinux.git/tree/mbr/mbr.S
>
OK, the syslinux and syslinux-efi packages are now installed and I'm
studying man grub-install to see how to get the right mbr installed. It
appears to be in /usr/lib/SYSLINUX-EFI/efi64. It is called syslinux.efi.
Not sure this will cure the "ERROR:No boot disk..." problem tho.
- Dan
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2017-12-02 20:30 +0100 |
| Message-ID | <uSlE7-5rw-49@gated-at.bofh.it> |
| In reply to | #189478 |
Hi, Dan Norton wrote: > OK, the syslinux and syslinux-efi packages are now installed SYSLINUX and GRUB are competitors (with GRUB winning the race on hard disk but lagging behind on ISO 9660 for old BIOS). I mentioned the SYSLINUX file "mbr.bin" (source: mbr.S) only to substantiate my statement about the boot flag, the MBR and the (old) BIOS. So i expect that you only need GRUB packages to solve your problem. But i also expect that the boot flag will not play any role if you strive for a normal GRUB installation. > I'm studying man grub-install to see how to get the right mbr installed. It > appears to be in /usr/lib/SYSLINUX-EFI/efi64. It is called syslinux.efi. That's quite some mix-up. The Master Boot Record is in the first 512-byte block of a disk. It may contain up to 446 bytes of 16-bit x86 machine code and 4 MBR partition table entries. The x86 machine code is started by old BIOS as first stage of the custom boot process. It can do what its programmers wants. Normally it locates and starts a bigger x86 program. The MBR partition table is of no interest for old BIOS. (But as said, the MBR code might read the table and choose a partition if its programmer wanted it to do so.) As successor of old BIOS there is the (U)EFI firmware. Usually it has a Legacy BIOS emulation mode which causes the MBR program to be started. But in its native EFI mode it looks at the MBR partition table. If there is only one partition entry which has type 0xee and starts at block 1 (i.e. 1 block after the MBR block 0), then there is a GUID Partition Table (GPT). The MBR is then called "Protective MBR" because it protects the GPT from old unaware partition editors. EFI will then look in this GPT for the EFI System Partition and in there for the programs /EFI/BOOT/BOOTX64.EFI or /EFI/BOOT/BOOTIA32.EFI. You have GPT but no EFI System Partition. If the MBR partition table bears a partition of type 0xef, then EFI will accept it as EFI System Partition and look for the files. You have a Protective MBR and thus no partition of type 0xef. If no EFI System Partition is advertised bei GPT or MBR partition table then EFI will not consider the disk for booting. The file "syslinux.efi" in the "efi64" directory of SYSLINUX is a program which may serve as /EFI/BOOT/BOOTX64.EFI in the EFI System Partition. See http://www.syslinux.org/wiki/index.php?title=Install#UEFI Since your disk has no EFI System Partition, consider to try this: If your machine has EFI firmware, then check whether it is set to use "Legacy BIOS" or something with similar meaning. If not, then try to enable this legacy emulation. Maybe the MBR code on the disk knows how to start booting the system on the disk. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2017-12-02 03:00 +0100 |
| Message-ID | <uS5fX-3tB-1@gated-at.bofh.it> |
| In reply to | #189449 |
On 12/01/17 10:50, Dan Norton wrote:
> Maybe this is the wrong forum, but please bear with me a little bit.
> This post was sent from a desktop with jessie installed. The problem is
> it will not boot normally. Network booting has been disabled in the
> NVRAM setup. After POST there is a one-liner which says it can not find
> disk.
Please post the *exact* contents of the console screen.
> It can be booted with a supergrub2 cd, however.
>
>
> # fdisk -l
>
> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24
>
> Device Start End Sectors Size Type
> /dev/sda1 2048 411647 409600 200M BIOS boot
> /dev/sda2 411648 16783359 16371712 7.8G Linux swap
> /dev/sda3 16783360 151001087 134217728 64G Linux LVM
> /dev/sda4 151001088 285218815 134217728 64G Linux LVM
> /dev/sda5 285218816 419436543 134217728 64G Linux LVM
> /dev/sda6 419436544 553654271 134217728 64G Linux LVM
> /dev/sda7 553654272 1953525134 1399870863 667.5G Linux filesystem
>
>
> This post is being written with Debian 8 installed on /dev/sda3, above.
How did you create the contents of this disk?
What are your LVM PV's, VG's, and LV's?
What are the corresponding file systems and where are their mount points?
What bootloader was installed -- LILO, GRUB, GRUB2, whatever? And, where?
> Apparently, BIOS does not see a bootable device.
Are you sure? How did you reach that conclusion?
> In the dim past, fdisk
> could set a partition as "active", which was its euphemism for
> "bootable". However now:
>
>
> # fdisk /dev/sda
>
> Welcome to fdisk (util-linux 2.25.2).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
>
>
> Command (m for help): a
> a: unknown command
>
>
> Additional info:
>
> # uname -v
> #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19)
>
>
> HP Pro 3400 Series MT
https://support.hp.com/us-en/product/HP-Pro-3400-Microtower-PC/5160137
> BIOS version 7.16 dated 03/23/2012 with no update found.
>
>
> How can /dev/sda1 be defined so that the bios will see it as bootable?
On 12/01/17 13:23, Dan Norton wrote:
> On 12/01/2017 02:29 PM, Pascal Hambourg wrote:
>> Le 01/12/2017 à 19:57, Greg Wooledge a écrit :
>>> On Fri, Dec 01, 2017 at 01:50:12PM -0500, Dan Norton wrote:
>>>> Disklabel type: gpt
>>>
>>>> Apparently, BIOS does not see a bootable device. In the dim past,
fdisk
>>>> could set a partition as "active", which was its euphemism for
>>>> "bootable".
>>>> However now:
>>>
>>> GPT disk labels don't have active/bootable partitions.
>>
>> Yes they do. They even have two kinds of them.
>>
>> - Partition attribute bit 2 = legacy BIOS bootable.
>> It is supposed to be equivalent to the boot/active flag in partition
>> entries of the MBR. I just wonder how a BIOS would use that, though.
>>
>> - The good old boot/active flag of the GPT protective partition entry
>> in the MBR. Some BIOSes require it to boot a drive regardless of the
>> presence of a GPT disk label. It can be set with parted which
>> considers it as a disk flag (disk_set pmbr_boot on), or by fdisk by
>> forcing it to use the protective DOS/MBR disk label (-t dos).
>>
>
> This really sounds good. I could not figure out how to get at the
> protective mbr and turn on that bit. Here's what I tried, after doing a
> backup:
>
> # fdisk -t dos /dev/sda
Your original post indicated a GPT partition table. Forcing an MS-DOS
MBR partition type means the tool will be looking at fake information
that your GPT formatting tool laid down on disk ("protective MBR", or
some such; I avoid these complexities.)
> ...
>
> Command (m for help): m
>
> Help:
>
> DOS (MBR)
> a toggle a bootable flag
> b edit nested BSD disklabel
> c toggle the dos compatibility flag
>
> ...
>
> Command (m for help): a
> Selected partition 1
> The bootable flag on partition 1 is enabled now.
>
> Command (m for help): p
> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x3f90eec3
>
> Device Boot Start End Sectors Size Id Type
> /dev/sda1 * 1 1953525167 1953525167 931.5G ee GPT
>
> Command (m for help): w
> The partition table has been altered.
> Calling ioctl() to re-read partition table.
> Re-reading the partition table failed.: Device or resource busy
>
> The kernel still uses the old table. The new table will be used at the
> next reboot or after you run partprobe(8) or kpartx(8).
>
> # partprobe -s /dev/sda
Manipulating the fake information is unlikely to produce a desirable
result. I would undo those changes.
> After removing the cd and shutting down, re-booted from power-off
> state, but unfortunately still got the "disk not found" message on a
> black screen.
See my first comment.
> The PC is simply not seeing the 1T sda, which is the only disk. It's
> not even getting as far as the mbr/grub. The PC appears to be no more
> than 5 years old, based on the BIOS date, but it may be old enough to
> have a flaky UEFI. Should I abandon the use of GPT?
If you want to pursue the questions in your OP, I suspect that the
solution will involve reverting the changes you made, configuring your
firmware to see the GPT partition table, and configuring your bootloader
to find the Debian 8 /boot and/or root file systems.
David
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-02 05:10 +0100 |
| Message-ID | <uS7hL-4Yw-1@gated-at.bofh.it> |
| In reply to | #189458 |
On 12/01/2017 08:54 PM, David Christensen wrote:
> On 12/01/17 10:50, Dan Norton wrote:
>> Maybe this is the wrong forum, but please bear with me a little bit.
>> This post was sent from a desktop with jessie installed. The problem
>> is it will not boot normally. Network booting has been disabled in
>> the NVRAM setup. After POST there is a one-liner which says it can
>> not find disk.
>
> Please post the *exact* contents of the console screen.
>
ERROR:No boot disk has been detected or the disk has failed.
>
>> It can be booted with a supergrub2 cd, however.
>>
>>
>> # fdisk -l
>>
>> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disklabel type: gpt
>> Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24
>>
>> Device Start End Sectors Size Type
>> /dev/sda1 2048 411647 409600 200M BIOS boot
>> /dev/sda2 411648 16783359 16371712 7.8G Linux swap
>> /dev/sda3 16783360 151001087 134217728 64G Linux LVM
>> /dev/sda4 151001088 285218815 134217728 64G Linux LVM
>> /dev/sda5 285218816 419436543 134217728 64G Linux LVM
>> /dev/sda6 419436544 553654271 134217728 64G Linux LVM
>> /dev/sda7 553654272 1953525134 1399870863 667.5G Linux filesystem
>>
>>
>> This post is being written with Debian 8 installed on /dev/sda3, above.
>
> How did you create the contents of this disk?
fdisk for sda1 and sda2, then installer for sda3 through sda7. The
installer was from Debian 8.9 netinst on cd.
>
>
> What are your LVM PV's, VG's, and LV's?
# lvm pvdisplay
--- Physical volume ---
PV Name /dev/sda3
VG Name debian8-vg
PV Size 64.00 GiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 16383
Free PE 9399
Allocated PE 6984
PV UUID vyN3Lt-vGyw-lVZi-RDBG-NoXL-nqlH-k9eolf
"/dev/sda4" is a new physical volume of "64.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sda4
VG Name
PV Size 64.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID QqDROv-x2rg-3C3z-Lkdw-U95u-86BT-Jzrc6O
"/dev/sda5" is a new physical volume of "64.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sda5
VG Name
PV Size 64.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID oOQuaB-qAIu-q3DW-1h0B-rKA0-q1Z4-oznScr
"/dev/sda6" is a new physical volume of "64.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sda6
VG Name
PV Size 64.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID hHiVce-cC0V-u7zz-tqjU-5Rdd-nPza-BlPMQz
# lvm vgdisplay
--- Volume group ---
VG Name debian8-vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 17
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 4
Max PV 0
Cur PV 1
Act PV 1
VG Size 64.00 GiB
PE Size 4.00 MiB
Total PE 16383
Alloc PE / Size 6984 / 27.28 GiB
Free PE / Size 9399 / 36.71 GiB
VG UUID lfqcVE-yP6G-IeYF-zHYt-jc60-Jzas-c1fr5p
# lvm lvdisplay
--- Logical volume ---
LV Path /dev/debian8-vg/root
LV Name root
VG Name debian8-vg
LV UUID Eh9QwL-dTlm-s8H5-5FYN-CxBl-wnvn-om3Pbx
LV Write Access read/write
LV Creation host, time debian8, 2017-11-20 12:32:12 -0500
LV Status available
# open 1
LV Size 9.31 GiB
Current LE 2384
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0
--- Logical volume ---
LV Path /dev/debian8-vg/home
LV Name home
VG Name debian8-vg
LV UUID NugOd8-PRZM-9B1e-n0Ut-MWuB-Svso-Cfyxoe
LV Write Access read/write
LV Creation host, time debian8, 2017-11-20 12:33:08 -0500
LV Status available
# open 1
LV Size 9.31 GiB
Current LE 2384
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:1
--- Logical volume ---
LV Path /dev/debian8-vg/tmp
LV Name tmp
VG Name debian8-vg
LV UUID Met5mR-J5iz-KFvz-v58s-Y0B0-J2p0-v9pv8q
LV Write Access read/write
LV Creation host, time debian8, 2017-11-20 12:34:09 -0500
LV Status available
# open 1
LV Size 284.00 MiB
Current LE 71
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:2
--- Logical volume ---
LV Path /dev/debian8-vg/var
LV Name var
VG Name debian8-vg
LV UUID Wey2Pw-NO64-FjKH-Zvva-BJkV-ZlKE-SNmcjF
LV Write Access read/write
LV Creation host, time debian8, 2017-11-20 12:35:22 -0500
LV Status available
# open 1
LV Size 8.38 GiB
Current LE 2145
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:3
>
>
> What are the corresponding file systems and where are their mount points?
>
>
> What bootloader was installed -- LILO, GRUB, GRUB2, whatever? And, where?
>
GRUB2 to sda1.
>
>> Apparently, BIOS does not see a bootable device.
>
> Are you sure? How did you reach that conclusion?
>
ERROR:No boot disk... does not look like something I expect from GRUB2,
but I haven't searched the source code.
> ...
>>
>> HP Pro 3400 Series MT
>
> https://support.hp.com/us-en/product/HP-Pro-3400-Microtower-PC/5160137
>
>
The above url was used to search for bios updates. None found, as stated.
HP Diagnostics were run; all passed, including S.M.A.R.T.
>> BIOS version 7.16 dated 03/23/2012 with no update found.
>>
>>
>> How can /dev/sda1 be defined so that the bios will see it as bootable?
>
>
> On 12/01/17 13:23, Dan Norton wrote:
> > On 12/01/2017 02:29 PM, Pascal Hambourg wrote:
> >> Le 01/12/2017 à 19:57, Greg Wooledge a écrit :
> >>> On Fri, Dec 01, 2017 at 01:50:12PM -0500, Dan Norton wrote:
> >>>> Disklabel type: gpt
> >>>
> >>>> Apparently, BIOS does not see a bootable device. In the dim past,
> fdisk
> >>>> could set a partition as "active", which was its euphemism for
> >>>> "bootable".
> >>>> However now:
> >>>
> >>> GPT disk labels don't have active/bootable partitions.
> >>
> >> Yes they do. They even have two kinds of them.
> >>
> >> - Partition attribute bit 2 = legacy BIOS bootable.
> >> It is supposed to be equivalent to the boot/active flag in partition
> >> entries of the MBR. I just wonder how a BIOS would use that, though.
> >>
> >> - The good old boot/active flag of the GPT protective partition entry
> >> in the MBR. Some BIOSes require it to boot a drive regardless of the
> >> presence of a GPT disk label. It can be set with parted which
> >> considers it as a disk flag (disk_set pmbr_boot on), or by fdisk by
> >> forcing it to use the protective DOS/MBR disk label (-t dos).
> >>
> >
> > This really sounds good. I could not figure out how to get at the
> > protective mbr and turn on that bit. Here's what I tried, after doing a
> > backup:
> >
> > # fdisk -t dos /dev/sda
>
> Your original post indicated a GPT partition table. Forcing an MS-DOS
> MBR partition type means the tool will be looking at fake information
> that your GPT formatting tool laid down on disk ("protective MBR", or
> some such; I avoid these complexities.)
>
A new empty GPT partition table was created by fdisk prior to install.
Selection "g" under "Create a new label". Avoiding complexities is high
on my list of desirables.
>
> > ...
> >
> > Command (m for help): m
> >
> > Help:
> >
> > DOS (MBR)
> > a toggle a bootable flag
> > b edit nested BSD disklabel
> > c toggle the dos compatibility flag
> >
> > ...
> >
> > Command (m for help): a
> > Selected partition 1
> > The bootable flag on partition 1 is enabled now.
> >
> > Command (m for help): p
> > Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> > Units: sectors of 1 * 512 = 512 bytes
> > Sector size (logical/physical): 512 bytes / 512 bytes
> > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > Disklabel type: dos
> > Disk identifier: 0x3f90eec3
> >
> > Device Boot Start End Sectors Size Id Type
> > /dev/sda1 * 1 1953525167 1953525167 931.5G ee GPT
> >
> > Command (m for help): w
> > The partition table has been altered.
> > Calling ioctl() to re-read partition table.
> > Re-reading the partition table failed.: Device or resource busy
> >
> > The kernel still uses the old table. The new table will be used at the
> > next reboot or after you run partprobe(8) or kpartx(8).
> >
> > # partprobe -s /dev/sda
>
> Manipulating the fake information is unlikely to produce a desirable
> result. I would undo those changes.
>
>
> > After removing the cd and shutting down, re-booted from power-off
> > state, but unfortunately still got the "disk not found" message on a
> > black screen.
>
> See my first comment.
>
? Not sure which comment you are indicating.
>
> > The PC is simply not seeing the 1T sda, which is the only disk. It's
> > not even getting as far as the mbr/grub. The PC appears to be no more
> > than 5 years old, based on the BIOS date, but it may be old enough to
> > have a flaky UEFI. Should I abandon the use of GPT?
>
> If you want to pursue the questions in your OP, I suspect that the
> solution will involve reverting the changes you made, configuring your
> firmware to see the GPT partition table, and configuring your
> bootloader to find the Debian 8 /boot and/or root file systems.
>
There have been lots of changes as I've tried to learn how to multiboot
with LVM and GPT.
Are you referring to the "fdisk -t dos /dev/sda" change?
Not sure how to configure the firmware to see the GPT partition, beyond
Esc after power-on and selecting UEFI or boot using the defaults.
Configuring the bootloader was something I was going to do after the
disk could be found.
- Dan
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2017-12-02 20:40 +0100 |
| Message-ID | <uSlNM-5vO-7@gated-at.bofh.it> |
| In reply to | #189459 |
On 12/01/17 20:07, Dan Norton wrote:
> On 12/01/2017 08:54 PM, David Christensen wrote:
>> On 12/01/17 10:50, Dan Norton wrote: >>> Maybe this is the wrong forum, but please bear with me a little bit.
>>> This post was sent from a desktop with jessie installed. The problem
>>> is it will not boot normally. Network booting has been disabled in
>>> the NVRAM setup. After POST there is a one-liner which says it can
>>> not find disk.
>>
>> Please post the *exact* contents of the console screen.
>
> ERROR:No boot disk has been detected or the disk has failed.
>
>>> It can be booted with a supergrub2 cd, however.
>>>
>>> # fdisk -l
>>>
>>> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
>>> Units: sectors of 1 * 512 = 512 bytes
>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>> Disklabel type: gpt
>>> Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24
>>>
>>> Device Start End Sectors Size Type
>>> /dev/sda1 2048 411647 409600 200M BIOS boot
>>> /dev/sda2 411648 16783359 16371712 7.8G Linux swap
>>> /dev/sda3 16783360 151001087 134217728 64G Linux LVM
>>> /dev/sda4 151001088 285218815 134217728 64G Linux LVM
>>> /dev/sda5 285218816 419436543 134217728 64G Linux LVM
>>> /dev/sda6 419436544 553654271 134217728 64G Linux LVM
>>> /dev/sda7 553654272 1953525134 1399870863 667.5G Linux filesystem
>>>
>>>
>>> This post is being written with Debian 8 installed on /dev/sda3, above.
>>
>> How did you create the contents of this disk?
>
> fdisk for sda1 and sda2, then installer for sda3 through sda7. The
> installer was from Debian 8.9 netinst on cd.
Does the disk have the original GPT partition table created by HP, or
did you overwrite it?
>> What are your LVM PV's, VG's, and LV's?
>
> # lvm pvdisplay
> --- Physical volume ---
> PV Name /dev/sda3
> VG Name debian8-vg
> PV Size 64.00 GiB / not usable 4.00 MiB
> Allocatable yes
> PE Size 4.00 MiB
> Total PE 16383
> Free PE 9399
> Allocated PE 6984
> PV UUID vyN3Lt-vGyw-lVZi-RDBG-NoXL-nqlH-k9eolf
>
> "/dev/sda4" is a new physical volume of "64.00 GiB"
> --- NEW Physical volume ---
> PV Name /dev/sda4
> VG Name
> PV Size 64.00 GiB
> Allocatable NO
> PE Size 0
> Total PE 0
> Free PE 0
> Allocated PE 0
> PV UUID QqDROv-x2rg-3C3z-Lkdw-U95u-86BT-Jzrc6O
>
> "/dev/sda5" is a new physical volume of "64.00 GiB"
> --- NEW Physical volume ---
> PV Name /dev/sda5
> VG Name
> PV Size 64.00 GiB
> Allocatable NO
> PE Size 0
> Total PE 0
> Free PE 0
> Allocated PE 0
> PV UUID oOQuaB-qAIu-q3DW-1h0B-rKA0-q1Z4-oznScr
>
> "/dev/sda6" is a new physical volume of "64.00 GiB"
> --- NEW Physical volume ---
> PV Name /dev/sda6
> VG Name
> PV Size 64.00 GiB
> Allocatable NO
> PE Size 0
> Total PE 0
> Free PE 0
> Allocated PE 0
> PV UUID hHiVce-cC0V-u7zz-tqjU-5Rdd-nPza-BlPMQz
>
>
> # lvm vgdisplay
> --- Volume group ---
> VG Name debian8-vg
> System ID
> Format lvm2
> Metadata Areas 1
> Metadata Sequence No 17
> VG Access read/write
> VG Status resizable
> MAX LV 0
> Cur LV 4
> Open LV 4
> Max PV 0
> Cur PV 1
> Act PV 1
> VG Size 64.00 GiB
> PE Size 4.00 MiB
> Total PE 16383
> Alloc PE / Size 6984 / 27.28 GiB
> Free PE / Size 9399 / 36.71 GiB
> VG UUID lfqcVE-yP6G-IeYF-zHYt-jc60-Jzas-c1fr5p
>
>
> # lvm lvdisplay
> --- Logical volume ---
> LV Path /dev/debian8-vg/root
> LV Name root
> VG Name debian8-vg
> LV UUID Eh9QwL-dTlm-s8H5-5FYN-CxBl-wnvn-om3Pbx
> LV Write Access read/write
> LV Creation host, time debian8, 2017-11-20 12:32:12 -0500
> LV Status available
> # open 1
> LV Size 9.31 GiB
> Current LE 2384
> Segments 1
> Allocation inherit
> Read ahead sectors auto
> - currently set to 256
> Block device 254:0
>
> --- Logical volume ---
> LV Path /dev/debian8-vg/home
> LV Name home
> VG Name debian8-vg
> LV UUID NugOd8-PRZM-9B1e-n0Ut-MWuB-Svso-Cfyxoe
> LV Write Access read/write
> LV Creation host, time debian8, 2017-11-20 12:33:08 -0500
> LV Status available
> # open 1
> LV Size 9.31 GiB
> Current LE 2384
> Segments 1
> Allocation inherit
> Read ahead sectors auto
> - currently set to 256
> Block device 254:1
>
> --- Logical volume ---
> LV Path /dev/debian8-vg/tmp
> LV Name tmp
> VG Name debian8-vg
> LV UUID Met5mR-J5iz-KFvz-v58s-Y0B0-J2p0-v9pv8q
> LV Write Access read/write
> LV Creation host, time debian8, 2017-11-20 12:34:09 -0500
> LV Status available
> # open 1
> LV Size 284.00 MiB
> Current LE 71
> Segments 1
> Allocation inherit
> Read ahead sectors auto
> - currently set to 256
> Block device 254:2
>
> --- Logical volume ---
> LV Path /dev/debian8-vg/var
> LV Name var
> VG Name debian8-vg
> LV UUID Wey2Pw-NO64-FjKH-Zvva-BJkV-ZlKE-SNmcjF
> LV Write Access read/write
> LV Creation host, time debian8, 2017-11-20 12:35:22 -0500
> LV Status available
> # open 1
> LV Size 8.38 GiB
> Current LE 2145
> Segments 1
> Allocation inherit
> Read ahead sectors auto
> - currently set to 256
> Block device 254:3
>
>> What are the corresponding file systems and where are their mount points?
>>
>> What bootloader was installed -- LILO, GRUB, GRUB2, whatever? And, where?
>
> GRUB2 to sda1.
To summarize:
/dev/sda1 200 MB -- GRUB2 boot code (?)
/dev/sda2 has 7994 MB swap
/dev/sd3 is a 64 GB LVM PV allocated to VG 'debian8-vg', which is
allocated as follows
9.31 GiB LV 'root' -- ext4 file system mounted at /?
9.31 GiB LV 'home' -- ext4 file system mounted at /home?
284.00 MiB LV 'tmp' -- ext4 file system mounted at /tmp?
8.38 GiB LV 'var' -- ext4 file system mounted at /var?
36.71 GiB free
/dev/sd4 is an unallocated 64 GB LVM PV
/dev/sd5 is an unallocated 64 GB LVM PV
/dev/sd6 is an unallocated 64 GB LVM PV
/dev/sd7 667+ GB -- what is this used for?
Where is /boot?
>>> Apparently, BIOS does not see a bootable device.
>>
>> Are you sure? How did you reach that conclusion?
>
> ERROR:No boot disk... does not look like something I expect from GRUB2,
> but I haven't searched the source code.
>
>>> HP Pro 3400 Series MT
>>
>> https://support.hp.com/us-en/product/HP-Pro-3400-Microtower-PC/5160137
>>
> The above url was used to search for bios updates. None found, as stated.
> HP Diagnostics were run; all passed, including S.M.A.R.T.
>
>>> BIOS version 7.16 dated 03/23/2012 with no update found.
>>>
>>> How can /dev/sda1 be defined so that the bios will see it as bootable?
>>
>> On 12/01/17 13:23, Dan Norton wrote:
>> > On 12/01/2017 02:29 PM, Pascal Hambourg wrote:
>> >> Le 01/12/2017 à 19:57, Greg Wooledge a écrit :
>> >>> On Fri, Dec 01, 2017 at 01:50:12PM -0500, Dan Norton wrote:
>> >>>> Disklabel type: gpt
>> >>>
>> >>>> Apparently, BIOS does not see a bootable device. In the dim past,
>> fdisk
>> >>>> could set a partition as "active", which was its euphemism for
>> >>>> "bootable".
>> >>>> However now:
>> >>>
>> >>> GPT disk labels don't have active/bootable partitions.
>> >>
>> >> Yes they do. They even have two kinds of them.
>> >>
>> >> - Partition attribute bit 2 = legacy BIOS bootable.
>> >> It is supposed to be equivalent to the boot/active flag in partition
>> >> entries of the MBR. I just wonder how a BIOS would use that, though.
>> >>
>> >> - The good old boot/active flag of the GPT protective partition entry
>> >> in the MBR. Some BIOSes require it to boot a drive regardless of the
>> >> presence of a GPT disk label. It can be set with parted which
>> >> considers it as a disk flag (disk_set pmbr_boot on), or by fdisk by
>> >> forcing it to use the protective DOS/MBR disk label (-t dos).
>> >>
>> > This really sounds good. I could not figure out how to get at the
>> > protective mbr and turn on that bit. Here's what I tried, after doing a
>> > backup:
>> >
>> > # fdisk -t dos /dev/sda
>>
>> Your original post indicated a GPT partition table. Forcing an MS-DOS
>> MBR partition type means the tool will be looking at fake information
>> that your GPT formatting tool laid down on disk ("protective MBR", or
>> some such; I avoid these complexities.)
>
> A new empty GPT partition table was created by fdisk prior to install.
> Selection "g" under "Create a new label". Avoiding complexities is high
> on my list of desirables.
UEFI, GPT, and multi-boot all add complexity.
I did BIOS/MBR multi-boot years ago -- PITA. Now I KISS and do BIOS/MBR
and one OS per disk. I've only read about UEFI/GPT installation and
system disks. so my help will be limited.
>> > Command (m for help): m
>> >
>> > Help:
>> >
>> > DOS (MBR)
>> > a toggle a bootable flag
>> > b edit nested BSD disklabel
>> > c toggle the dos compatibility flag
>> >
>> > Command (m for help): a
>> > Selected partition 1
>> > The bootable flag on partition 1 is enabled now.
>> >
>> > Command (m for help): p
>> > Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
>> > Units: sectors of 1 * 512 = 512 bytes
>> > Sector size (logical/physical): 512 bytes / 512 bytes
>> > I/O size (minimum/optimal): 512 bytes / 512 bytes
>> > Disklabel type: dos
>> > Disk identifier: 0x3f90eec3
>> >
>> > Device Boot Start End Sectors Size Id Type
>> > /dev/sda1 * 1 1953525167 1953525167 931.5G ee GPT
>> >
>> > Command (m for help): w
>> > The partition table has been altered.
>> > Calling ioctl() to re-read partition table.
>> > Re-reading the partition table failed.: Device or resource busy
>> >
>> > The kernel still uses the old table. The new table will be used at the
>> > next reboot or after you run partprobe(8) or kpartx(8).
>> >
>> > # partprobe -s /dev/sda
>>
>> Manipulating the fake information is unlikely to produce a desirable
>> result. I would undo those changes.
>>
>> > After removing the cd and shutting down, re-booted from power-off
>> > state, but unfortunately still got the "disk not found" message on a
>> > black screen.
>>
>> See my first comment.
>
> ? Not sure which comment you are indicating.
My first comment was "Please post the *exact* contents of the console
screen".
STFW I found "Maintenance & Service Guide HP Pro 3400 Microtower
Business PC ...":
http://h10032.www1.hp.com/ctg/Manual/c03550748
p.12
Table 3-3 Computer Setup—Storage (continued)
Boot Order
Have you set /dev/sda1 as the first EFI boot source in EFI Boot Sources?
p. 18
Table 3-6 Computer Setup—Advanced (for advanced users)
Power-On Options
I would set "POST mode" to FullBoot.
I would set "Post messages" to Enabled.
p. 128
B POST Error Messages
POST Message Disabled suppresses most system messages during POST,
such as memory count and non-error text messages. If a POST error
occurs, the screen will display the error message. To manually
switch to the POST Messages Enabled mode during POST, press any key
(except F10, F11, or F12). The default mode is POST Message
Disabled.
See if you can get more messages that precedes "ERROR:No boot disk has
been detected or the disk has failed" and post the contents of the
console screen.
p.129
POST Numeric Codes and Text Messages
This section covers those POST errors that have numeric codes
associated with them. The section also includes some text messages
that may be encountered during POST.
NOTE:
The computer will beep once after a POST text message is displayed
on the screen.
Does the computer beep once after displaying "ERROR:No boot disk has
been detected or the disk has failed"?
STFW I also found "GPT hard Disk Drives For HP Desktops" which provides
useful background information:
http://h10032.www1.hp.com/ctg/Manual/c02826744
>> > The PC is simply not seeing the 1T sda, which is the only disk. It's
>> > not even getting as far as the mbr/grub. The PC appears to be no more
>> > than 5 years old, based on the BIOS date, but it may be old enough to
>> > have a flaky UEFI. Should I abandon the use of GPT?
>>
>> If you want to pursue the questions in your OP, I suspect that the
>> solution will involve reverting the changes you made, configuring your
>> firmware to see the GPT partition table, and configuring your
>> bootloader to find the Debian 8 /boot and/or root file systems.
>>
>
> There have been lots of changes as I've tried to learn how to multiboot
> with LVM and GPT.
I hope you are making images and taking good notes.
I typically remove all the drives except my target system drive (I
prefer 16+ GB SSD's), reset the BIOS CMOS settings, boot the Debian
distribution image into a rescue console, wipe the system drive, boot
the Debian distribution image into the installer, do a fresh install,
and build up from there (taking good notes as I go). It can take me
several attempts before I find a recipe that works (then I take an
image). I would get another 1 TB drive and create an mdadm RAID1 or ZFS
mirror.
> Are you referring to the "fdisk -t dos /dev/sda" change?
I was referring to:
Command (m for help): a
Selected partition 1
Command (m for help): w
> Not sure how to configure the firmware to see the GPT partition, beyond
> Esc after power-on and selecting UEFI or boot using the defaults.
>
> Configuring the bootloader was something I was going to do after the
> disk could be found.
David
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-03 04:50 +0100 |
| Message-ID | <uStrX-1X9-1@gated-at.bofh.it> |
| In reply to | #189481 |
On 12/02/2017 02:35 PM, David Christensen wrote:
> On 12/01/17 20:07, Dan Norton wrote:
>> On 12/01/2017 08:54 PM, David Christensen wrote:
>>> On 12/01/17 10:50, Dan Norton wrote: >>> Maybe this is the wrong
>>> forum, but please bear with me a little bit.
>>>> This post was sent from a desktop with jessie installed. The
>>>> problem is it will not boot normally. Network booting has been
>>>> disabled in the NVRAM setup. After POST there is a one-liner which
>>>> says it can not find disk.
>>>
>>> Please post the *exact* contents of the console screen.
>>
>> ERROR:No boot disk has been detected or the disk has failed.
>>
>>>> It can be booted with a supergrub2 cd, however.
>>>>
>>>> # fdisk -l
>>>>
>>>> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
>>>> Units: sectors of 1 * 512 = 512 bytes
>>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>>> Disklabel type: gpt
>>>> Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24
>>>>
>>>> Device Start End Sectors Size Type
>>>> /dev/sda1 2048 411647 409600 200M BIOS boot
>>>> /dev/sda2 411648 16783359 16371712 7.8G Linux swap
>>>> /dev/sda3 16783360 151001087 134217728 64G Linux LVM
>>>> /dev/sda4 151001088 285218815 134217728 64G Linux LVM
>>>> /dev/sda5 285218816 419436543 134217728 64G Linux LVM
>>>> /dev/sda6 419436544 553654271 134217728 64G Linux LVM
>>>> /dev/sda7 553654272 1953525134 1399870863 667.5G Linux filesystem
>>>>
>>>>
>>>> This post is being written with Debian 8 installed on /dev/sda3,
>>>> above.
>>>
>>> How did you create the contents of this disk?
>>
>> fdisk for sda1 and sda2, then installer for sda3 through sda7. The
>> installer was from Debian 8.9 netinst on cd.
>
> Does the disk have the original GPT partition table created by HP, or
> did you overwrite it?
It had no GPT until I put one on it. Previous scheme was 4 primaries
and 1 extended. The extended had logicals for /, /home, /tmp, and /var.
>
>
>>> What are your LVM PV's, VG's, and LV's?
>>
>> # lvm pvdisplay
>> --- Physical volume ---
>> PV Name /dev/sda3
>> VG Name debian8-vg
>> PV Size 64.00 GiB / not usable 4.00 MiB
>> Allocatable yes
>> PE Size 4.00 MiB
>> Total PE 16383
>> Free PE 9399
>> Allocated PE 6984
>> PV UUID vyN3Lt-vGyw-lVZi-RDBG-NoXL-nqlH-k9eolf
>>
>> "/dev/sda4" is a new physical volume of "64.00 GiB"
>> --- NEW Physical volume ---
>> PV Name /dev/sda4
>> VG Name
>> PV Size 64.00 GiB
>> Allocatable NO
>> PE Size 0
>> Total PE 0
>> Free PE 0
>> Allocated PE 0
>> PV UUID QqDROv-x2rg-3C3z-Lkdw-U95u-86BT-Jzrc6O
>>
>> "/dev/sda5" is a new physical volume of "64.00 GiB"
>> --- NEW Physical volume ---
>> PV Name /dev/sda5
>> VG Name
>> PV Size 64.00 GiB
>> Allocatable NO
>> PE Size 0
>> Total PE 0
>> Free PE 0
>> Allocated PE 0
>> PV UUID oOQuaB-qAIu-q3DW-1h0B-rKA0-q1Z4-oznScr
>>
>> "/dev/sda6" is a new physical volume of "64.00 GiB"
>> --- NEW Physical volume ---
>> PV Name /dev/sda6
>> VG Name
>> PV Size 64.00 GiB
>> Allocatable NO
>> PE Size 0
>> Total PE 0
>> Free PE 0
>> Allocated PE 0
>> PV UUID hHiVce-cC0V-u7zz-tqjU-5Rdd-nPza-BlPMQz
>>
>>
>> # lvm vgdisplay
>> --- Volume group ---
>> VG Name debian8-vg
>> System ID
>> Format lvm2
>> Metadata Areas 1
>> Metadata Sequence No 17
>> VG Access read/write
>> VG Status resizable
>> MAX LV 0
>> Cur LV 4
>> Open LV 4
>> Max PV 0
>> Cur PV 1
>> Act PV 1
>> VG Size 64.00 GiB
>> PE Size 4.00 MiB
>> Total PE 16383
>> Alloc PE / Size 6984 / 27.28 GiB
>> Free PE / Size 9399 / 36.71 GiB
>> VG UUID lfqcVE-yP6G-IeYF-zHYt-jc60-Jzas-c1fr5p
>>
>>
>> # lvm lvdisplay
>> --- Logical volume ---
>> LV Path /dev/debian8-vg/root
>> LV Name root
>> VG Name debian8-vg
>> LV UUID Eh9QwL-dTlm-s8H5-5FYN-CxBl-wnvn-om3Pbx
>> LV Write Access read/write
>> LV Creation host, time debian8, 2017-11-20 12:32:12 -0500
>> LV Status available
>> # open 1
>> LV Size 9.31 GiB
>> Current LE 2384
>> Segments 1
>> Allocation inherit
>> Read ahead sectors auto
>> - currently set to 256
>> Block device 254:0
>>
>> --- Logical volume ---
>> LV Path /dev/debian8-vg/home
>> LV Name home
>> VG Name debian8-vg
>> LV UUID NugOd8-PRZM-9B1e-n0Ut-MWuB-Svso-Cfyxoe
>> LV Write Access read/write
>> LV Creation host, time debian8, 2017-11-20 12:33:08 -0500
>> LV Status available
>> # open 1
>> LV Size 9.31 GiB
>> Current LE 2384
>> Segments 1
>> Allocation inherit
>> Read ahead sectors auto
>> - currently set to 256
>> Block device 254:1
>>
>> --- Logical volume ---
>> LV Path /dev/debian8-vg/tmp
>> LV Name tmp
>> VG Name debian8-vg
>> LV UUID Met5mR-J5iz-KFvz-v58s-Y0B0-J2p0-v9pv8q
>> LV Write Access read/write
>> LV Creation host, time debian8, 2017-11-20 12:34:09 -0500
>> LV Status available
>> # open 1
>> LV Size 284.00 MiB
>> Current LE 71
>> Segments 1
>> Allocation inherit
>> Read ahead sectors auto
>> - currently set to 256
>> Block device 254:2
>>
>> --- Logical volume ---
>> LV Path /dev/debian8-vg/var
>> LV Name var
>> VG Name debian8-vg
>> LV UUID Wey2Pw-NO64-FjKH-Zvva-BJkV-ZlKE-SNmcjF
>> LV Write Access read/write
>> LV Creation host, time debian8, 2017-11-20 12:35:22 -0500
>> LV Status available
>> # open 1
>> LV Size 8.38 GiB
>> Current LE 2145
>> Segments 1
>> Allocation inherit
>> Read ahead sectors auto
>> - currently set to 256
>> Block device 254:3
>>
>>> What are the corresponding file systems and where are their mount
>>> points?
>>>
>>> What bootloader was installed -- LILO, GRUB, GRUB2, whatever? And,
>>> where?
>>
>> GRUB2 to sda1.
>
> To summarize:
>
> /dev/sda1 200 MB -- GRUB2 boot code (?)
>
> /dev/sda2 has 7994 MB swap
>
> /dev/sd3 is a 64 GB LVM PV allocated to VG 'debian8-vg', which is
> allocated as follows
>
> 9.31 GiB LV 'root' -- ext4 file system mounted at /?
>
> 9.31 GiB LV 'home' -- ext4 file system mounted at /home?
>
> 284.00 MiB LV 'tmp' -- ext4 file system mounted at /tmp?
>
> 8.38 GiB LV 'var' -- ext4 file system mounted at /var?
>
Yes to all four questions.
> 36.71 GiB free
>
> /dev/sd4 is an unallocated 64 GB LVM PV
>
> /dev/sd5 is an unallocated 64 GB LVM PV
>
> /dev/sd6 is an unallocated 64 GB LVM PV
>
> /dev/sd7 667+ GB -- what is this used for?
>
Nothing at this time.
>
> Where is /boot?
>
In LV root, in sda4.
>
>>>> Apparently, BIOS does not see a bootable device.
>>>
>>> Are you sure? How did you reach that conclusion?
>>
>> ERROR:No boot disk... does not look like something I expect from
>> GRUB2, but I haven't searched the source code.
>>
>>>> HP Pro 3400 Series MT
>>>
>>> https://support.hp.com/us-en/product/HP-Pro-3400-Microtower-PC/5160137
>>>
>> The above url was used to search for bios updates. None found, as
>> stated.
>> HP Diagnostics were run; all passed, including S.M.A.R.T.
>>
>>>> BIOS version 7.16 dated 03/23/2012 with no update found.
>>>>
>>>> How can /dev/sda1 be defined so that the bios will see it as bootable?
>>>
>>> On 12/01/17 13:23, Dan Norton wrote:
>>> > On 12/01/2017 02:29 PM, Pascal Hambourg wrote:
>>> >> Le 01/12/2017 à 19:57, Greg Wooledge a écrit :
>>> >>> On Fri, Dec 01, 2017 at 01:50:12PM -0500, Dan Norton wrote:
>>> >>>> Disklabel type: gpt
>>> >>>
>>> >>>> Apparently, BIOS does not see a bootable device. In the dim
>>> past, fdisk
>>> >>>> could set a partition as "active", which was its euphemism for
>>> >>>> "bootable".
>>> >>>> However now:
>>> >>>
>>> >>> GPT disk labels don't have active/bootable partitions.
>>> >>
>>> >> Yes they do. They even have two kinds of them.
>>> >>
>>> >> - Partition attribute bit 2 = legacy BIOS bootable.
>>> >> It is supposed to be equivalent to the boot/active flag in partition
>>> >> entries of the MBR. I just wonder how a BIOS would use that, though.
>>> >>
>>> >> - The good old boot/active flag of the GPT protective partition
>>> entry
>>> >> in the MBR. Some BIOSes require it to boot a drive regardless of the
>>> >> presence of a GPT disk label. It can be set with parted which
>>> >> considers it as a disk flag (disk_set pmbr_boot on), or by fdisk by
>>> >> forcing it to use the protective DOS/MBR disk label (-t dos).
>>> >>
>>> > This really sounds good. I could not figure out how to get at the
>>> > protective mbr and turn on that bit. Here's what I tried, after
>>> doing a
>>> > backup:
>>> >
>>> > # fdisk -t dos /dev/sda
>>>
>>> Your original post indicated a GPT partition table. Forcing an
>>> MS-DOS MBR partition type means the tool will be looking at fake
>>> information that your GPT formatting tool laid down on disk
>>> ("protective MBR", or some such; I avoid these complexities.)
>>
>> A new empty GPT partition table was created by fdisk prior to
>> install. Selection "g" under "Create a new label". Avoiding
>> complexities is high on my list of desirables.
>
> UEFI, GPT, and multi-boot all add complexity.
>
>
> I did BIOS/MBR multi-boot years ago -- PITA. Now I KISS and do
> BIOS/MBR and one OS per disk. I've only read about UEFI/GPT
> installation and system disks. so my help will be limited.
>
>
>>> > Command (m for help): m
>>> >
>>> > Help:
>>> >
>>> > DOS (MBR)
>>> > a toggle a bootable flag
>>> > b edit nested BSD disklabel
>>> > c toggle the dos compatibility flag
>>> >
>>> > Command (m for help): a
>>> > Selected partition 1
>>> > The bootable flag on partition 1 is enabled now.
>>> >
>>> > Command (m for help): p
>>> > Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
>>> > Units: sectors of 1 * 512 = 512 bytes
>>> > Sector size (logical/physical): 512 bytes / 512 bytes
>>> > I/O size (minimum/optimal): 512 bytes / 512 bytes
>>> > Disklabel type: dos
>>> > Disk identifier: 0x3f90eec3
>>> >
>>> > Device Boot Start End Sectors Size Id Type
>>> > /dev/sda1 * 1 1953525167 1953525167 931.5G ee GPT
>>> >
>>> > Command (m for help): w
>>> > The partition table has been altered.
>>> > Calling ioctl() to re-read partition table.
>>> > Re-reading the partition table failed.: Device or resource busy
>>> >
>>> > The kernel still uses the old table. The new table will be used at
>>> the
>>> > next reboot or after you run partprobe(8) or kpartx(8).
>>> >
>>> > # partprobe -s /dev/sda
>>>
>>> Manipulating the fake information is unlikely to produce a desirable
>>> result. I would undo those changes.
>>>
>>> > After removing the cd and shutting down, re-booted from power-off
>>> > state, but unfortunately still got the "disk not found" message on a
>>> > black screen.
>>>
>>> See my first comment.
>>
>> ? Not sure which comment you are indicating.
>
> My first comment was "Please post the *exact* contents of the console
> screen".
>
>
> STFW I found "Maintenance & Service Guide HP Pro 3400 Microtower
> Business PC ...":
>
> http://h10032.www1.hp.com/ctg/Manual/c03550748
This got my attention, sure. I tweaked every feature in Setup but most
of the stuff in the manual is not available on this PC.
NOTE: Not all settings shown in the following sections are available for
all models
>
> p.12
>
> Table 3-3 Computer Setup—Storage (continued)
>
> Boot Order
>
> Have you set /dev/sda1 as the first EFI boot source in EFI Boot Sources?
>
>
> p. 18
>
> Table 3-6 Computer Setup—Advanced (for advanced users)
>
> Power-On Options
>
> I would set "POST mode" to FullBoot.
>
> I would set "Post messages" to Enabled.
>
>
> p. 128
>
> B POST Error Messages
>
> POST Message Disabled suppresses most system messages during POST,
> such as memory count and non-error text messages. If a POST error
> occurs, the screen will display the error message. To manually
> switch to the POST Messages Enabled mode during POST, press any key
> (except F10, F11, or F12). The default mode is POST Message
> Disabled.
>
> See if you can get more messages that precedes "ERROR:No boot disk has
> been detected or the disk has failed" and post the contents of the
> console screen.
>
>
> p.129
>
> POST Numeric Codes and Text Messages
>
> This section covers those POST errors that have numeric codes
> associated with them. The section also includes some text messages
> that may be encountered during POST.
>
> NOTE:
> The computer will beep once after a POST text message is displayed
> on the screen.
>
> Does the computer beep once after displaying "ERROR:No boot disk has
> been detected or the disk has failed"?
>
Wish I could do the above, but there is no provision for it on mine.
There is no beep.
"Press any key" was news to me. Each press produces another "ERROR:No
boot disk has been detected or the disk has failed"
>
> STFW I also found "GPT hard Disk Drives For HP Desktops" which
> provides useful background information:
>
> http://h10032.www1.hp.com/ctg/Manual/c02826744
>
>
>>> > The PC is simply not seeing the 1T sda, which is the only disk. It's
>>> > not even getting as far as the mbr/grub. The PC appears to be no more
>>> > than 5 years old, based on the BIOS date, but it may be old enough to
>>> > have a flaky UEFI. Should I abandon the use of GPT?
>>>
>>> If you want to pursue the questions in your OP, I suspect that the
>>> solution will involve reverting the changes you made, configuring
>>> your firmware to see the GPT partition table, and configuring your
>>> bootloader to find the Debian 8 /boot and/or root file systems.
>>>
>>
>> There have been lots of changes as I've tried to learn how to
>> multiboot with LVM and GPT.
>
> I hope you are making images and taking good notes.
> I typically remove all the drives except my target system drive (I
> prefer 16+ GB SSD's), reset the BIOS CMOS settings, boot the Debian
> distribution image into a rescue console, wipe the system drive, boot
> the Debian distribution image into the installer, do a fresh install,
> and build up from there (taking good notes as I go). It can take me
> several attempts before I find a recipe that works (then I take an
> image). I would get another 1 TB drive and create an mdadm RAID1 or
> ZFS mirror.
>
Another drive
>
>> Are you referring to the "fdisk -t dos /dev/sda" change?
>
> I was referring to:
>
> Command (m for help): a
> Selected partition 1
>
> Command (m for help): w
>
Yes, that was made possible by "fdisk -t dos /dev/sda" and it's been
reverted.
>
>> Not sure how to configure the firmware to see the GPT partition,
>> beyond Esc after power-on and selecting UEFI or boot using the defaults.
>>
>> Configuring the bootloader was something I was going to do after the
>> disk could be found.
>
Using the supergrub2 cd to boot is feasible, barely, it takes 3 or 4
minutes to get to the logon. It probably succeeds where others fail
because it has an option to activate lvm support.
I'm not making progress with this PC so I'll probably abandon GPT. The
disk is 1T and it was handled by the extended partition scheme before
this experiment and it probably can again. I still want to do LVM and
multiboot a few systems though.
- Dan
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-04 00:40 +0100 |
| Message-ID | <uSM1A-5Eh-9@gated-at.bofh.it> |
| In reply to | #189492 |
On 12/03/2017 02:04 PM, Felix Miata wrote: > Dan Norton composed on 2017-12-04 08:00 (UTC-0500): > >> Felix Miata wrote: >>> Dan Norton composed on 2017-12-03 16:44 (UTC-0500): >>> Note the above is currently from the future. Apparently the PC you are emailing >>> from is advanced one day. >> Must be a result of my Setup menu activities. Debian says it is 07:48 AM >> (5 hours late) but I put in the local time from my cell phone in Setup >> this morning. Maybe I need to set the HW to UTC? > That's the preferred time for *nix installations. Check what's in /etc/adjtime > to confirm. HW clock needs to match it. Now you're showing 5 hours late. > >> I've been wondering what you do with all those >> systems, too. It would be much more productive if we worked together. >> I'm pretty much self-taught. > Mostly I try to replicate reported problems and assist in finding solutions, > identifying bugs, and doing bug QA. It's getting harder because my supply of > free PCs to use for the purpose dried up before UEFI started to show up. > >> Do you ever come to Atlanta? I'm North of it, in Roswell. > I've never stopped there except to fuel passing through between here and > Wisconsin or Nashville. Last such trip was probably around 25 years ago. > >>> Before you give up, it might be worth more investigation of GPT boot foibles >>> outside the Debian zone. Archlinux docs are consistently among the best >>> regardless of distro in use. You might yet have a solution using a simple >>> procedure applied to what you have already done, if only it can be identified. >>> http://www.lightofdawn.org/wiki/wiki.cgi/BIOSBootGPT > !!! After reading this again, did this: # gdisk /dev/sda [...] Command (? for help): x Expert command (? for help): p [...] Number Start (sector) End (sector) Size Code Name 1 2048 411647 200.0 MiB EF00 2 411648 16783359 7.8 GiB 8200 3 16783360 151001087 64.0 GiB 8E00 4 151001088 285218815 64.0 GiB 8E00 5 285218816 419436543 64.0 GiB 8E00 6 419436544 553654271 64.0 GiB 8E00 7 553654272 1953525134 667.5 GiB 8300 [...] Expert command (? for help): a Partition number (1-7): 3 [...] Attribute value is 0000000000000000. Set fields are: No fields set Toggle which attribute field (0-63, 64 or <Enter> to exit): 2 Have enabled the 'legacy BIOS bootable' attribute. Attribute value is 0000000000000004. Set fields are: 2 (legacy BIOS bootable) Toggle which attribute field (0-63, 64 or <Enter> to exit): w I know this needs to be followed by more steps... the reference refers to Syslinux but we're using GRUB. It says: 2. Next, mount the partition somewhere, say in /mnt/data 3. Use [GRUB2] to install the boot loader, pretending that it is a regular partition: 4. Copy [ ? ] which is capable of booting GPT partition to the disk's MBR. What is needed to fill the two [...]? The mbr's first 446 bytes are non-empty, but possibly incompatible with bios.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2017-12-04 06:20 +0100 |
| Message-ID | <uSRkB-zY-3@gated-at.bofh.it> |
| In reply to | #189492 |
On 12/03/17 13:44, Dan Norton wrote:
> On 12/02/2017 02:35 PM, David Christensen wrote:
> I'm not making progress with this PC so I'll probably abandon GPT. The
> disk is 1T and it was handled by the extended partition scheme before
> this experiment and it probably can again. I still want to do LVM and
> multiboot a few systems though.
STFW I see:
1. https://wiki.debian.org/UEFI
More background information.
2. https://www.debian.org/releases/stable/amd64/ch06s03.html.en#di-partition
Note section "6.3.3.3. Manual Partitioning".
I have a computer with an Intel DQ67SWR motherboard that supports UEFI.
So, I pulled the drives, installed a 16 GB SSD, powered up, reset the
CMOS settings to default, set "Boot" -> "UEFI Boot" to "Enable", booted
the Debian 9.1.0 amd64 installer into "Rescue mode", wiped the first and
last megabyte of the SSD, used 'parted' to create a GPT partition table,
and booted d-i again in "Install" mode. I set up the disk with:
- 1 GB ESP partition
- 5 GB partition with LVM PV and matching VG
- 1 GB LV with btrfs /boot
- 1 GB LV with LUKS random key swap
- 3 GB LV with LUKS btrfs root
- 10 GB free space for adding more OS's
Installation proceeded smoothly, until d-i tried to install GRUB:
[!!] Install the GRUB boot loader on a hard disk
Unable to install GRUB in dummy
Executing 'grub-install dummy' failed.
This is a fatal error.
I re-tried the step -- nope.
I proceeded with "Continue without boot loader" and was able to finish
the install.
Needless to say, the disk does not boot using only UEFI.
But, it was not a total loss -- I can now dissect the SSD.
Here is the boot sector:
# dd if=/dev/sda count=1 2>/dev/null | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
000001c0 01 00 ee fe ff ff 01 00 00 00 af 40 dd 01 00 00
|...........@....|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
|..............U.|
00000200
When I mount /dev/sda1, I see:
# mount -o ro /dev/sda1 /mnt/sda1
# mount | grep /mnt/sda1
/dev/sda1 on /mnt/sda1 type vfat
(ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
# df /dev/sda1
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 973952 188 973764 1% /mnt/sda1
# tree -a /mnt/sda1
/mnt/sda1
`-- EFI
`-- debian
`-- grubx64.efi
# ls -l /mnt/sda1/EFI/debian/grubx64.efi
-rwxr-xr-x 1 root root 178688 Dec 2 23:33 /mnt/sda1/EFI/debian/grubx64.efi
# file /mnt/sda1/EFI/debian/grubx64.efi
/mnt/sda1/EFI/debian/grubx64.efi: PE32+ executable (EFI application)
x86-64 (stripped to external PDB), for MS Windows
I can run various LVM commands to confirm that d-i/partman did what I
told it to do.
The next time I try this, I think I'll go the opposite extreme, feed a
blank disk to d-i, let partman automagically format the whole disk, and
see if GRUB installs, if the installation completes without error, if
the disk boots, and what the SSD contains.
David
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2017-12-04 06:30 +0100 |
| Message-ID | <uSRuh-G8-3@gated-at.bofh.it> |
| In reply to | #189538 |
On 12/03/17 21:17, David Christensen wrote:
> But, it was not a total loss -- I can now dissect the SSD.
More info:
# lsblk /dev/sda
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 14.9G 0 disk
|-sda1 8:1 0 953M 0 part
`-sda2 8:2 0 4.7G 0 part
# parted /dev/sda u s p free
Model: ATA SAMSUNG SSD UM41 (scsi)
Disk /dev/sda: 31277232s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
34s 2047s 2014s Free Space
1 2048s 1953791s 1951744s fat32 ESP boot, esp
2 1953792s 11718655s 9764864s stretch lvm
11718656s 31277198s 19558543s Free Space
Are there any other commands that readers might find interesting (before
I wipe the SSD)?
David
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-04 15:40 +0100 |
| Message-ID | <uT04x-62x-9@gated-at.bofh.it> |
| In reply to | #189539 |
On 12/04/2017 12:27 AM, David Christensen wrote: > On 12/03/17 21:17, David Christensen wrote: >> But, it was not a total loss -- I can now dissect the SSD. > > More info: > > # lsblk /dev/sda > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 14.9G 0 disk > |-sda1 8:1 0 953M 0 part > `-sda2 8:2 0 4.7G 0 part > > # parted /dev/sda u s p free > Model: ATA SAMSUNG SSD UM41 (scsi) > Disk /dev/sda: 31277232s > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End Size File system Name Flags > 34s 2047s 2014s Free Space > 1 2048s 1953791s 1951744s fat32 ESP boot, esp > 2 1953792s 11718655s 9764864s stretch lvm > 11718656s 31277198s 19558543s Free Space > > > Are there any other commands that readers might find interesting > (before I wipe the SSD)? > Just out of curiosity, lvdisplay? - Dan
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2017-12-05 01:50 +0100 |
| Message-ID | <uT9AR-3Cu-3@gated-at.bofh.it> |
| In reply to | #189552 |
On 12/04/17 06:39, Dan Norton wrote: > On 12/04/2017 12:27 AM, David Christensen wrote: >> Are there any other commands that readers might find interesting >> (before I wipe the SSD)? > > Just out of curiosity, lvdisplay? # lvm lvdisplay --- Logical volume --- LV Path /dev/vg-stretch/lv-stretch-boot LV Name lv-stretch-boot VG Name vg-stretch LV UUID 7Zm4BR-NCAV-GoUM-Q9S2-R8Ns-LEl3-I1nRne LV Write Access read/write LV Creation host, time debian, 2017-12-02 22:37:23 -0800 LV Status NOT available LV Size 952.00 MiB Current LE 238 Segments 1 Allocation inherit Read ahead sectors auto --- Logical volume --- LV Path /dev/vg-stretch/lv-stretch-swap LV Name lv-stretch-swap VG Name vg-stretch LV UUID XeVjFi-rGUx-deNE-iGX0-63YP-wQFx-OfCX1a LV Write Access read/write LV Creation host, time debian, 2017-12-02 22:38:41 -0800 LV Status NOT available LV Size 952.00 MiB Current LE 238 Segments 1 Allocation inherit Read ahead sectors auto --- Logical volume --- LV Path /dev/vg-stretch/lv-stretch-root LV Name lv-stretch-root VG Name vg-stretch LV UUID YZrrSb-tScX-WkPo-hdPE-Lgux-rMs7-QbZlX7 LV Write Access read/write LV Creation host, time debian, 2017-12-02 22:39:42 -0800 LV Status NOT available LV Size 2.79 GiB Current LE 715 Segments 1 Allocation inherit Read ahead sectors auto David
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-12-04 16:30 +0100 |
| Message-ID | <uT0QW-6xY-9@gated-at.bofh.it> |
| In reply to | #189539 |
On Sun 03 Dec 2017 at 21:27:20 (-0800), David Christensen wrote: > On 12/03/17 21:17, David Christensen wrote: > >But, it was not a total loss -- I can now dissect the SSD. > > More info: > > # lsblk /dev/sda > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 14.9G 0 disk > |-sda1 8:1 0 953M 0 part > `-sda2 8:2 0 4.7G 0 part > > # parted /dev/sda u s p free > Model: ATA SAMSUNG SSD UM41 (scsi) > Disk /dev/sda: 31277232s > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End Size File system Name Flags > 34s 2047s 2014s Free Space > 1 2048s 1953791s 1951744s fat32 ESP boot, esp > 2 1953792s 11718655s 9764864s stretch lvm > 11718656s 31277198s 19558543s Free Space > > > Are there any other commands that readers might find interesting > (before I wipe the SSD)? I recently reformatted a disk thus: puck: GPT-style, master Part # filesys size code rôle puck - 1007KiB partition tables and alignment space puck01 - 3MiB EF02 bios-boot for Grub (bios_grub flag) puck02 FAT32 496MiB EF00 EFI (boot flag) puck03 ext2 500MiB 8300 /boot (unencrypted) … which gdisk shows as Number Start (sector) End (sector) Size Code Name 1 2048 8191 3.0 MiB EF02 BIOS boot partition 2 8192 1023999 496.0 MiB EF00 EFI System 3 1024000 2047999 500.0 MiB 8300 Linux filesystem … Is the absence of a partition like puck01 on your disk a significant factor in your failure to install grub? ie where's grub going to place itself? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2017-12-05 02:40 +0100 |
| Message-ID | <uTanf-4a6-7@gated-at.bofh.it> |
| In reply to | #189553 |
On 12/04/17 07:21, David Wright wrote:
> I recently reformatted a disk thus:
>
> puck: GPT-style, master
>
> Part # filesys size code rôle
> puck - 1007KiB partition tables and alignment space
> puck01 - 3MiB EF02 bios-boot for Grub (bios_grub flag)
> puck02 FAT32 496MiB EF00 EFI (boot flag)
> puck03 ext2 500MiB 8300 /boot (unencrypted)
> …
Your console session is incomplete -- you did not copy/paste your command.
> which gdisk shows as
>
> Number Start (sector) End (sector) Size Code Name
> 1 2048 8191 3.0 MiB EF02 BIOS boot partition
> 2 8192 1023999 496.0 MiB EF00 EFI System
> 3 1024000 2047999 500.0 MiB 8300 Linux filesystem
> …
As above; but at least you dropped a clue, "gdisk".
Here is some more info:
# gpart -d -vvv /dev/sda
dev(/dev/sda) mss(512) chs(1946/255/63)(LBA) #s(31277232) size(15272mb)
Primary partition(1)
type: 238(0xEE)(UNKNOWN)
size: 15272mb #s(31277231) s(1-31277231)
chs: (0/0/1)-(1023/254/63)d (0/0/2)-(1946/233/63)r
hex: 00 00 01 00 EE FE FF FF 01 00 00 00 AF 40 DD 01
Primary partition(2)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
hex: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Primary partition(3)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
hex: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Primary partition(4)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
hex: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
dev(/dev/sda) master boot record (w/o partition table):
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
01A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 31277232 sectors, 14.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): C078C1DF-29A5-4552-917D-995FF9946D9F
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 31277198
Partitions will be aligned on 2048-sector boundaries
Total free space is 19560557 sectors (9.3 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1953791 953.0 MiB EF00 ESP
2 1953792 11718655 4.7 GiB 8E00 stretch
# fdisk -l /dev/sda
Disk /dev/sda: 14.9 GiB, 16013942784 bytes, 31277232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C078C1DF-29A5-4552-917D-995FF9946D9F
Device Start End Sectors Size Type
/dev/sda1 2048 1953791 1951744 953M EFI System
/dev/sda2 1953792 11718655 9764864 4.7G Linux LVM
> Is the absence of a partition like puck01 on your disk a significant
> factor in your failure to install grub?
> ie where's grub going to place itself?
I initially let d-i/partman automagically partition the SSD, looked at
the table it generated, and saw a ESP partition, a swap partition, and a
root partition. I then wipe the first and last megabyte, created the
GPT partition with parted, and then proceeded with the complex disk
layout I really wanted. Unfortunately, debian-9.1.0-amd64-xfce-CD-1 d-i
blew up trying to install GRUB, so I don't know where GRUB ends up when
UEFI firmware and GPT partitioning is done correctly. That's why I plan
to try again with the simplest automagic partitioning and see what happens.
STFW I found another useful article:
http://www.rodsbooks.com/efi-bootloaders/grub2.html
David
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2017-12-05 07:00 +0100 |
| Message-ID | <uTeqR-6Ja-5@gated-at.bofh.it> |
| In reply to | #189566 |
On 12/04/17 17:34, David Christensen wrote:
> That's why I plan to try again with the simplest automagic partitioning
> and see what happens.
I wiped the SSD, ran d-i, and chose "Partitioning method" -> "Guided -
use entire disk and set up encrypted LVM", which produced:
LVM VG debian-vg, LV home - 3.5 GB Linux device-mapper (linear)
#1 3.5 GB f ext4 /home
LVM VG debian-vg, LV root - 2.0 GB Linux device-mapper (linear)
#1 2.0 GB f ext4 /
LVM VG debian-vg, LV swap_1 - 8.5 GB Linux device-mapper (linear)
#1 8.5 GB f swap swap
LVM VG debian-vg, LV tmp - 255.9 MB Linux device-mapper (linear)
#1 255.9 MB f ext4 /tmp
LVM VG debian-vg, LV tmp - 998.2 MB Linux device-mapper (linear)
#1 998.2 MB f ext4 /var
Encrypted volume (sda3_crypt) - 15.2 GB Linux device-mapper (crypt)
#1 15.2 GB K lvm
SCSI3 (0,0,0) (sda) - 16.0 GB ATA SAMSUNG SSD UM41
1.0 MB FREE SPACE
#1 536.9 MB B F ESP
#2 255.9 MB F ext2 /boot
#3 15.2 GB K crypto (sda3_crypt)
73.2 kB FREE SPACE
I tried changing swap size, but that led to prompts for actions that
might break things. So, I just accepted the above and moved on.
d-i completed without errors. :-)
The disk boots to the GRUB menu. Letting that time out, LUKS passphrase
prompt is displayed. Entering the passphrase, the login prompt is
displayed. :-)
An SSH session follows.
As for "how does it boot with UEFI, GPT, and GRUB?", my vague guess is:
1. There is no 16-bit 8086 first stage boot loader code in sector 0 of
the SSD -- see 'gpart -d -vvv /dev/sda' output, below. The motherboard
firmware doesn't use this in UEFI mode.
2. There is a "protective MBR" in sector 0 of the SSD -- see 'fdisk -t
mbr -l /dev/sda' output, below. I don't know if UEFI firmware looks at
this.
3. The firmware finds and reads the GPT partition table on the SSD.
4. The firmware finds the first GPT partition and file system, which
look "right" for EFI boot images.
5. The firmware reads this file system and finds only one file, which
it loads and runs (starting GRUB):
/EFI/debian/grubx64.efi
(If there were more than one choice, my guess is that I'd have to
pre-select one in the CMOS setup, or perhaps have to select one from a
menu at the end of POST?)
6. GRUB finds the second GPT partition and file system, which looks
"right" for GRUB, reads the file system, locates the appropriate files
(notably /boot/grub/grub.cfg), and boots the system.
Again -- are there any other commands I should run that readers might
find interesting?
David
--
root@debian:~# cat /etc/debian_version
9.2
root@debian:~# uname -a
Linux debian 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64
GNU/Linux
root@debian:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 14.9G 0 disk
|-sda1 8:1 0 512M 0 part /boot/efi
|-sda2 8:2 0 244M 0 part /boot
`-sda3 8:3 0 14.2G 0 part
`-sda3_crypt 254:0 0 14.2G 0 crypt
|-debian--vg-root 254:1 0 1.9G 0 lvm /
|-debian--vg-var 254:2 0 952M 0 lvm /var
|-debian--vg-swap_1 254:3 0 7.9G 0 lvm [SWAP]
|-debian--vg-tmp 254:4 0 244M 0 lvm /tmp
`-debian--vg-home 254:5 0 3.2G 0 lvm /home
sr0 11:0 1 1024M 0 rom
root@debian:~# parted /dev/sda u s p free
Model: ATA SAMSUNG SSD UM41 (scsi)
Disk /dev/sda: 31277232s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
34s 2047s 2014s Free Space
1 2048s 1050623s 1048576s fat32 boot, esp
2 1050624s 1550335s 499712s ext2
3 1550336s 31277055s 29726720s
31277056s 31277198s 143s Free Space
root@debian:~# gpart -d -vvv /dev/sda
dev(/dev/sda) mss(512) chs(1946/255/63)(LBA) #s(31277232) size(15272mb)
Primary partition(1)
type: 238(0xEE)(UNKNOWN)
size: 15272mb #s(31277231) s(1-31277231)
chs: (0/0/1)-(1023/254/63)d (0/0/2)-(1946/233/63)r
hex: 00 00 01 00 EE FE FF FF 01 00 00 00 AF 40 DD 01
Primary partition(2)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
hex: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Primary partition(3)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
hex: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Primary partition(4)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
hex: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
dev(/dev/sda) master boot record (w/o partition table):
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
01A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
. . . . . . . . . . . . . . . .
root@debian:~# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 31277232 sectors, 14.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1423ACF9-1BA2-404D-A4FC-52576318EFCF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 31277198
Partitions will be aligned on 2048-sector boundaries
Total free space is 2157 sectors (1.1 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1050623 512.0 MiB EF00
2 1050624 1550335 244.0 MiB 8300
3 1550336 31277055 14.2 GiB 8300
root@debian:~# fdisk -t mbr -l /dev/sda
Disk /dev/sda: 14.9 GiB, 16013942784 bytes, 31277232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sda1 1 31277231 31277231 14.9G ee GPT
root@debian:~# fdisk -l /dev/sda
Disk /dev/sda: 14.9 GiB, 16013942784 bytes, 31277232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1423ACF9-1BA2-404D-A4FC-52576318EFCF
Device Start End Sectors Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 1550335 499712 244M Linux filesystem
/dev/sda3 1550336 31277055 29726720 14.2G Linux filesystem
root@debian:~# lvm lvdisplay
--- Logical volume ---
LV Path /dev/debian-vg/root
LV Name root
VG Name debian-vg
LV UUID iU6J9C-MCbP-RXkU-7gpt-zzu3-3nW2-8ht7OB
LV Write Access read/write
LV Creation host, time debian, 2017-12-04 20:05:01 -0800
LV Status available
# open 1
LV Size 1.86 GiB
Current LE 476
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:1
--- Logical volume ---
LV Path /dev/debian-vg/var
LV Name var
VG Name debian-vg
LV UUID GlrAnx-fl2t-MwfR-gCe1-oNFK-75A5-XxF9Ew
LV Write Access read/write
LV Creation host, time debian, 2017-12-04 20:05:01 -0800
LV Status available
# open 1
LV Size 952.00 MiB
Current LE 238
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:2
--- Logical volume ---
LV Path /dev/debian-vg/swap_1
LV Name swap_1
VG Name debian-vg
LV UUID fsSVAk-qJxx-r5oO-nAzf-V7tD-P68K-j3PSg0
LV Write Access read/write
LV Creation host, time debian, 2017-12-04 20:05:01 -0800
LV Status available
# open 2
LV Size 7.91 GiB
Current LE 2026
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:3
--- Logical volume ---
LV Path /dev/debian-vg/tmp
LV Name tmp
VG Name debian-vg
LV UUID NX7oty-RbhV-LKLQ-mpUh-jZSy-Beo8-N0UKfJ
LV Write Access read/write
LV Creation host, time debian, 2017-12-04 20:05:01 -0800
LV Status available
# open 1
LV Size 244.00 MiB
Current LE 61
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:4
--- Logical volume ---
LV Path /dev/debian-vg/home
LV Name home
VG Name debian-vg
LV UUID Q13SCi-BKfV-LF04-0UPz-0lxg-Wb8X-i0LvB5
LV Write Access read/write
LV Creation host, time debian, 2017-12-04 20:05:01 -0800
LV Status available
# open 1
LV Size 3.23 GiB
Current LE 827
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:5
root@debian:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 4033908 0 4033908 0% /dev
tmpfs 809232 8928 800304 2% /run
/dev/mapper/debian--vg-root 1886280 688284 1084128 39% /
tmpfs 4046156 0 4046156 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 4046156 0 4046156 0% /sys/fs/cgroup
/dev/mapper/debian--vg-home 3268656 11604 3071300 1% /home
/dev/mapper/debian--vg-tmp 237861 2057 219216 1% /tmp
/dev/mapper/debian--vg-var 943128 194612 683392 23% /var
/dev/sda2 241965 38997 190476 17% /boot
/dev/sda1 523248 132 523116 1% /boot/efi
tmpfs 809228 0 809228 0% /run/user/1000
root@debian:~# mount | grep sda1
/dev/sda1 on /boot/efi type vfat
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
root@debian:~# tree /boot
/boot
|-- System.map-4.9.0-4-amd64
|-- config-4.9.0-4-amd64
|-- efi
| `-- EFI
| `-- debian
| `-- grubx64.efi
|-- grub
| |-- fonts
| | `-- unicode.pf2
| |-- grub.cfg
| |-- grubenv
| |-- locale
| | |-- ast.mo
| | |-- ca.mo
| | |-- da.mo
| | |-- de.mo
| | |-- de@hebrew.mo
| | |-- de_CH.mo
| | |-- en@arabic.mo
| | |-- en@cyrillic.mo
| | |-- en@greek.mo
| | |-- en@hebrew.mo
| | |-- en@piglatin.mo
| | |-- en@quot.mo
| | |-- eo.mo
| | |-- es.mo
| | |-- fi.mo
| | |-- fr.mo
| | |-- gl.mo
| | |-- hu.mo
| | |-- id.mo
| | |-- it.mo
| | |-- ja.mo
| | |-- lt.mo
| | |-- nb.mo
| | |-- nl.mo
| | |-- pa.mo
| | |-- pl.mo
| | |-- pt_BR.mo
| | |-- ru.mo
| | |-- sl.mo
| | |-- sr.mo
| | |-- sv.mo
| | |-- tr.mo
| | |-- uk.mo
| | |-- vi.mo
| | |-- zh_CN.mo
| | `-- zh_TW.mo
| |-- unicode.pf2
| `-- x86_64-efi
| |-- acpi.mod
| |-- adler32.mod
| |-- affs.mod
| |-- afs.mod
| |-- ahci.mod
| |-- all_video.mod
| |-- aout.mod
| |-- appleldr.mod
| |-- archelp.mod
| |-- at_keyboard.mod
| |-- ata.mod
| |-- backtrace.mod
| |-- bfs.mod
| |-- bitmap.mod
| |-- bitmap_scale.mod
| |-- blocklist.mod
| |-- boot.mod
| |-- bsd.mod
| |-- bswap_test.mod
| |-- btrfs.mod
| |-- bufio.mod
| |-- cat.mod
| |-- cbfs.mod
| |-- cbls.mod
| |-- cbmemc.mod
| |-- cbtable.mod
| |-- cbtime.mod
| |-- chain.mod
| |-- cmdline_cat_test.mod
| |-- cmp.mod
| |-- cmp_test.mod
| |-- command.lst
| |-- configfile.mod
| |-- core.efi
| |-- cpio.mod
| |-- cpio_be.mod
| |-- cpuid.mod
| |-- crc64.mod
| |-- crypto.lst
| |-- crypto.mod
| |-- cryptodisk.mod
| |-- cs5536.mod
| |-- ctz_test.mod
| |-- date.mod
| |-- datehook.mod
| |-- datetime.mod
| |-- disk.mod
| |-- diskfilter.mod
| |-- div.mod
| |-- div_test.mod
| |-- dm_nv.mod
| |-- echo.mod
| |-- efi_gop.mod
| |-- efi_uga.mod
| |-- efifwsetup.mod
| |-- efinet.mod
| |-- ehci.mod
| |-- elf.mod
| |-- eval.mod
| |-- exfat.mod
| |-- exfctest.mod
| |-- ext2.mod
| |-- extcmd.mod
| |-- fat.mod
| |-- file.mod
| |-- fixvideo.mod
| |-- font.mod
| |-- fs.lst
| |-- fshelp.mod
| |-- functional_test.mod
| |-- gcry_arcfour.mod
| |-- gcry_blowfish.mod
| |-- gcry_camellia.mod
| |-- gcry_cast5.mod
| |-- gcry_crc.mod
| |-- gcry_des.mod
| |-- gcry_dsa.mod
| |-- gcry_idea.mod
| |-- gcry_md4.mod
| |-- gcry_md5.mod
| |-- gcry_rfc2268.mod
| |-- gcry_rijndael.mod
| |-- gcry_rmd160.mod
| |-- gcry_rsa.mod
| |-- gcry_seed.mod
| |-- gcry_serpent.mod
| |-- gcry_sha1.mod
| |-- gcry_sha256.mod
| |-- gcry_sha512.mod
| |-- gcry_tiger.mod
| |-- gcry_twofish.mod
| |-- gcry_whirlpool.mod
| |-- geli.mod
| |-- gettext.mod
| |-- gfxmenu.mod
| |-- gfxterm.mod
| |-- gfxterm_background.mod
| |-- gfxterm_menu.mod
| |-- gptsync.mod
| |-- grub.efi
| |-- gzio.mod
| |-- halt.mod
| |-- hashsum.mod
| |-- hdparm.mod
| |-- hello.mod
| |-- help.mod
| |-- hexdump.mod
| |-- hfs.mod
| |-- hfsplus.mod
| |-- hfspluscomp.mod
| |-- http.mod
| |-- iorw.mod
| |-- iso9660.mod
| |-- jfs.mod
| |-- jpeg.mod
| |-- keylayouts.mod
| |-- keystatus.mod
| |-- ldm.mod
| |-- legacy_password_test.mod
| |-- legacycfg.mod
| |-- linux.mod
| |-- linux16.mod
| |-- linuxefi.mod
| |-- loadbios.mod
| |-- loadenv.mod
| |-- loopback.mod
| |-- ls.mod
| |-- lsacpi.mod
| |-- lsefi.mod
| |-- lsefimmap.mod
| |-- lsefisystab.mod
| |-- lsmmap.mod
| |-- lspci.mod
| |-- lssal.mod
| |-- luks.mod
| |-- lvm.mod
| |-- lzopio.mod
| |-- macbless.mod
| |-- macho.mod
| |-- mdraid09.mod
| |-- mdraid09_be.mod
| |-- mdraid1x.mod
| |-- memdisk.mod
| |-- memrw.mod
| |-- minicmd.mod
| |-- minix.mod
| |-- minix2.mod
| |-- minix2_be.mod
| |-- minix3.mod
| |-- minix3_be.mod
| |-- minix_be.mod
| |-- mmap.mod
| |-- moddep.lst
| |-- modinfo.sh
| |-- morse.mod
| |-- mpi.mod
| |-- msdospart.mod
| |-- mul_test.mod
| |-- multiboot.mod
| |-- multiboot2.mod
| |-- nativedisk.mod
| |-- net.mod
| |-- newc.mod
| |-- nilfs2.mod
| |-- normal.mod
| |-- ntfs.mod
| |-- ntfscomp.mod
| |-- odc.mod
| |-- offsetio.mod
| |-- ohci.mod
| |-- part_acorn.mod
| |-- part_amiga.mod
| |-- part_apple.mod
| |-- part_bsd.mod
| |-- part_dfly.mod
| |-- part_dvh.mod
| |-- part_gpt.mod
| |-- part_msdos.mod
| |-- part_plan.mod
| |-- part_sun.mod
| |-- part_sunpc.mod
| |-- partmap.lst
| |-- parttool.lst
| |-- parttool.mod
| |-- password.mod
| |-- password_pbkdf2.mod
| |-- pata.mod
| |-- pbkdf2.mod
| |-- pbkdf2_test.mod
| |-- pcidump.mod
| |-- play.mod
| |-- png.mod
| |-- priority_queue.mod
| |-- probe.mod
| |-- procfs.mod
| |-- progress.mod
| |-- raid5rec.mod
| |-- raid6rec.mod
| |-- random.mod
| |-- read.mod
| |-- reboot.mod
| |-- regexp.mod
| |-- reiserfs.mod
| |-- relocator.mod
| |-- romfs.mod
| |-- scsi.mod
| |-- search.mod
| |-- search_fs_file.mod
| |-- search_fs_uuid.mod
| |-- search_label.mod
| |-- serial.mod
| |-- setjmp.mod
| |-- setjmp_test.mod
| |-- setpci.mod
| |-- sfs.mod
| |-- shift_test.mod
| |-- signature_test.mod
| |-- sleep.mod
| |-- sleep_test.mod
| |-- spkmodem.mod
| |-- squash4.mod
| |-- syslinuxcfg.mod
| |-- tar.mod
| |-- terminal.lst
| |-- terminal.mod
| |-- terminfo.mod
| |-- test.mod
| |-- test_blockarg.mod
| |-- testload.mod
| |-- testspeed.mod
| |-- tftp.mod
| |-- tga.mod
| |-- time.mod
| |-- tr.mod
| |-- trig.mod
| |-- true.mod
| |-- udf.mod
| |-- ufs1.mod
| |-- ufs1_be.mod
| |-- ufs2.mod
| |-- uhci.mod
| |-- usb.mod
| |-- usb_keyboard.mod
| |-- usbms.mod
| |-- usbserial_common.mod
| |-- usbserial_ftdi.mod
| |-- usbserial_pl2303.mod
| |-- usbserial_usbdebug.mod
| |-- usbtest.mod
| |-- verify.mod
| |-- video.lst
| |-- video.mod
| |-- video_bochs.mod
| |-- video_cirrus.mod
| |-- video_colors.mod
| |-- video_fb.mod
| |-- videoinfo.mod
| |-- videotest.mod
| |-- videotest_checksum.mod
| |-- xfs.mod
| |-- xnu.mod
| |-- xnu_uuid.mod
| |-- xnu_uuid_test.mod
| |-- xzio.mod
| |-- zfs.mod
| |-- zfscrypt.mod
| `-- zfsinfo.mod
|-- initrd.img-4.9.0-4-amd64
|-- lost+found
`-- vmlinuz-4.9.0-4-amd64
8 directories, 312 files
root@debian:~# ls -l /boot/efi/EFI/debian/grubx64.efi
-rwx------ 1 root root 121856 Dec 4 20:23 /boot/efi/EFI/debian/grubx64.efi
root@debian:~# file /boot/efi/EFI/debian/grubx64.efi
/boot/efi/EFI/debian/grubx64.efi: PE32+ executable (EFI application)
x86-64 (stripped to external PDB), for MS Windows
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2017-12-06 00:20 +0100 |
| Message-ID | <uTuFk-Fw-13@gated-at.bofh.it> |
| In reply to | #189569 |
Le 05/12/2017 à 06:55, David Christensen a écrit : > > I wiped the SSD, ran d-i, and chose "Partitioning method" -> "Guided - > use entire disk and set up encrypted LVM", which produced: > > LVM VG debian-vg, LV home - 3.5 GB Linux device-mapper (linear) > #1 3.5 GB f ext4 /home > LVM VG debian-vg, LV root - 2.0 GB Linux device-mapper (linear) > #1 2.0 GB f ext4 / > LVM VG debian-vg, LV swap_1 - 8.5 GB Linux device-mapper (linear) > #1 8.5 GB f swap swap > LVM VG debian-vg, LV tmp - 255.9 MB Linux device-mapper (linear) > #1 255.9 MB f ext4 /tmp > LVM VG debian-vg, LV tmp - 998.2 MB Linux device-mapper (linear) > #1 998.2 MB f ext4 /var > Encrypted volume (sda3_crypt) - 15.2 GB Linux device-mapper (crypt) > #1 15.2 GB K lvm > SCSI3 (0,0,0) (sda) - 16.0 GB ATA SAMSUNG SSD UM41 > 1.0 MB FREE SPACE > #1 536.9 MB B F ESP > #2 255.9 MB F ext2 /boot > #3 15.2 GB K crypto (sda3_crypt) > 73.2 kB FREE SPACE (...) > d-i completed without errors. :-) ESP means that you ran the installer in EFI mode. If you did that with the initial partitioning (BIOS boot partition), the installation of GRUB could not work because there was no ESP partition. > As for "how does it boot with UEFI, GPT, and GRUB?", my vague guess is: > > 1. There is no 16-bit 8086 first stage boot loader code in sector 0 of > the SSD -- see 'gpart -d -vvv /dev/sda' output, below. The motherboard > firmware doesn't use this in UEFI mode. Correct. > 2. There is a "protective MBR" in sector 0 of the SSD -- see 'fdisk -t > mbr -l /dev/sda' output, below. I don't know if UEFI firmware looks at > this. It may, in order to check that it contains a valid protective MBR. > 3. The firmware finds and reads the GPT partition table on the SSD. Correct. > 4. The firmware finds the first GPT partition and file system, which > look "right" for EFI boot images. No. > 5. The firmware reads this file system and finds only one file, which > it loads and runs (starting GRUB): > > /EFI/debian/grubx64.efi No. > (If there were more than one choice, my guess is that I'd have to > pre-select one in the CMOS setup, or perhaps have to select one from a > menu at the end of POST?) No. First, a compliant UEFI firmware should look up its EFI boot variables and try each boot entry Boot* in the order defined in the BootOrder variable. The text description associated to theses entries is usually displayed in the EFI boot menu. If no entry is defined or works, then the firmware should look for a partition with the "EFI system partition" type GUID and look for an /EFI/Boot/bootx64.efi file (default path used on removable devices). GRUB can be installed in such a path with grub-install --removable > 6. GRUB finds the second GPT partition and file system, which looks > "right" for GRUB, reads the file system, locates the appropriate files > (notably /boot/grub/grub.cfg), and boots the system. When /boot/grub is in a plain partition on the same drive as GRUB's core image (grubx64.efi here), the partition number is hardcoded in the core image. > Again -- are there any other commands I should run that readers might > find interesting? You can print the EFI boot variables with efibootmgr -v
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2017-12-07 07:00 +0100 |
| Message-ID | <uTXnY-253-5@gated-at.bofh.it> |
| In reply to | #189588 |
On 12/05/17 15:18, Pascal Hambourg wrote:
> Le 05/12/2017 à 06:55, David Christensen a écrit :
>> 4. The firmware finds the first GPT partition and file system, which
>> look "right" for EFI boot images.
>
> No.
>
>> 5. The firmware reads this file system and finds only one file, which
>> it loads and runs (starting GRUB):
>>
>> /EFI/debian/grubx64.efi
>
> No.
>
>> (If there were more than one choice, my guess is that I'd have to
>> pre-select one in the CMOS setup, or perhaps have to select one from a
>> menu at the end of POST?)
>
> No.
>
> First, a compliant UEFI firmware should look up its EFI boot variables
> and try each boot entry Boot* in the order defined in the BootOrder
> variable. The text description associated to theses entries is usually
> displayed in the EFI boot menu. If no entry is defined or works, then
> the firmware should look for a partition with the "EFI system partition"
> type GUID and look for an /EFI/Boot/bootx64.efi file (default path used
> on removable devices).
>
> GRUB can be installed in such a path with
>
> grub-install --removable
>
>> 6. GRUB finds the second GPT partition and file system, which looks
>> "right" for GRUB, reads the file system, locates the appropriate files
>> (notably /boot/grub/grub.cfg), and boots the system.
>
> When /boot/grub is in a plain partition on the same drive as GRUB's core
> image (grubx64.efi here), the partition number is hardcoded in the core
> image.
>
>> Again -- are there any other commands I should run that readers might
>> find interesting?
>
> You can print the EFI boot variables with
>
> efibootmgr -v
root@debian:~# efibootmgr -v
Timeout: 1 seconds
BootOrder: 0001,0000,000B,000D,000E
Boot0000* Windows Boot Manager
HD(1,GPT,b1ed9b97-3b16-4838-8b46-3978e905fdd9,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0001* debian
HD(1,GPT,c89f1523-fff6-45d1-abbe-b2eaaa0216e0,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot000B* CD/DVD Drive BBS(CDROM,,0x0)P3: HL-DT-ST BD-RE WH14NS40 .
Boot000D* Network Card BBS(Network,,0x0)IBA GE Slot 00C8 v1395.
Boot000E* Hard Drive BBS(HD,,0x0)P0: INTEL SSDSC2CW060A3.
Boot0000 -- there is no Windows drive in this machine.
Boot0001 -- corresponds to the first GPT partition on the SSD that is in
the machine:
root@debian:~# blkid /dev/sda1
/dev/sda1: UUID="8F67-ADA4" TYPE="vfat"
PARTUUID="c89f1523-fff6-45d1-abbe-b2eaaa0216e0"
root@debian:~# mount /dev/sda1 /mnt
root@debian:~# ls -l /mnt/EFI/debian/grubx64.efi
-rwx------ 1 root root 121856 Dec 4 20:23 /mnt/EFI/debian/grubx64.efi
Boot000B -- corresponds to my optical drive.
Boot000D -- corresponds to my network interface.
Boot000E -- corresponds to an SSD (with Debian Stretch BIOS/MBR) that
was in the machine in the past, but was not installed when I installed
Debian UEFI/GPT and currently is not installed.
STFW I see:
http://www.uefi.org/
http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf
2,706 pages -- that's going to take a while to read...
David
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-12-05 23:30 +0100 |
| Message-ID | <uTtSV-8n-13@gated-at.bofh.it> |
| In reply to | #189566 |
On Mon 04 Dec 2017 at 17:34:52 (-0800), David Christensen wrote:
> On 12/04/17 07:21, David Wright wrote:
> >I recently reformatted a disk thus:
> >
> >puck: GPT-style, master
> >
> >Part # filesys size code rôle
> >puck - 1007KiB partition tables and alignment space
> >puck01 - 3MiB EF02 bios-boot for Grub (bios_grub flag)
> >puck02 FAT32 496MiB EF00 EFI (boot flag)
> >puck03 ext2 500MiB 8300 /boot (unencrypted)
> >…
>
> Your console session is incomplete -- you did not copy/paste your command.
That isn't a console session, it's taken from the File (in the MI5/FBI
sense) that I keep on each significant piece of hardware that I have.
"Puck" is what's written in magic marker on the drive.
"Part #" is the filesystem LABEL where there is such a thing,
otherwise it's a human label by which to refer to it (as I did
when I wrote puck01 later in the post).
"code" is the abbreviated code of the type used by gdisk.
"rôle" is the use that the area/partition is put to, written
in human language.
I don't know of a command that can print out a line like
puck - 1007KiB partition tables and alignment space
which is why I write it into the file myself.
> >which gdisk shows as
> >
> >Number Start (sector) End (sector) Size Code Name
> > 1 2048 8191 3.0 MiB EF02 BIOS boot partition
> > 2 8192 1023999 496.0 MiB EF00 EFI System
> > 3 1024000 2047999 500.0 MiB 8300 Linux filesystem
> >…
>
> As above; but at least you dropped a clue, "gdisk".
That *is* a copy/paste. I didn't think the command relevant: my
question is about the absence of this sort of partition in the
disk that you formatted:
1 2048 8191 3.0 MiB EF02 BIOS boot partition
I was under the impression (correct me if this is wrong) that Grub
put its 1st stage in the first sector along with the "fake" MBR
partition table, and the 2nd stage into the BIOS boot partition
which is an area that nothing else takes any interest in.
AFAICT (again, correct me if this is wrong) your disk has nowhere
for Grub to place its 2nd stage, so it fails. Perhaps that's what you
were deliberately trying to show?
> >Is the absence of a partition like puck01 on your disk a significant
> >factor in your failure to install grub?
> >ie where's grub going to place itself?
>
> I initially let d-i/partman automagically partition the SSD, looked
> at the table it generated, and saw a ESP partition, a swap
> partition, and a root partition. I then wipe the first and last
> megabyte, created the GPT partition with parted, and then proceeded
> with the complex disk layout I really wanted. Unfortunately,
> debian-9.1.0-amd64-xfce-CD-1 d-i blew up trying to install GRUB, so
> I don't know where GRUB ends up when UEFI firmware and GPT
> partitioning is done correctly. That's why I plan to try again with
> the simplest automagic partitioning and see what happens.
I don't know anything about UEFI firmware. I'm only just inheriting
a UEFI laptop with W10 on it and hope to split a partition for linux,
but I've only booted linux from a USB stick just to have a poke about.
The OP/Subject line says "BIOS Can Not Find Disk" so I'm posting info
from a BIOS computer booting from a SATA GPT disk. I installed stretch
onto it from a USB stick. Here's the full output from gdisk if you
think it helps:
✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂
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.
Disk /dev/sdb: 156250000 sectors, 74.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3443D1C7-75D1-44BB-B438-18F912FEC2DA
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 156249966
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 8191 3.0 MiB EF02 BIOS boot partition
2 8192 1023999 496.0 MiB EF00 EFI System
3 1024000 2047999 500.0 MiB 8300 Linux filesystem
4 2048000 79140863 36.8 GiB 8300 Linux filesystem
5 79140864 156249966 36.8 GiB 8300 Linux filesystem
✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂
And here is how it boots, as seen by bootinfoscript:
✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂
Boot Info Script 0.61 [1 April 2012]
============================= Boot Info Summary: ===============================
=> Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 2048
of the same hard drive for core.img, but core.img can not be found at this
location.
=> Grub2 (v1.99) is installed in the MBR of /dev/sdb and looks at sector 2048
of the same hard drive for core.img. core.img is at this location and
looks in partition 85 for .
sda1: __________________________________________________________________________
File system: crypto_LUKS
Boot sector type: Unknown
Boot sector info:
sdb1: __________________________________________________________________________
File system: BIOS Boot partition
Boot sector type: Grub2's core.img
Boot sector info:
sdb2: __________________________________________________________________________
File system:
Boot sector type: -
Boot sector info:
Mounting failed: mount: unknown filesystem type ''
sdb3: __________________________________________________________________________
File system: ext2
Boot sector type: -
Boot sector info:
Operating System:
Boot files: /grub/grub.cfg
sdb4: __________________________________________________________________________
File system: crypto_LUKS
Boot sector type: Unknown
Boot sector info:
sdb5: __________________________________________________________________________
File system: crypto_LUKS
Boot sector type: Unknown
Boot sector info:
============================ Drive/Partition Info: =============================
Drive: sda _____________________________________________________________________
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Partition Boot Start Sector End Sector # of Sectors Id System
/dev/sda1 1 976,773,167 976,773,167 ee GPT
GUID Partition Table detected.
Partition Start Sector End Sector # of Sectors System
/dev/sda1 2,048 976,771,071 976,769,024 Data partition (Linux)
Drive: sdb _____________________________________________________________________
Disk /dev/sdb: 74.5 GiB, 80000000000 bytes, 156250000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Partition Boot Start Sector End Sector # of Sectors Id System
/dev/sdb1 1 156,249,999 156,249,999 ee GPT
GUID Partition Table detected.
Partition Start Sector End Sector # of Sectors System
/dev/sdb1 2,048 8,191 6,144 BIOS Boot partition
/dev/sdb2 8,192 1,023,999 1,015,808 EFI System partition
/dev/sdb3 1,024,000 2,047,999 1,024,000 Data partition (Linux)
/dev/sdb4 2,048,000 79,140,863 77,092,864 Data partition (Linux)
/dev/sdb5 79,140,864 156,249,966 77,109,103 Data partition (Linux)
✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂
As you can see, the 2nd stage of Grub is at the first sector of
/dev/sdb1, or what I called "puck01".
I haven't tried installing Debian on a GPT disk without having
(a) a protective MBR for the 1st stage and (b) a BIOS Boot
partition for the 2nd stage, so I don't know how or whether
it objects.
I haven't pieced together the info from the OP into a coherent
narrative. (There are too many bits like "Yes, that was made possible
by "fdisk -t dos /dev/sda" and it's been reverted.") So I can't
suggest a way of fixing their problem. I don't know how fascist
their BIOS is. This 2006 Dell doesn't seem to bother about
boot flags.
All I can say is that there doesn't seem to be much point in
formatting a GPT disk without including (i) a protective MBR,
(ii) a BIOS Boot partition and (iii) an EFI System partition.
(i) and (ii) give you backward compatibility, and (iii) gives
you future-proofing. As you can see, I haven't yet bothered
to format (iii) as I was more concerned with getting LUKS right.
One day, I might get my hands on a UEFI desktop.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-05 22:50 +0100 |
| Message-ID | <uTtgd-83A-7@gated-at.bofh.it> |
| In reply to | #189538 |
On 12/04/2017 12:17 AM, David Christensen wrote: > On 12/03/17 13:44, Dan Norton wrote: >> On 12/02/2017 02:35 PM, David Christensen wrote: >> I'm not making progress with this PC so I'll probably abandon GPT. >> The disk is 1T and it was handled by the extended partition scheme >> before this experiment and it probably can again. I still want to do >> LVM and multiboot a few systems though. > [...] > > When I mount /dev/sda1, I see: > > # mount -o ro /dev/sda1 /mnt/sda1 > > # mount | grep /mnt/sda1 > /dev/sda1 on /mnt/sda1 type vfat > (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) > > # df /dev/sda1 > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 973952 188 973764 1% /mnt/sda1 > > # tree -a /mnt/sda1 > /mnt/sda1 > `-- EFI > `-- debian > `-- grubx64.efi > > # ls -l /mnt/sda1/EFI/debian/grubx64.efi > -rwxr-xr-x 1 root root 178688 Dec 2 23:33 > /mnt/sda1/EFI/debian/grubx64.efi > > # file /mnt/sda1/EFI/debian/grubx64.efi > /mnt/sda1/EFI/debian/grubx64.efi: PE32+ executable (EFI application) > x86-64 (stripped to external PDB), for MS Windows > > > I can run various LVM commands to confirm that d-i/partman did what I > told it to do. > > > The next time I try this, I think I'll go the opposite extreme, feed a > blank disk to d-i, let partman automagically format the whole disk, > and see if GRUB installs, if the installation completes without error, > if the disk boots, and what the SSD contains. > This post is being sent from a fresh netinst: dan@mydeb:~$ uname -v #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) root@mydeb:/# fdisk -l Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x29f6f73a Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 976895 974848 476M ef EFI (FAT-12/16/32) /dev/sda2 976896 16601087 15624192 7.5G 83 Linux /dev/sda3 16603134 532223999 515620866 245.9G 5 Extended /dev/sda5 16603136 141600767 124997632 59.6G 8e Linux LVM /dev/sda6 141602816 266600447 124997632 59.6G 83 Linux /dev/sda7 266602496 391600127 124997632 59.6G 83 Linux /dev/sda8 391602176 516599807 124997632 59.6G 83 Linux /dev/sda9 516601856 532223999 15622144 7.5G 82 Linux swap / Solaris [...] As you can see, the partitioning scheme is primary/logical. Needed to get some work done. I'm in the process of restoring stuff from backup, but at least the saved emails are OK. The installer was involved in all partitioning. At the start of this thread and another, fdisk had been used to define sda1 and sda2. This time I tried not to over-think it. First, manual partitioning in the installer was used to remove the LVs and VGs. Then the physical partitions were removed, resulting in 1TB free space (the whole disk). There were lots of false starts, but I learned that you can reboot the installer and run it repeated through partitioning and eventually get things corrected. I lost count. Partitioning dread subsided and I began to relax. Next, primary partitions were defined for sda1 and sda2. Logical partitions for sda5-9. The installer automagically did sda3 Extended. When it complained that there was no EFI, sda1 was removed and the EFI put in its place. Now you are looking at this and thinking, "Boy, that is really sloppy. Wasting disk space like that." That's OK, I don't mind. Obviously sda1 is much bigger than needed and sda2 is not used at all but it boots *normally* at last. Onward to installing another Debian and I may try GPT again, too. Many thanks for your help, everyone. - Dan
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.debian.user
csiph-web