Bug 238529 - System hangs during boot when attaching da0
Summary: System hangs during boot when attaching da0
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-geom mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-12 19:36 UTC by Moritz Schmitt
Modified: 2019-08-31 01:07 UTC (History)
2 users (show)

See Also:


Attachments
Output of dmesg, sysctl -a, and pciconf -lv (180.83 KB, text/plain)
2019-06-12 19:36 UTC, Moritz Schmitt
no flags Details
/etc/fstab (84 bytes, text/plain)
2019-06-18 04:16 UTC, Moritz Schmitt
no flags Details
/etc/rc.conf (440 bytes, text/plain)
2019-06-18 04:17 UTC, Moritz Schmitt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Schmitt 2019-06-12 19:36:40 UTC
Created attachment 205016 [details]
Output of dmesg, sysctl -a, and pciconf -lv

I am using FreeBSD-CURRENT (Rev. 348849) on a Lenovo Thinkpad T470. Every second time or so when I boot my system stops booting with the following last messages:

	(...)
	uhub0: 18 ports with 18 removable, self powered
	ugen0.2: <Generic EMV Smartcard Reader> at usbus0
	Enter passphrase for nvd0s1d: ugen0.3: <vendor 0x8087 product 0x0a2b> at usbus0
	ugen0.4: <SunplusIT Inc Integrated Camera> at usbus0
	ugen0.5: <vendor 0x138a product 0x0097> at usbus0
	ugen0.6: <Generic USB3.0-CRW> at usbus0
	umass0 on uhub0
	umass0: <Bulk-In, Bulk-Out, Interface> on usbus0
	umass0:  SCSI over Bulk-Only; quirks = 0x4000
	umass0:0:0: Attached to scbus0
	(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 
	(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
	(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
	(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
	(probe0:umass-sim0:0:0:0): Error 22, Unretryable error
	da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
	da0: <Generic- SD/MMC 1.00> Removable Direct Access SPC-4 SCSI device
	da0: Serial Number 20120501030900000
	da0: 400.000MB/s transfers
	da0: Attempt to query device size failed: NOT READY, Medium not present
	da0: quirks=0x2<NO_6_BYTE>

When I press Enter I get

	GEOM_ELI: Wrong key for nvd0s1d. Tries left: 2.
	Enter passphrase for nvd0s1d:

After entering my password to unlock the harddisk encryption everything continues normally

	GEOM_ELI: Device nvd0s1d.eli created.
	GEOM_ELI: Encryption: AES-XTS 256
	GEOM_ELI:     Crypto: hardware
	GEOM_ELI: Device nvd0s1b.eli created.
	GEOM_ELI: Encryption: AES-XTS 128
	GEOM_ELI:     Crypto: hardware
	(...)

I compiled FreeBSD from source by doing:

	# cd /usr/src
	# sudo make cleanworld
	# sudo make -j4 buildworld
	# sudo make -j4 buildkernel KERNCONF=BSD1993
	# cd /usr/src
	# sudo make installkernel KERNCONF=BSD1993
	# shutdown -r now
	# cd /usr/src
	# make installworld
	# shutdown -r now

The custom kernel config I use is GENERIC plus the following two lines:

	device iwm
	device iwmfw

Any idea what's going on?

Please find attached the output of dmesg, sysctl -a, and pciconf -lv.
Comment 1 Ben Woods freebsd_committer 2019-06-16 14:09:11 UTC
If I am understanding correctly, the confusion is in the third line of output:
"Enter passphrase for nvd0s1d: ugen0.3: <vendor 0x8087 product 0x0a2b> at usbus0"

The first part of that line is prompting you to enter your GELI passphrase to decrypt the hard drive - boot will pause until you complete this step.
"Enter passphrase for nvd0s1d:"

After that line is printed to the console, the kernel discovers some USB devices, and prints the details to the screen. It has an error in activating one of the USB devices, but that does not appear to be related at all to the boot process.

The confusion on your part is that the message that the boot has paused an is waiting for you to enter your passphrase is no longer the last thing on the screen - other unrelated messages have flooded over the top of that. It is not immediately apparent to you that the computer is waiting for your input.

Instead of pushing enter, if you immediately typed your GELI passphrase, it would continue the boot process (despite the other text having been written to the screen).

This user experience does leave a bit to be desired.
Comment 2 Moritz Schmitt 2019-06-16 19:04:49 UTC
Your explanation makes sense, thank you.

However, what's still unclear to me is why the system prompts for the password at all. I already entered the disk encryption password right at the beginning of the boot process (before even the FreeBSD loader menu appears). And, as I wrote, this only happens every second time or so.

How can I help debugging this issue?
Comment 3 Ben Woods freebsd_committer 2019-06-16 22:19:53 UTC
Can you please attach the following files?
/etc/rc.conf
/etc/fstab
/boot/loader.conf
Comment 4 Moritz Schmitt 2019-06-18 04:16:07 UTC
Created attachment 205193 [details]
/etc/fstab
Comment 5 Moritz Schmitt 2019-06-18 04:17:06 UTC
Created attachment 205194 [details]
/etc/rc.conf
Comment 6 Moritz Schmitt 2019-06-18 04:19:15 UTC
My system doesn't have /boot/loader.conf.
Comment 7 Ben Woods freebsd_committer 2019-06-21 23:32:31 UTC
I can't see it in either of those files you have attached, but something is causing nvd0s1d to be mounted as an encrypted filesystem.

Have you got any other files that do this?
/etc/rc.conf.local
/etc/rc.conf.d/*
/usr/local/etc/rc.conf.d/*
Comment 8 ota 2019-08-31 01:07:54 UTC
I have a USB drive with "auto-power-on".  As come implies, this USB drive cuts power off when PC is turned off.  This drive take a bit extra time such that I cannot use for USB booting as the USB drive isn't ready when BIOS looks for USB drive.

This USB drive always shuts off itself while kernel is loading.  Interestingly,  this power-off happens after kernel recognizes da0 once.  Then, it gets power-on again and kernel finds the device again and attaches.

In a different note, geli attach has -d option to detach once the last close.

If you have a similar USB drive or you have attach -d equivalent, kernel lose a contact to the geli devices.

It is random ideas I discover but not sure if these apply to you as well.