Util-Linux Archive on lore.kernel.org
 help / color / Atom feed
From: Hank Barta <hbarta@gmail.com>
To: util-linux@vger.kernel.org
Subject: no result for blkid for EFI partition
Date: Tue, 3 Sep 2019 10:47:08 -0500
Message-ID: <CABTDG88idFakiMbMYCKB+GmCy5=G_LiAFDK2tW28M8xMDh17BA@mail.gmail.com> (raw)

'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

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:/# 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
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 ->
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"
/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

Versions installed are
root@debian:/# apt-cache policy util-linux dosfstools
  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
  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

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

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


'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

             reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 15:47 Hank Barta [this message]
2019-09-03 19:13 ` Karel Zak

Reply instructions:

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

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

  Avoid top-posting and favor interleaved quoting:

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

  git send-email \
    --in-reply-to='CABTDG88idFakiMbMYCKB+GmCy5=G_LiAFDK2tW28M8xMDh17BA@mail.gmail.com' \
    --to=hbarta@gmail.com \
    --cc=util-linux@vger.kernel.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Util-Linux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/util-linux/0 util-linux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 util-linux util-linux/ https://lore.kernel.org/util-linux \
	public-inbox-index util-linux

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git