Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop  [Solved]

When you run into problems installing MX Linux XFCE
Message
Author
User avatar
m_pav
Developer
Posts: 1739
Joined: Sun Aug 06, 2006 3:02 pm

Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop

#11 Post by m_pav »

You might not want to put such faith in the USB Flash media because by default, most USB Flash drives are designed for BOT, not to be used in a real-time live system. BOT is an acronym for Bulk Only Transport. If I were you. I'd be making a backup image of the USB drive quick smart after 6 months of use if the data contained therein is important to you.

A much better flash drive type for Live use is a drive manufactured to the USAP specification. UASP is an acronym for USB Attached SCSI Protocol and they have supremely better capabilities than BOT drives because they have a real controller, more in line with, though not the same as, that of a proper fixed disk like a HDD or an SSD. Furthermore, they are magnitudes of scale faster than a regular BOT drive.

Like others here, I can't emphasise enough how great our Live system is when used from a fully featured Live USB. I too use Ventoy when I only need a limited feature set, but you really can't go past a full featured Live ISO, there is so much more we have to offer that Ventoy simply can not provide.
Mike P

Regd Linux User #472293
(Daily) Lenovo T560, i7-6600U, 16GB, 2.0TB SSD, MX_ahs
(ManCave) AMD Ryzen 5 5600G, 32G, 8TB mixed, MX_ahs
(Spare)2017 Macbook Air 7,2, 8GB, 256GB SSD, MX_ahs

User avatar
Plurix
Posts: 15
Joined: Sun Dec 20, 2020 9:05 pm

Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop

#12 Post by Plurix »

m_pav wrote: Mon Feb 15, 2021 10:08 pm You might not want to put such faith in the USB Flash media because by default, most USB Flash drives are designed for BOT, not to be used in a real-time live system. BOT is an acronym for Bulk Only Transport. If I were you. I'd be making a backup image of the USB drive quick smart after 6 months of use if the data contained therein is important to you.

A much better flash drive type for Live use is a drive manufactured to the USAP specification. UASP is an acronym for USB Attached SCSI Protocol and they have supremely better capabilities than BOT drives because they have a real controller, more in line with, though not the same as, that of a proper fixed disk like a HDD or an SSD. Furthermore, they are magnitudes of scale faster than a regular BOT drive.
Yes Mike, I completely agree with you, as long as all components in the the chain support UASP, e.g. the USB device, the host PC hw (controllers) and its firmware, and the sw drivers in the OS. Otherwise you won't get the benefits of using UAS Protocol.

In my case:

Code: Select all

$ lsusb -v | grep "Lexar"
Bus 004 Device 002: ID 05dc:a838 Lexar Media, Inc. JumpDrive Tough
  idVendor           0x05dc Lexar Media, Inc
  
$ lsmod | grep uas
squashfs               65536  1
zstd_decompress        86016  1 squashfs
uas                    32768  0
usb_storage            81920  2 uas
scsi_mod              262144  6 sd_mod,usb_storage,uas,libata,sg,sr_mod
usbcore               315392  7 xhci_hcd,ehci_pci,usbhid,usb_storage,ehci_hcd,xhci_pci,ua
The code above shows my Lexar USB flash drive where multi boot Ventoy with several Linux flavors is installed. And it shows this flash drive supports UASP.

But:

Code: Select all

$ lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 05dc:a838 Lexar Media, Inc. JumpDrive Tough
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hu

$ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
    |__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 3: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 3: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480
    
 $ lspci
...
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
...
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
...
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
...
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)

$ lsusb -v -d 05dc:a838

Bus 004 Device 002: ID 05dc:a838 Lexar Media, Inc. JumpDrive Tough
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x05dc Lexar Media, Inc.
  idProduct          0xa838 JumpDrive Tough
  bcdDevice           11.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x002c
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              504mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               8
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               8
demo@mx1:/home

$ lsusb -v -d 05dc:a838 | grep bInterfaceProtocol
Couldn't open device, some information will be missing
      bInterfaceProtocol     80 Bulk-Only
 
In the code above you can see my Lexar flash drive is at Bus 04 Port 2 Driver=usb-storage instead of uas, so it (the Bus device) does not support uas.

Besides, notice that the only bInterfaceProtocol line value listed is 80 Bulk-Only instead of bInterfaceProtocol 98. bInterfaceProtocol 98 indicates the device supports the protocol required for UAS. If you see a bInterfaceProtocol 98 line, it means a UASP-configured device.

From what I read, you need 3 components to get UASP:
OS Support: Windows 8, Windows 10, Linux
USB controller support: Any USB 2 or 3+ interface that doesn't have UASP blacklisted (*).
UASP ready peripherals: UASP standards solidified near the end of USB 3.0 development so most USB 3.0 storage products are not UASP compatible.

(*) Some buggy chips were produced thus some products claiming UASP support have been blacklisted. Hopefully most USB 3.1 products will include UASP support.

Bottom line: speed is not a problem, and reliability is within my expectation for the time being. Human error was a factor in my issue.

See further details here and here.
Like others here, I can't emphasise enough how great our Live system is when used from a fully featured Live USB. I too use Ventoy when I only need a limited feature set, but you really can't go past a full featured Live ISO, there is so much more we have to offer that Ventoy simply can not provide.
I also fully agree with your statement above, Mike. The only reason I'm using Ventoy is because I am learning and familiarizing myself with the Linux family, and for me at least it is very convenient to play around and test the different flavors without the need to replace several USB flash drives every now and then, including being able to carry along with me wherever I go. No critical and / or classified documents are being stored on it. Just enjoying and having fun while learning.

