Yes, staring at a blank screen while important stuff is happening
sucks. A serial console might show more, I haven't tried it. OK, you
did. If there's a quiet in your kernel command line options get rid
of it, also splash. The list keeps changing and moving but see
https://www.kernel.org/doc/html/v4.10/admin-guide/kernel-parameters.html
earlyprintk sounds worth trying in there. Printk is messages from
the kernel.
I don't have an answer but my guess is it's a matter of timing, you're
trying to access something before it's ready because something is
quicker than something else. In the old days they used to do stuff
like hold the reset line active for N seconds to give everything
chance to boot then release reset. This isn't so different from
waiting for a hard drive to spin up. Or drives, worse yet, thinking
of those big cases with 4 5-1/4 SCSI drives in a RAID. They drew so
much power the controller was programmed to not start them all at
once, so you'd hear drives spinning up for 20-30 seconds. Without
holding down reset the sequence has to be right.
My SSD sits here in a box while I research things like how to put
multiple OSes on it, it's going into a Pinebook Pro.
On 3/21/20, David Pottage <david@electric-spoon.com> wrote:
Hello,
I have a RockPro64 running Armbian buster version 20.02.1 (Linux kernel
5.4.20-rockchip64)
I have connected an M.2 SSD via an adapter in the PCIe slot, and have
setup an LVM PV on it, with a number logical ext4 and btrfs volumes on it.
All this worked fine when I set it up, but when I went to reboot the
system, it never came back. On the serial console, I got a series of
message from the firmware and U-Boot, then "Starting kernel ..." and
nothing. (I waited about half an hour)
Suspecting the SSD, I powered off, disconnected it, and rebooted. After
a delay of about 2 minutes I got "Give root password, or Ctrl-D to
continue" (Not sure of the exact wording), so Iogged in, and edited
/etc/fstab to comment out or add "noauto" to the lines for all file
systems on the SSD. I was then able to reboot successfully.
Those volumes on the SSD will mount fine from the command line after
boot, but it looks like they don't mount successfully during boot, and
are preventing boot.
I suspect that there is some sort of issue with dependencies in systemd.
Perhaps the PCI bus or the LVM2 mapper is not ready when the kernel
attempts to mount the filesystems, but why would that block the boot,
rather than just adding a delay?
On one occasion, I attempted to boot with just a swap volume on the SSD
name in /etc/fstab, and I saw this in syslog:
Mar 21 19:52:57 jupiter systemd[1]: dev-jupiter\x2dvg1-swap.device: Job
dev-jupiter\x2dvg1-swap.device/start timed out.
Mar 21 19:52:57 jupiter systemd[1]: Timed out waiting for device
/dev/jupiter-vg1/swap.
Mar 21 19:52:57 jupiter systemd[1]: Dependency failed for
/dev/jupiter-vg1/swap.
Mar 21 19:52:57 jupiter systemd[1]: dev-jupiter\x2dvg1-swap.swap: Job
dev-jupiter\x2dvg1-swap.swap/start failed with result 'dependency'.
Mar 21 19:52:57 jupiter systemd[1]: dev-jupiter\x2dvg1-swap.device: Job
dev-jupiter\x2dvg1-swap.device/start failed with result 'timeout'.
Does anyone have an idea how I can fix this, or how to investigate
further, given that I don't see any output on the serial console or the
HDMI monitor when the boot fails?
Thanks,
--
David Pottage