Making USB ISO sticks

[turtlebay777]

I know that the MX Live USB maker is slightly more different but can anyone tell me why when you make an ISO on a USB stick the tool always takes up all of the rest of the space on the stick as well? For instance the ISO may only be 1.5GB but if you use a 32GB stick it uses up all that space.

[JayM]

I know that the MX Live USB maker is slightly more different but can anyone tell me why when you make an ISO on a USB stick the tool always takes up all of the rest of the space on the stick as well? For instance the ISO may only be 1.5GB but if you use a 32GB stick it uses up all that space.

To leave room for the two persistence files, one each for root and home, and enough extra free space for remastering. If it uses the entire device it allows people to run MX purely on the live USB stick without having to install it to their computers.

[dolphin_oracle]

I know that the MX Live USB maker is slightly more different but can anyone tell me why when you make an ISO on a USB stick the tool always takes up all of the rest of the space on the stick as well? For instance the ISO may only be 1.5GB but if you use a 32GB stick it uses up all that space.

when you use something that puts a iso image on a stick, something like dd or etcher or imgburn or something like that, the resultant filesystem is what I call a "disc-on-a-stick", and that filesystem is limited to the size of the iso, not the size of the stick. its basically still looks to the PC like an optical disc, but on a usb stick. and as a non-bonus, the usb stick's filesystem using these methods is read-only, like an optical disc.

tools like (mx-)live-usb-maker and even unetbootin and rufus take an iso and split out the live boot and squashfs from the desired iso. these are files that are then placed on the stick's filesystem, and so the remainder of the sticks space is still available, although its been formatted (and re-partitioned in MX-LUM's case). unetbootin doesn't even format the partitions first, although it also doesn't always work these days.

that's the layman's version anyway.

[turtlebay777]

Yeah but why does it take up so much space? Even the full installation on a hard drive wouldn't take up so much space.

[BitJam]

I know that the MX Live USB maker is slightly more different but can anyone tell me why when you make an ISO on a USB stick the tool always takes up all of the rest of the space on the stick as well? For instance the ISO may only be 1.5GB but if you use a 32GB stick it uses up all that space.

The command line version of live-usb-maker allows you to select how much of the usb-stick to use and how much to leave free. In the latest version (available on antiX-19 or from my git repo) allows you to start the live-usb with a data partition formatted to fat32 or ntfs, etc.

Since day-one, live-usb-maker has allowed you to select how much of the usb stick to use for the live-usb. The latest iteration lets you start the live-usb with a data partition which (I hear) makes it easier to share data with some versions of Windows.

[Head_on_a_Stick]

Yeah but why does it take up so much space?

Because the hybrid ISO images provide a combination of ISO, GPT & msdos partition tables and so cannot be altered by gparted or any of the other partitioning tools.

[JayM]

MX Live USB Maker has a setting for the percentage of space of the USB device to use, defaulting to 100% but user-adjustable.

[turtlebay777]

Perhaps I should have been clearer because so many here are concentrating on just MX and just the MX tool. That's why I posted in Chat rather than a MX headed forum.

I was asking on a much broader scale, so, why does any USB image maker (on any distro) use up all the room on a USB stick to make any Live Linux, say Ubuntu or Arch, or Debian, or Tiny Core or Fedora, etc.

[BitJam]

I was asking on a much broader scale, so, why does any USB image maker (on any distro) use up all the room on a USB stick to make any Live Linux, say Ubuntu or Arch, or Debian, or Tiny Core or Fedora, etc.

Most other distros create a live usb with a simple "dd" copy of the iso file. This copies the iso file byte by byte onto the usb storage device. The iso file has a read-only iso9660 files system so the usb device gets a read-only iso9660 file-system. This makes the rest of the usb-stick useless for anything else because in order to make use of the remainder of the it you would need to create a partition table at the beginning but this is space is already used up be the iso filesystem and bootloader.

Most storage devices show up like:

Code: Select all

/dev/sba
/dev/sdb1
/dev/sdb2
...

Here, /dev/sdb is the entire device. It was parititioned by adding a partition table to the beginning. The table points to other locations on the device, including the beginning and length of the partitions /dev/sdb1, /dev/sdb2, and so on.

But instead of partitioning /dev/sdb we could have put a file system directly on /dev/sdb. It doesn't have to be an iso9660 file system, it could be any file system. Some mp3 players do this and they only show up as a single device with no partitions. Some distros use a read-write file system as the first thing on the usb stick but still no partition table. This at least allows them to implement persistence.

However it's done, once you start the entire device with a file system instead of a partition table then the only thing that can go on the device is that one file system. OTOH, the (mx-)live-usb-maker goes to the trouble of making a partition table first on the usb stick. This gives you the flexibility of setting the size of the live-usb portion so you can use other parts (partitions) of the usb stick for other things.

So why doesn't everybody do it our way? Doing it our way was much harder and took a lot of hard work over many years:

Back in 2009, the antiX devs foresaw that usb flash drives would be the wave of the future for live Linux media. During the ensuing eight years antiX has been refining their live-usb technology striving to improve the live-usb experience and to find new and unique ways for making use of fast read-write live boot media. During this same time usb flash drives have got larger, more reliable, much cheaper, and much much faster.

So why didn't other distros adopt our system? I don't know for sure. We tried reaching out to them but there was zero interest. Perhaps this was due to a combination of NIH and the fact that good engineers are usually terrible salespeople.

Avoiding a partition table makes their live boot code simpler because they don't have to look at all partitions on all devices like:

Code: Select all

/dev/sda
/dev/sda1
/dev/sda2
...
/dev/sdb
/dev/sdb1
/dev/sdb2
...
/dev/sdc
/dev/sdc1
/dev/sdc2
...

They only have to look at the base devices:

Code: Select all

/dev/sda
/dev/sdb
/dev/sdc
...

If you mount partitions that are used for a Linux system during the early live boot (looking for the live system) the date and time of that access is recorded. Since the time is rarely set correctly during the early live boot process (another wonderful gift to the Linux world from Microsoft) those incorrect access times can cause scary warning messages when the installed Linux system next boots. Most other distros have been using a very simple and easy way to make live-usbs. The downsides are that it uses up all of the usb device and in some cases it's read-only. The plus side is it is simple and easy.

BTW: dolphin_oracle has experimented with porting our live system to other distros by installing our snapshot tool and using it to take a snapshot of the other system. This was very clever IMO.

[say_hello]

hello dear All

for creating a bootable USB-Stick i use the version from the following page :


http://mxrepo.com/

The preferred method of installing packages is by adding these repositories

For MX-19:
deb http://mxrepo.com/mx/repo/ buster main non-free (for MX-19 Main repo)

this means i download the version and create the iso on the stick...