util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* no result for blkid for EFI partition
@ 2019-09-03 15:47 Hank Barta
  2019-09-03 19:13 ` Karel Zak
  0 siblings, 1 reply; 2+ messages in thread
From: Hank Barta @ 2019-09-03 15:47 UTC (permalink / raw)
  To: util-linux

'm running into an issue I don;t understand. Short description:
installing Debian Buster to ZFS root and using LUKS encryption. Long
description: This is esecuting in a chroot in a VM running the Live
USB image for Debian Buster and following the instructions at
https://github.com/zfsonlinux/zfs/wiki/Debian-Buster-Root-on-ZFS.

The issue I'm running into is that `blkid` reports no information for
the EFI partition. The partition is created using
    wipefs -a /dev/disk/by-id/$DRIVE_ID     # useful if the drive
already had ZFS pools
    sgdisk --zap-all /dev/disk/by-id/$DRIVE_ID

    # 2.2 Partition your disk
    # Run this for UEFI booting (for use now or in the future):
    sgdisk     -n2:1M:+1024M -t2:EF00 /dev/disk/by-id/$DRIVE_ID
    export EFI_PART=/dev/disk/by-id/${DRIVE_ID}-part2

and formatted using
mkdosfs -F 32 -s 1 -n EFI ${EFI_PART}

The result is
root@debian:/# blkid /dev/sda2
root@debian:/#

root@debian:/# fdisk /dev/sda

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: VBOX HARDDISK
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: E560C0D8-7453-400C-8B08-C4A4E7741BF8

Device       Start      End  Sectors Size Type
/dev/sda2     2048  2099199  2097152   1G EFI System
/dev/sda3  2099200  4196351  2097152   1G Solaris /usr & Apple ZFS
/dev/sda4  4196352 16777182 12580831   6G Linux filesystem

Command (m for help): q

root@debian:/# ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 Sep  3 04:09 ata-VBOX_CD-ROM_VB2-01700376 -> ../../sr0
lrwxrwxrwx 1 root root  9 Sep  3 09:49
ata-VBOX_HARDDISK_VBed34bc29-2968e615 -> ../../sda
lrwxrwxrwx 1 root root 10 Sep  3 09:49
ata-VBOX_HARDDISK_VBed34bc29-2968e615-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep  3 09:49
ata-VBOX_HARDDISK_VBed34bc29-2968e615-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Sep  3 09:49
ata-VBOX_HARDDISK_VBed34bc29-2968e615-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 Sep  3 09:19 dm-name-luks1 -> ../../dm-0
lrwxrwxrwx 1 root root 10 Sep  3 09:19
dm-uuid-CRYPT-LUKS2-e21badad6d6b4db59d95d99d1e4fc9b1-luks1 ->
../../dm-0
root@debian:/# blkid
/dev/sda4: UUID="e21badad-6d6b-4db5-9d95-d99d1e4fc9b1"
TYPE="crypto_LUKS" PARTUUID="e0afc765-239f-4b3d-9afa-971a64801b73"
/dev/sda3: LABEL="bpool" UUID="3469266818014148396"
UUID_SUB="48979436116215382" TYPE="zfs_member"
PARTUUID="3c00e355-ee3a-430c-aa58-1478d4f00e36"
/dev/sr0: UUID="2019-07-06-12-12-54-00" LABEL="d-live nf 10.0.0 gn
amd64" TYPE="iso9660" PTUUID="720eaf06" PTTYPE="dos"
/dev/loop0: TYPE="squashfs"
/dev/mapper/luks1: LABEL="rpool" UUID="15828100763890880025"
UUID_SUB="8162042683520056023" TYPE="zfs_member"
root@debian:/# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root  9 Sep  3 04:09 2019-07-06-12-12-54-00 -> ../../sr0
lrwxrwxrwx 1 root root 10 Sep  3 09:49 3469266818014148396 -> ../../sda3
lrwxrwxrwx 1 root root 10 Sep  3 09:49
e21badad-6d6b-4db5-9d95-d99d1e4fc9b1 -> ../../sda4
root@debian:/#

Versions installed are
root@debian:/# apt-cache policy util-linux dosfstools
util-linux:
  Installed: 2.33.1-0.1
  Candidate: 2.33.1-0.1
  Version table:
 *** 2.33.1-0.1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status
dosfstools:
  Installed: 4.1-2
  Candidate: 4.1-2
  Version table:
 *** 4.1-2 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status
root@debian:/#

When I don't format anything using LUKS encryption, I get the expected result.

I think I can work around this but if it is a bug, it seems like I
should report. If it is something I'm doing wrong, it is an
opportunity to learn something.

I did some searching and only found issues where Windows and Linux
were both installed and there was some confusion with the
partitioning.

I'm not sure where to go next with this and appreciate any suggestions.

Thanks!

-- 
'03 BMW F650CS - hers
'98 Dakar K12RS - "BABY K" grew up.
'93 R100R w/ Velorex 700 (MBD starts...)
'95 Miata - "OUR LC"
polish visor: apply squashed bugs, rinse, repeat
Beautiful Sunny Winfield, Illinois

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: no result for blkid for EFI partition
  2019-09-03 15:47 no result for blkid for EFI partition Hank Barta
@ 2019-09-03 19:13 ` Karel Zak
  0 siblings, 0 replies; 2+ messages in thread
From: Karel Zak @ 2019-09-03 19:13 UTC (permalink / raw)
  To: Hank Barta; +Cc: util-linux

On Tue, Sep 03, 2019 at 10:47:08AM -0500, Hank Barta wrote:
> and formatted using
> mkdosfs -F 32 -s 1 -n EFI ${EFI_PART}
> 
> The result is
> root@debian:/# blkid /dev/sda2

Please, try 

   # LIBBLKID_DEBUG=all blkid -p /dev/sda2

and send the output. Thanks.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-09-03 19:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-03 15:47 no result for blkid for EFI partition Hank Barta
2019-09-03 19:13 ` Karel Zak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).