MX Linux Forum

Posted: **Sat Feb 13, 2021 11:36 pm**

Hi, I'm no expert in Linux but I've been getting acquainted with a few flavors since a couple of years ago. One way accomplishing that is by setting a Ventoy multiboot USB flash drive.

Most often I've been playing with MX-Linux 19.3 KDE x64 with 16 GB Persistence dat file, and so far so good saving lots of data in the dat virtual storage for a couple of months until, I guess, I made a terrible mistake and started getting stuck at the message of the Subject above...

A few days ago the system was left on for a day or two, with an extra empty flash drive attached to another USB port, when I decided to set the system to Suspend mode in order to save a little in the electric bill and get the system back quicker and right where it was before going to Suspend mode. Prior to turning the system back on in the day after, I decided first to replace the extra flash drive by another one, as it was not yet being used by me after all...

As a matter of fact, the system does save all current status information in regards the hardware, software, RAM and so on when going to Suspend mode, quite different from when going to shut down, of course.

Besides, now I can not either boot any other Linux in the Ventoy flash drive, either using or not using the Persistence dat file. Even the boot order in the BIOS settings is changed intermittently for some reason beyond my reasoning.

The screen where the message is displayed is a blank one. Hitting Enter takes the cursor down like a new line (wrap). Alt-F2/F3... does not work either. Nothing can be done.

I'm writing this topic on a dual boot W7/Debian Buster, and using Dolphin I can browse the ISO and dat files in the Ventoy USB multi boot flash drive, but no any other files seen there.

I deeply appreciate if anybody knows how to address this and get the Ventoy flash drive usable again without losing any information stored in it.

Let me know of any other additional detail you might need to resolve this issue.

See dropbox link of the boot screen below:

Loading Hardware Specific Modules.

Posted: **Sun Feb 14, 2021 12:48 am**

Did you know that Ventoy has a support forum? That would probably be a better place to ask for help. MX only supports the boot USB creation methods described in the user manual.

Posted: **Sun Feb 14, 2021 3:55 am**

If I were you, then I'd have reinstalled ventoy latest version (force update switch) onto the usb and copy the MX ISO again (rewrite) and check.
Then comes posting in ventoy and mx forums.

Posted: **Sun Feb 14, 2021 10:40 am**

JayM wrote: Sun Feb 14, 2021 12:48 am Did you know that Ventoy has a support forum? That would probably be a better place to ask for help. MX only supports the boot USB creation methods described in the user manual.

Thank you JayM! I think you have a good point, and I sure will do that. Although I think I had rather screwed up with MX-Linux booting process by replacing the extra flash drive... It was just working great before that mishap.

Will keep you posted while also waiting for other feedbacks as well.

Posted: **Sun Feb 14, 2021 10:55 am**

agnivo007 wrote: Sun Feb 14, 2021 3:55 am If I were you, then I'd have reinstalled ventoy latest version (force update switch) onto the usb and copy the MX ISO again (rewrite) and check.
Then comes posting in ventoy and mx forums.

Thank you Agni, yes you're right! I also thought doing that and a new Persistence dat file as well, as long as I could retrieve all the document files contained in the dat file beforehand.

About the MX ISO, I compared the one in the Ventoy flash drive with the original backed up in regards to its size and date and there's no difference. But the Persistence dat file has the date as the last time it was used. So my guess is all the information for booting and Suspend back on status are stored in the Persistence dat file?...

I know it is a challenge, but I also think it is a good one, and a great opportunity of learning out of it.

Posted: **Sun Feb 14, 2021 1:03 pm**

its nice of them to provide support for their own persistence system and mx, but I have no idea how it works nor what to do if their persistence file gets full or corrupted. with the antix live system, you can remaster your persistence files back into a the main read only image and then make new persistence files.

if you want to use persistence features, you should use our live-usb-maker tool.

Posted: **Sun Feb 14, 2021 5:25 pm**

Thanks to the OP for bringing VENTOY to my attention, interesting tool (i had been using YUMI before, but it runs on windows only)

@Plurix I think it's only normal that once mounted with dolphin (or other) you only see files that belong to the "main" partition; the second "boot" one probably shouldn't be messed with. Can you edit the boot line and remove the "quiet" cheatcode, you should then at least see how far the boot process works ...(no idea about those "HW specific modules, though)

@dolphin_oracle their README provides the following link regarding the persistence mechanism. Not that users should expect support from the MX devs for any such non MX-sanctioned feature, of course.

Posted: **Mon Feb 15, 2021 6:35 pm**

@dolphin_oracle thank you for your feedback. I have already posted at a Ventoy forum and still waiting for any fb from there. I do not want to remaster because, as I have already mentioned, don't want to lose the documents within it (no backups). Also I do not use MX's live-usb-maker tool because it is specific for MX only.

The beauty of Ventoy is it runs under any platform (be it Linux / Windows / MacOS) and it allows for multi boot and persistence. It was working great for me for almost half a year until I took the wrong action (Mea culpa) using MX Linux (The reason why I'm posting here, too).

@baldyeti thanks for your comments. You will love using MX Linux under Ventoy from the beginning, I'm sure. But I fear I have no clue how to edit the boot line to remove the "quiet" cheat code. The initial Ventoy screen shows a few Fn:options like Localboot, Tools, ExMenu I'm yet to give them a try, although I'm presuming it won't allow me to go to MX Linux boot area to edit anything...

Sure will let you know anything I learn about it...

Take a look at some shots here.

Posted: **Mon Feb 15, 2021 9:19 pm**

FYI I just went to ventoy boot menu, entered grub shell but issued no commands at all except for the reboot to get out of it and all came back to normal, as usual. MX Linux with Persistence back to business with no data loss at all!

Issue presumably resolved for now.

Thanks for you all!

Posted: **Mon Feb 15, 2021 9:20 pm**

If this is solved to your satisfaction, could you please mark the topic as solved by clicking the button with a checkmark icon next to the post containing the solution? Instructions are here. This will make it easier for others when they search the forum looking for a solution to the same problem. Thanks.

Posted: **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.

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.

Posted: **Tue Feb 16, 2021 7:41 pm**

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.

Posted: **Thu Feb 18, 2021 6:24 pm**

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).

Posted: **Thu Feb 18, 2021 9:05 pm**

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.

Posted: **Fri Feb 19, 2021 12:55 pm**

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.

Posted: **Fri Feb 19, 2021 1:12 pm**

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.

Posted: **Fri Oct 01, 2021 1:28 am**

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.

Posted: **Sat Oct 02, 2021 6:24 am**

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.

MX Linux Forum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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