I'm leaning to install a full blown MX Linux on both my DT and LT. When that happens, I sure will also have handy with me a Live USB MX Linux flash drive. But as the hw are jurassic, no expectations in regards to UASP.

Thank you for your heads up, MIke.
OSes: Debian Buster, Ventoy Multi Boot USB with Persistence with Linux Lite, Manjaro, MX Linux
HW: ASUS X570 Pro (WiFi) MoBo, Ryzen 5900 12 Cores, 128 GB RAM, 2 TB NVMe, 2 TB WD Blue 2.5" SSD, NVidia GTX 1650

User avatar
BitJam
Developer
Posts: 2303
Joined: Sat Aug 22, 2009 11:36 pm

Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop

#13 Post by BitJam »

Plurix wrote: Tue Feb 16, 2021 7:41 pmThe only reason I'm using Ventoy is because I am learning and familiarizing myself with the Linux family, and for me at least it is very convenient to play around and test the different flavors without the need to replace several USB flash drives every now and then, including being able to carry along with me wherever I go. No critical and / or classified documents are being stored on it. Just enjoying and having fun while learning.
FWIW, you might consider doing a frugal install (available from the text menus using "menus=p" boot option) to a data partition on your Ventoy device. This could give you the best of both worlds. It would give you access to almost all of our advanced live-usb features while sharing the Ventoy device with other distros. It will create a top level /MX-Fugal-xxxxx/ directory and optionally a top level /Live-usb-storage/ directory. In the /MX-Frugal-xxxxx directory will be a grub.entry file that you can add to an existing grub.cfg file for booting directly into the frugal install. You can also get to the frugal install by using the "frugal" boot option or related options. For example if the main data partition on the Ventoy device has the partition label "Ventoy-data" then you could boot into a frugal system installed there with "flab=Ventoy-data".

The main thing the frugal install does is copy the large linuxfs file (and some other files) from the iso file you booted from to the MX-Frugal-xxxxx directory on an existing partition you selected from a menu (or selected with a boot parameter such as "flab=yyyy"). One surprising thing we do is finish the boot from the newly copied linuxfs file so this process if very fast and does not require a reboot to be running from the newly installed system.

I think it's actually simpler and easier than it sounds. BTW, the "xxxxx" in /MX-Frugal-xxxxx" is the kernel version number. This makes it easy to run several different MX frugal installs side by side. It also ensures that if you're booting into the frugal install from a live-usb then the kernels must match.

If you want to modify a grub.cfg entry that is already booting from the MX iso to boot frugal then add these two cheats:

Code: Select all

frugal=root!,static flab=$PARTITION_LABEL
where $PARTITION_LABEL is the fs label of an existing partition where you want to do the install. When you reboot after the install was done then these same boot parameters will boot you into the installed frugal system. Both cheats enable frugal mode. The first also enables static root persistence and will offer to create the rootfs file if it doesn't already exist. The second one also tells us the fs label of the partition that has the frugal install (or that we should install to if the frugal install doesn't already exist).
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."

-- Richard Feynman

User avatar
Adrian
Developer
Posts: 8876
Joined: Wed Jul 12, 2006 1:42 am

Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop

#14 Post by Adrian »

I just tried what BitJam recommends, one small addition, if you want to do a frugal installation when you make the Ventoy drive you need to leave space at the end of the drive and partition that as FAT32, for some reasons frugal doesn't work with exFAT. Ventoy partition is by default formatted as exFAT.

User avatar
BitJam
Developer
Posts: 2303
Joined: Sat Aug 22, 2009 11:36 pm

Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop

#15 Post by BitJam »

Adrian wrote: Thu Feb 18, 2021 9:05 pm[...] for some reasons frugal doesn't work with exFAT.
Thanks Adrian! AFAIK exFAT requires fusermount and mount.exfat-fuse which are not currently in the live initrd. I will see if we can add them.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."

-- Richard Feynman

User avatar
Adrian
Developer
Posts: 8876
Joined: Wed Jul 12, 2006 1:42 am

Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop

#16 Post by Adrian »

That would be great, thanks! I've also noticed an issue with renaming the partition, I called it MX-Persist when I tried persistency then when I installed frugal it prompted me to name it antiX-Frugal I said "y" but it didn't take, it also didn't create the rootfs although I was prompted for it, maybe I was doing something wrong... eventually I was able to create it I think I did it by not using the frugal install but just selected to create root persistency, let me know if you want logs and more testing.

User avatar
Plurix
Posts: 15
Joined: Sun Dec 20, 2020 9:05 pm

Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop

#17 Post by Plurix »

Just browsing back after a good while and saw your (BitJam's and Adrian's) comments about the frugal install.

Will give it a try and let you know about it.
OSes: Debian Buster, Ventoy Multi Boot USB with Persistence with Linux Lite, Manjaro, MX Linux
HW: ASUS X570 Pro (WiFi) MoBo, Ryzen 5900 12 Cores, 128 GB RAM, 2 TB NVMe, 2 TB WD Blue 2.5" SSD, NVidia GTX 1650

Somewhat Reticent
Posts: 152
Joined: Thu Oct 17, 2019 5:37 pm

Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop

#18 Post by Somewhat Reticent »

Oh, good. I've been struggling to get Ventoy to work on one old box - even the latest version, which includes a GTK/Qt GUI option (that seems to exclude reserving space for access).
Claims it can't even find its own CLI script.

Post Reply

Return to “Installation”