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.
Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop [Solved]
Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop
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
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
Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop
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.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.
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
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
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.
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.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'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
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
Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop
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".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.
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
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."
-- Richard Feynman
-- Richard Feynman
Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop
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.
Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop
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
-- Richard Feynman
Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop
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.
Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop
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.
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
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
-
- Posts: 152
- Joined: Thu Oct 17, 2019 5:37 pm
Re: Live Ventoy USB multiboot stuck at "Loading Hardware Specific Modules" on a Desktop
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.
Claims it can't even find its own CLI script.