On Thu, Jul 25, 2019 at 11:25 AM Grant Edwards <grant.b.edwa...@gmail.com> wrote: > > On 2019-07-25, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > > > All the examples I can find of people using root=PARTUUID=<> show the > > longer PARTUUID values you get with a GPT parition table. Does the > > root=PARTUUID=<> mechanism only work with GPT and not with DOS > > parition tables? > > The comments in the kernel source certinaly indicate that DOS PARTUUID > values should work. From init/do_mounts.c: > > /* > * Convert a name into device number. We accept the following variants: > [...] > * 6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the > * unique id of a partition if the partition table provides it. > * The UUID may be either an EFI/GPT UUID, or refer to an MSDOS > * partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero- > * filled hex representation of the 32-bit "NT disk signature", and PP > * is a zero-filled hex representation of the 1-based partition > number. > [...] > > I've also tried just passing root=/dev/sdb1 (which in the current > setup is consistently the device the root partition shows up on). > That doesn't work either and I'm begining to suspect that the kernel > simply isn't recognizing the USB storage device at all. > > I wish I could figure out how to get scrollback to work so I could see > all of the kernel messages before the panic...
Do you have all the necessary USB drivers compiled into the kernel? Check to make sure the following options are "y". CONFIG_USB_EHCI_HCD -- USB 2.0 CONFIG_USB_OHCI_HCD -- USB 1.0 (non-Intel) CONFIG_USB_UHCI_HCD -- USB 1.0 (Intel) CONFIG_USB_XHCI_HCD -- USB 3.0 CONFIG_USB_STORAGE CONFIG_BLK_DEV_SD
