Does anyone here use Mintstick for making livUSB's? Need testers.

greenjeans · 2025-05-23 22:18:32

Hey all, just wondering if anyone uses Mintstick for making quickie liveUSB's, I could really use some extra eyeballs and some testing if anyone would be willing.

Here's the gist of it: Mintstick works great for making a quick liveUSB, there's no options for persistence or additional partitions or multi-boot, if you want that I recommend and use Refracta2USB. But that's okay, it's fast and simple when you need to make one and test, doing what I do I literally use it multiple times in a day.

But it does take up the entire USB stick regardless of size, one giant ISO-9660 file when viewed in Gparted or your file-manager. Which is fine for everyday production use. But I also like to make for myself and family and friends a liveUSB that has a second partition purely for data, in FAT32 so any machine can read it, to carry files with you or if you're using it to do a rescue of files from a machine that's acting badly, you have a place to easily at least save important files right there on the stick. My iso's are typically 1.2 gb or less, so you can see the issue when I write one to a 32 or 64 gb stick, lotsa wasted space.

The gnome-disk-utility (GDU) comes in handy to do this, unlike Gparted it can "see" that there's a tremendous amount of empty space following the iso, and using it you can convert that space to a 2nd partition. It works fine and creates/formats the partition. But.....

1. GDU uses some CSD, and the result is a superfluous set of min-max-close buttons in addition to some other artifacts, and just looks silly.

2. It doesn't do it quite right, it's perfectly functional, but in Gparted it will still show one giant ISO-9660 partition as GDU omits an important step.

So i've been writing a one-trick-pony script that does the same thing, but does it right, purely a companion app to be run right after using the Mintstick image writer, that auto-detects the USB and makes a second partition in FAT32 and labels it "DATA".

It's working perfectly for me currently with the machines I have here and a small variety of different USB sticks, but USB can be very finicky, and USB sticks can vary greatly in how they're made and work, so I could really use some input and testing as I think this is a great small utility.

I just don't know if there's any folks here who would be interested, it's a pretty small niche app. But if I get a few replies i'll post the script, if not then I won't take up anymore space on the forum with this project.

Thanks!
~greenjeans

Altoid · 2025-05-23 23:09:00

Hello:

greenjeans wrote:

... anyone uses Mintstick ...

I don't use mintstick, last time I ran Mint was ~ 8 years ago.

It but I downloaded the cmd line version from the Devuan repository and installed it.
Drags along gir1.2-polkit-1.0 gir1.2-udisks-2.0 gir1.2-xapp-1.0 python3-gnupg python3-parted

Q: does it work better than dd?
You may recall I had a series of issues when I tried to dd an *.iso file to a 4Gb SD card/8Gb USB stick to use in my (non UEFI box) not long ago.
Had to jump through a lot of hoops to get it done. See here.

If you post instructions I can give mintstick a try then run your script and report.
ie: only a 64Gb stick available for testing.

Best,

A.

greenjeans · 2025-05-25 22:36:19

Sorry for the delay, have still been testing and fixing tiny bugs and errors, grammatical and syntax stuff. Doesn't look like anybody much is interested except my buddy Altoid, lol, but that's allright, it works great for me.

@Altoid: protocol:

Install Mintstick from the repo. Its a GUI app, so i'm not sure what you mean by "cmd line version"?
Plug in a USB stick.
Run the "USB Stick Formatter" component of Minstick from menu.
Run the "USB Image Writer" component of Mintstick from menu using any good iso (Vuu-do is a good 'un )
Run the Fatstick script.

I'm setting it up as a GUI app to be run from the menu with a .desktop added in /usr/share/applications, but for testing purposes running in a terminal will do.

I don't use sudo at all, I su-to-root to run admin tasks, so if you run the script that way, it will give you some chiding about running GUI apps as root, ignore that. But I am curious if you use sudo in terminal to launch it, if it will give those same warnings.

There's a ton of comments in the script, sorry but don't laugh at me, i'm old and I need 'em for easy reference as to what the heck i've done sometimes.

Script, save as "fatstick" and make executable:

#!/bin/bash

# This script is intended for use immediately after using Mintstick to create a
# liveUSB, it creates a 2nd partition for data in FAT32 on the remainder of the
# stick, i.e. if you have a 32 gig stick with a 4 gig iso on it, the script will
# create a 28 gig "DATA" partition in the empty space that follows the iso.

# Copyleft greenjeans 2025, use as you see fit.
# This is free software with NO WARRANTY, use at your own risk!

# Trap to ensure progress dialog is killed on script exit
trap 'kill $PROGRESS_PID 2>/dev/null' EXIT

# Function to display error dialog
error_dialog() {
    local error_message="$1"
    kill $PROGRESS_PID 2>/dev/null
    yad --center --borders=20 --fixed --window-icon=error --title="Error" \
        --height=150 --button="OK:0" \
        --text="$error_message"
    exit 1
}

# Must run with root privileges
if [ "$EUID" -ne 0 ]; then
    error_dialog "This script must be run as root (use sudo or su)."
fi

# Display initial dialog
yad --center --borders=20 --title="Fatstick" --window-icon=drive-removable-media \
    --fixed --height=325 --button="OK:0" --button="Cancel:1" \
    --text="This utility is for use on an existing liveUSB that is using an ISO-9660 filesystem
that takes up the entire stick, i.e. the type made by the Mintstick image writer.

If there is space after the iso, this will create a secondary data partition with
a FAT32 filesystem (for maximum compatibility with all operating systems) 
and label it 'DATA'.  WARNING: If the stick has existing secondary partition(s), 
the utility will overwrite them and you will lose any data stored on them.

Please ensure there is only one liveUSB with an ISO-9660 filesystem plugged
into your computer before using this utility or it will error out and close.

If you have not already plugged in a liveUSB, do so now before continuing.

Click 'OK' to proceed or 'Cancel' to abort."

if [ $? -ne 0 ]; then
    exit 0 
fi

# Start progress dialog in the background
yad --window-icon=drive-removable-media --progress --progress-text="working..." \
    --no-buttons --fixed --borders=20 --center --pulsate --width=400 --auto-close \
    --title="Creating new partition" &
PROGRESS_PID=$!

# Check for multiple USBs with iso9660 filesystems
ISO_COUNT=$(blkid -o device -t TYPE=iso9660 | wc -l)
if [ "$ISO_COUNT" -gt 1 ]; then
    error_dialog "Multiple USB devices with ISO-9660 filesystems detected.\n\nPlease unplug all but one USB device with an ISO-9660 filesystem and try again.\n\nRun 'blkid -o list' to identify connected devices."
elif [ "$ISO_COUNT" -eq 0 ]; then
    error_dialog "No USB with ISO-9660 filesystem found.\n\nRun 'lsblk -o NAME,FSTYPE,LABEL' and 'blkid' to diagnose."
fi

# Find the USB device with an iso9660 filesystem (Mintstick’s LiveUSB)
USB_PART=$(blkid -o device -t TYPE=iso9660 | head -n 1)
if [ -n "$USB_PART" ]; then
    USB_DEV=$(echo "$USB_PART" | sed 's/[0-9]*$//')
fi

# Fallback to lsblk if blkid fails
if [ -z "$USB_DEV" ]; then
    USB_PART=$(lsblk -o NAME,FSTYPE | grep iso9660 | awk '{print $1}' | head -n 1)
    USB_DEV=$(echo "$USB_PART" | sed 's/[0-9]*$//' | head -n 1)
    USB_DEV="/dev/${USB_DEV}"
fi

if [ -z "$USB_DEV" ] || [ ! -b "$USB_DEV" ]; then
    error_dialog "No USB with ISO-9660 filesystem found.\n\nRun 'lsblk -o NAME,FSTYPE,LABEL' and 'blkid' to diagnose."
fi

# Unmount any mounted partitions on the USB
umount "${USB_DEV}"* 2>/dev/null

# Get the partition table and disk info
FDISK_OUT=$(fdisk -l "$USB_DEV" 2>/dev/null)
if [ -z "$FDISK_OUT" ]; then
    error_dialog "Failed to read disk info with fdisk."
fi

# Extract the end sector of the iso9660 partition
ISO_END=$(echo "$FDISK_OUT" | grep "^${USB_PART}" | awk '{print $4}')
if [ -z "$ISO_END" ]; then
    error_dialog "Could not determine end sector of iso9660 partition."
fi

# Extract total sectors
TOTAL_SECTORS=$(echo "$FDISK_OUT" | grep "^Disk $USB_DEV" | grep -o '[0-9]\+ sectors' | awk '{print $1}')
if [ -z "$TOTAL_SECTORS" ]; then
    error_dialog "Could not determine total disk sectors."
fi

# Calculate start and size of the new partition
PART_START=$((ISO_END + 1))
PART_SIZE=$((TOTAL_SECTORS - PART_START))

# Check space (needs at least 1 MB = 2048 sectors)
if [ "$PART_SIZE" -lt 2048 ]; then
    error_dialog "Not enough free space to create a new partition (need at least 1 MB)."
fi

# Proactively wipe ISO-9660 signatures to prevent Gparted detection issues
wipefs -a -t iso9660 "$USB_DEV" 2>/dev/null || {
    error_dialog "Failed to wipe ISO-9660 signatures on $USB_DEV."
}

# Remove any existing secondary partitions
sfdisk --delete "$USB_DEV" 2 2>/dev/null

# Create a new partition using sfdisk
echo "start=$PART_START, size=$PART_SIZE, type=c" | sfdisk --append "$USB_DEV"
if [ $? -ne 0 ]; then
    error_dialog "Failed to create partition on $USB_DEV."
fi

# Check if the new partition was created
NEW_PART="${USB_DEV}2"
if [ ! -b "$NEW_PART" ]; then
    error_dialog "Failed to create partition $NEW_PART."
fi

# Refresh the partition table and wait for kernel to recognize new partition
partprobe "$USB_DEV"
sleep 2  # Give kernel time to update device nodes
for i in {1..3}; do
    if [ -b "$NEW_PART" ]; then
        break
    fi
    sleep 1
done
if [ ! -b "$NEW_PART" ]; then
    error_dialog "New partition $NEW_PART not detected by kernel."
fi

# Format the new partition as FAT32
mkfs.vfat -n "DATA" "$NEW_PART" 2>/dev/null
if [ $? -ne 0 ]; then
    error_dialog "Failed to format $NEW_PART as FAT32."
fi

# Verification of FAT32, 3 tries
for i in {1..3}; do
    if blkid -o device -t TYPE=vfat | grep "$NEW_PART" >/dev/null; then
        break
    fi
    sleep 1
done

if ! blkid -o device -t TYPE=vfat | grep "$NEW_PART" >/dev/null; then
    error_dialog "Could not verify FAT32 filesystem on $NEW_PART, but partition was created.\n\nCheck with 'lsblk -o NAME,FSTYPE,LABEL'."
fi

# Close progress dialog before showing success dialog
kill $PROGRESS_PID 2>/dev/null

# Display success dialog
yad --center --borders=20 --timeout=5 --fixed --height=100 \
    --window-icon=drive-removable-media --no-buttons --title="Fatstick" \
    --text="Success! New partition $NEW_PART created with FAT32 filesystem, labeled 'DATA'."

EDIT: here's the .desktop i'm using on my machine:

[Desktop Entry]
Name=Fatstick
Comment=Create a FAT32 data partition on a liveUSB
Exec=gksu.sh /usr/local/bin/fatstick
Type=Application
Icon=drive-removable-media
Terminal=false
Categories=Utility;

Last edited by greenjeans (2025-05-26 15:28:21)

fsmithred · 2025-05-25 23:40:53

Feel free to use this. No gui stuff. (I actually dissected it out of a gui app. You'll recognize some of it.) And yes, this uses dd.

#!/usr/bin/env bash
#
# iso2usb.sh
#set -x
#
# Run this script from the directory that contains your .iso files.
#

blocksize="1M"

[[ $(id -u) -eq 0 ]] || { echo -e "\n\t You need to be root!\n" ; exit 1 ; }

usbdevlist=$(/usr/sbin/hwinfo --usb --short | awk '/dev\/sd/ {print $1}')
usbdevfulllist=$(/usr/sbin/hwinfo --usb --short | awk '/dev\/sd/ {print $0}')

	echo -e "\n\tLIST OF REMOVABLE DRIVES\n${usbdevfulllist}\n${sdfulllist}\n${cdromfulllist}\n\nSelect a device:"
	select opt in $usbdevlist ; do
		device=$(echo "$opt" | awk '{ print $1 }')
		break
	done

if [[ -z "$device" ]] ; then
	echo "No device was found."
	exit 0
fi

echo -e "\n\tSelect the image file.\n"
select file in *.iso *.img ; do
	echo -e "\n$file"
	break
done

size=$(ls -lh $file | awk '{ print $5 }' | sed -e 's/M//')

if echo "$size" | grep -q G ; then
	size="$(echo "$size" | sed -e 's/\.//' -e 's/G//')00"
fi

echo "Size is ${size}M"

if echo "$size" | grep -q K ; then
	echo "Out of range units"
	exit 1
fi

echo -e "\n\tCopy $file to $device?\n\n\tThe command will be:\n\tdd if=$file | pv -s ${size}M | dd of=$device bs=${blocksize}\n\n"
echo -e " Press ENTER to continue or ctrl-c to abort."
read -p " "

dd if="$file" | pv -s ${size}M | dd of="$device" bs="$blocksize"
sync

exit 0

greenjeans · 2025-05-26 01:22:28

I do recognize that, I have that saved in my script experiments file!

This thing is just a very niche app, an experiment as is most of what I mess with. Might be some useful code to run with the above to automagically spit out a liveUSB with a data partition. I don't know that i've ever seen a poll to ask about people's preferences about
liveUSB's, do most just make a simple one, or do most prefer a persistence partition as well or data like I usually do?

I do like a dedicated app that does one thing and does it really well, hard not to like 'em.

Do the whole liveUSB plus a data partition and do it in like 200 lines of code or less....awww.yeeahhh

Altoid · 2025-05-26 12:34:14

Hello:

greenjeans wrote:

... the delay ...

No problem, seems you are quite busy.

greenjeans wrote:

... protocol:

Done.
Used a 2.0GB SD Card on a generic USB SD/Micro SD Card reader and wrote a Chimaera i386 *.iso.
No problems, was abe to boot my 1000HE both from SD Card in slot and SD Card in reader.

disks and gparted reported as expected.

Labelled the script 'fatstick', made it executable.
Ran is as root, I have specific permissions for sudo and too lazy to add another entry in sudoers.d.

$ sudo ./fatstick.sh
Sorry, user is not allowed to execute './fatstick.sh' as root on localhost.
$

But I get an error/warning:

# ./fatstick.sh
(yad:2866): Gtk-WARNING **: 09:21:27.813: cannot open display: 
#

Something in the script?

Best,

A.

fsmithred · 2025-05-26 13:21:05

"su" vs. "su -" problem? Those usually give you a "command not found" error. More likely the environment issue (root vs. user)

If you want to be able to run root programs on the user's desktop like you used to do before su got moved into util-linux, do this:

echo "Always_set_path yes" >> /etc/default/su

Then log out and log in using "su" and compare your PATH to what it was before. (or try to run a graphical app as root)

ralph.ronnquist · 2025-05-26 13:21:13

You may need to make "root" have access and permissions to use "non-root"'s X display.
E.g use pgrep -a Xorg to learn the pathname for the authority file, (might be /var/lib/xdm/authdir/authfiles/A:0-tznMUP or something else, say, /AAA). Then run with

XAUTHORITY=/AAA DISPLAY=:0 ./fatstick.sh

greenjeans · 2025-05-26 14:25:24

Yeah on my machine that I test with, I have done what fsmithred outlined above on all of my stuff.

I've also tested it added as a menu entry and still working great, i'm using a workaround for pkexec hoopla, a tiny script to fill in the blanks I call gksu.sh on my machine, it's some code that's been around as long as pkexec has. So the exec command for the .desktop is "gksu.sh /path/to/fatstick (/usr/local/bin/ is what i'm using). I just added the .sh to the name to avoid confusion with the real gksu which is sadly gone.

#!/bin/sh
# Script to convert gksu to pkexec for extensions already written
# without adding a lot of code to the .desktop command line.

COMMAND=$1
shift #shift first arg
for ARG in "$@"
do
 if [ -z "$ARGS" ]; then
  ARGS="$ARG"
 else
  ARGS="$ARGS $ARG"
 fi 
done
ARGS=\'$ARGS\'
eval pkexec env DISPLAY="$DISPLAY" XAUTHORITY="$XAUTHORITY" "$COMMAND" "$ARGS"
exit 0

greenjeans · 2025-05-26 14:36:45

To be clear, I still have my training wheels on when it comes to writing scripts. This utility is part of my own self-training regimen which is to start writing more complex scripts than my usual tiny ones, not to the level of full-blown apps, just small targeted helper-scripts that aim to fix one or more small challenges. I have a ton of such things on the back-burner that are not yet working, this script is the 2nd successful one.

Altoid · 2025-05-26 15:21:48

Hello:

fsmithred wrote:

"su" vs. "su -" problem?

Don't think so.

I have used su - since it changed from su.
ie: I never use su and my use of sudo is for a set of specific commands.

fsmithred wrote:

... likely the environment issue (root vs. user) ...
... run root programs on the user's desktop like you used to do ...

I checked.
It would seem I probably did that long ago:

$ cat /etc/default/su
# restore the old 'su' behaviour
# no 'su-' | just use 'su' as before
# see https://files.devuan.org/devuan_beowulf/Release_notes.txt

ALWAYS_SET_PATH yes
$

Maybe that's the problem?
It should be no?

fsmithred wrote:

... try to run a graphical app as root.

Right.
Examples:

# thunar
thunar: Failed to initialize Xfconf: Cannot autolaunch D-Bus without X11 $DISPLAY
(thunar:4055): Gtk-WARNING **: 11:42:29.809: cannot open display: 
#

# jpilot
(jpilot:4525): Gtk-WARNING **: 11:51:05.663: cannot open display: 
#

# synaptic
Failed to initialize GTK.
Probably you're running Synaptic on Wayland with root permission.
Please restart your session without Wayland, or run Synaptic without root permission
#

ralph.ronnquist wrote:

... need to make "root" have access and permissions to use "non-root"'s X display.

Yes, seems that it was what thunar was bitching about. (?)

ralph.ronnquist wrote:

... use pgrep -a Xorg to learn the pathname for the authority file ...

$ pgrep -a Xorg
2204 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/slim.auth vt07
$

ralph.ronnquist wrote:

Then run with ...

Like this? (checking first)

$ XAUTHORITY=/usr/lib/xorg/Xorg DISPLAY=:0 ./fatstick.sh

I'll return in a while ...

Best,

A.

Altoid · 2025-05-26 21:29:11

Hello:

I wrote:

Maybe that's the problem?

Indeed it was. 8^°
ie: pebkac

Fixed that.

$ cat /etc/default/su
# restore the old 'su' behaviour
# no 'su-' | just use 'su' as before
# see https://files.devuan.org/devuan_beowulf/Release_notes.txt
# ALWAYS_SET_PATH yes
$

Now, with su and sudo:

[root@devuan isos]# sudo ./fatstick.sh
/dev/sdg: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31
Checking that no-one is using this disk right now ... OK

Disk /dev/sdg: 1.89 GiB, 2032664576 bytes, 3970048 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x23927a24

Old situation:

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1  *       64 2333951 2333888  1.1G 17 Hidden HPFS/NTFS

/dev/sdg2: Created a new partition 2 of type 'W95 FAT32 (LBA)' and of size 798.9 MiB.
Partition #2 contains a vfat signature.
/dev/sdg3: Done.

New situation:
Disklabel type: dos
Disk identifier: 0x23927a24

Device     Boot   Start     End Sectors   Size Id Type
/dev/sdg1  *         64 2333951 2333888   1.1G 17 Hidden HPFS/NTFS
/dev/sdg2       2333952 3970047 1636096 798.9M  c W95 FAT32 (LBA)

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
[root@devuan isos]#

I think it works properly.
ie: as advertised -> no small feat.

Just one thing ...
At some point towards the end of the job, I think (?) the stick is unmounted and then remounted.
Not sure of that.

The first time I tried the script it ended with a a pop-up with an error and the second partition was not formatted. (unknown)
I then ran the script again and it ended with a formatted FAT32 partition, no errors.

To check, I ran the whole process again: blanked the SD card, ran the format / image writing applications and then the script.

Although the same thing happened ie: the pop-up with an error for writing the second partition, on checking I saw that the second partiton had been formatted.

You may want to test and see if a short pause somewhere between the creation of the second partition and formatting it to FAT32 would avoid that.

Let me know if you need anything else.

Best,

A.

Last edited by Altoid (2025-05-26 21:32:12)

ralph.ronnquist · 2025-05-26 23:10:33

To be a bit security minded, the script would rather isolate the one or two command(s) that actually require root, and make due wrapping for them, instead of "user transition wrapping" let root run X (display) programs.

And in a normal linux OS there is good use of the disk group, which would be a sufficient permission for running those disk device manipulation commands. (Possibly this has got lost since there are so many M$ heads putting their fingers into linux s/w nowadays; does your udev rules assign group permission for removable devices?)

I.e., to become root is just a "lazy convenience" in this case; easy to do, easy to talk about but sacrificing on security. (Though umount will require root). I do it all the time myself

Also, @greenjeans, (and for the benefit of the grandkids) the blkid verification does not in any way verify the result of the partition formating (by mkfs.vfat), but rather the result of sfdisk, i.e., that the partition table declares a vfat partition. You may use fsck for that although it'd typically be sufficient to accept the successful run of mkfs.vfat as evidence that formatting went well.

greenjeans · 2025-05-27 00:13:26

Although the same thing happened ie: the pop-up with an error for writing the second partition, on checking I saw that the second partiton had been formatted.
You may want to test and see if a short pause somewhere between the creation of the second partition and formatting it to FAT32 would avoid that.

Thanks for testing @Altoid!

Yeah I had similar errors myself multiple times when testing later versions of the script. And sometimes it would error, yet work perfectly.

if you notice there are already some "timeouts" in there that fixed this on my machine at least. That's great info you gave me, seems I may need to extend/add some time in those areas. The script does work fast, too fast it seems for some other parts of the system. Any chance I could get specs of the machine you tested it on?
ETA: Also, model and size of stick?

And yeah, the stick winds up unmounted at the end of the process, but should still show in your file-manager as being present, so you should be able to just click the new partition(s) to mount. Pretty much all of my testing thus far has been in Mate, I need to run some tests in my Openbox partitions (though it should be same result).

@RRQ: Thanks for weighing in on this, I need to study your post a bit and do some research, again, i'm a rookie at this, but blkid seems to work fine for that check, if there's no vfat partition on that stick it's going to error out as it should, which is all i'm after...but yeah it may actually be a superfluous check anyway, i'm working off the premise right now that "if there's anything that gets done, it probably needs an error check". Which is mainly actually for my benefit to make it easier and faster to de-bug, some stuff probably doesn't need to be in the final script I guess.

ETA: Just wanted to re-iterate, I REALLY appreciate any and all comments and testing and suggestions, they are immensely helpful and give me things to consider that I might have not thought about, you guys rock and although my brain hurts a bit right now i'm still having a lot of fun with this stuff.

Last edited by greenjeans (2025-05-27 00:34:19)

Altoid · 2025-05-27 12:22:19

Hello:

ralph.ronnquist wrote:

... use of the disk group ...
... sufficient permission for running ...

I belong to all the groups I thought were needed when I set up this box long ago with Devuan jesse, things may well have changed or not.
eg: I nuked exim back when I was running Beowulf but I see the group Debian-exim:x: 104: is still there, so I fixed that.

# groupdel Debian-exim
#

Then there are groups which call my attention:

$getent group | grep systemd
systemd-journal:x:119:
systemd-timesync:x:120:
systemd-network:x:121:
systemd-resolve:x:122:
systemd-bus-proxy:x:123:
$

I see no reason for a Devuan user to belong to any of them.
ie: because -> Devuan but that may not be enough ...

I suspect a rogue (to give it a name) application could well add a user to any/all of those.
Made me wonder if they should be part of what Devuan should not have in its system. ie: sanitised

That said, the disk group is still there but, alas, I am not in it.
Fixed that.

ralph.ronnquist wrote:

... does your udev rules assign group permission for removable devices?

The default udev set lists the disk group:

[root@devuan rules.d] # cat 50-udev-default.rules | grep disk
SUBSYSTEM=="block", GROUP="disk"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="0", GROUP="disk"
KERNEL=="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|nrawqft[0-9]*", GROUP="disk"
KERNEL=="loop-control", GROUP="disk", OPTIONS+="static_node=loop-control"
KERNEL=="btrfs-control", GROUP="disk"
KERNEL=="rawctl", GROUP="disk"
SUBSYSTEM=="raw", KERNEL=="raw[0-9]*", GROUP="disk"
SUBSYSTEM=="aoe", GROUP="disk", MODE="0220"
[root@devuan rules.d]#

No idea if they are what they should be.
The folder for custom udev rules has this:

[root@devuan ~]# ls /etc/udev/rules.d
59-smfp_samsung.rules
60-vboxdrv.rules
70-persistent-net.rules
[root@devuan ~]#

I am member of the sudo group but for the use of a specific set of commands with rules in /etc/sudoers.d.
eg: updatedb, fdisk -l, etc.
Some without user PW and, in an attempt to keep me on my toes, some needing it to run.

The rest of the important commands are run as root.
I'd appreciate your letting me know if something is amiss in how this is set up.

Thanks for your input.

Best,

A.

Altoid · 2025-05-27 13:01:05

Hello:

greenjeans wrote:

Thanks ...
... had similar errors ...
... great info ...

Glad I could be of help.

greenjeans wrote:

... specs of the machine you tested it on?
... model and size of stick?

Box is a ca. 2009 Sun Microsystems Ultra 24 WS with an Intel Q9550 / 8Gb RAM - Linux 6.1.0-37-amd64 x86_64
Swap file in RAM.

$ sudo swapon -s
Filename				Type		Size		Used		Priority
/dev/sdb3                               partition	2749436		0		-2
/dev/zram0                              partition	6291452		0		100
$

The memory is a standard Sandisk SD (Class 2) 2.0Gb Card on a generic USB 2.0 SD /MicroSD Card reader plugged into a USB 3.0 slot.

The difference in read/access speeds between a Class 2 SD card, USB 2.0 reader in a USB 3.0 slot and a swapfile in RAM may (?) account for whatever happens timing wise. I'd say that, in this specific case, you don't need fast.
ie: accurate and reliable would be the thing to aim for.

Best,

A.

greenjeans · 2025-05-27 14:55:19

Okay that's a funky set-up my friend, sd card in a USB 2 converter, plugged into a USB3 slot...That's definitely an edge case, surprised it worked at all.

How you got a USB 3.0 slot on a 2009 machine?

Edit: Really need some more testing, preferably some garden-variety testing using actual USB sticks.

C'mon ya'll, help a brother out, this may not be important to ya, but it increases my knowledge and skill level which I hope to leverage into making myself of more use to Devuan and the community in the years to come, so it will benefit you too as Devuan users.

Last edited by greenjeans (2025-05-27 15:56:58)

Altoid · 2025-05-27 15:54:12

Hello:

greenjeans wrote:

... funky set-up ...

Indeed ...

greenjeans wrote:

... surprised it worked at all.
... a USB 3.0 slot on a 2009 machine?

The U24 MB has two front and four rear USB 2.0 sockets as well as one internal USB 1.1 USB.
There are two useless 1394a Firewire sockets but I've never used them and have blacklisted the kernel module.

For USB 3.0 I have a PCIe X1 USB card with four external sockets, jury-rigged to a (rather crappy) USB 2.0/3.0 hub occupying the 5.25" bay where the OEM CD/DVD drive was. I keep a ca. 2009 LG GB08LU11 Super Multi DVD Writer at hand just in case I need to boot from a CD/DVD or read/write optical media.

Best,

A.

Last edited by Altoid (2025-05-27 15:56:12)

greenjeans · 2025-05-27 18:55:51

Wow, even funkier! Okay I think anyone would agree that's a pretty non-traditional and uncommon setup, and after some thought it seems like to me that your wild daisy-chain of things there, has introduced some additional latency which contributed to the errors. Quite frankly i'm amazed it worked at all.

Still it's good exercise in edge-case scenarios and dealing with them. I think maybe just adding a "sleep 1" (or 2) right around line 126, right before the partition check, might make it work for your case.

I also have a cli version of the script, it might be easier to test that in your situation, let me know and i'll post it with an added sleep command in that section.

ETA: thinking more about it, in a newer machine there's probably not even a need to do any of the timeouts. My machine is old and very low spec even for it's time, 2012 Compaq with a dual-core APU @ likely 700-800 mhz actual, and 4gb of old ram.

But of course that's a lot of the point of what I do, I work on older machines and try to make them run, knowing if it works on my machine it's likely to work on anything from the last 15 years, and should work really well on anything newer than 2015 or so.

Last edited by greenjeans (2025-05-27 20:04:14)

greenjeans · 2025-05-27 20:12:35

Here's a CLI version of the script, @Altoid I have not added the additional sleep command here, if you test it maybe try it as-is first, and then if it fails at the check, add sleep 1 on line 106, maybe sleep 2. It would be awesome if you could also just try using a regular usb stick plugged in to one of your machines original usb 2 ports.

#!/bin/bash

# Fatstick CLI: Creates a secondary FAT32 data partition on a liveUSB made with Mintstick.
# Copyleft greenjeans 2025, use as you see fit.
# This is free software with NO WARRANTY, use at your own risk!

# Function to display error message and exit
error_exit() {
    local error_message="$1"
    echo "Error: $error_message" >&2
    exit 1
}

# Must run with root privileges
if [ "$EUID" -ne 0 ]; then
    error_exit "This script must be run as root (use sudo or su)."
fi

# Display initial prompt
echo "This utility is for use on an existing liveUSB with an ISO-9660 filesystem"
echo "created by Mintstick. It will create a secondary FAT32 data partition labeled"
echo "'DATA' in the remaining space. WARNING: Existing secondary partitions will be"
echo "overwritten, and data on them will be lost."
echo ""
echo "Ensure only one liveUSB with an ISO-9660 filesystem is plugged in."
echo "Run 'lsblk -o NAME,FSTYPE,LABEL' or 'blkid' to check connected devices."
echo ""
echo "Continue? (y/n): "
read -r response
if [ "$response" != "y" ] && [ "$response" != "Y" ]; then
    echo "Aborted."
    exit 0
fi

# Check for multiple USBs with iso9660 filesystems
ISO_COUNT=$(blkid -o device -t TYPE=iso9660 | wc -l)
if [ "$ISO_COUNT" -gt 1 ]; then
    error_exit "Multiple USB devices with ISO-9660 filesystems detected. Unplug all but one and try again. Run 'blkid -o list' to identify devices."
elif [ "$ISO_COUNT" -eq 0 ]; then
    error_exit "No USB with ISO-9660 filesystem found. Run 'lsblk -o NAME,FSTYPE,LABEL' and 'blkid' to diagnose."
fi

# Find the USB device with an iso9660 filesystem
USB_PART=$(blkid -o device -t TYPE=iso9660 | head -n 1)
if [ -n "$USB_PART" ]; then
    USB_DEV=$(echo "$USB_PART" | sed 's/[0-9]*$//')
fi

# Fallback to lsblk if blkid fails
if [ -z "$USB_DEV" ]; then
    USB_PART=$(lsblk -o NAME,FSTYPE | grep iso9660 | awk '{print $1}' | head -n 1)
    USB_DEV=$(echo "$USB_PART" | sed 's/[0-9]*$//' | head -n 1)
    USB_DEV="/dev/${USB_DEV}"
fi

if [ -z "$USB_DEV" ] || [ ! -b "$USB_DEV" ]; then
    error_exit "No USB with ISO-9660 filesystem found. Run 'lsblk -o NAME,FSTYPE,LABEL' and 'blkid' to diagnose."
fi

# Unmount any mounted partitions on the USB
umount "${USB_DEV}"* 2>/dev/null

# Get the partition table and disk info
FDISK_OUT=$(fdisk -l "$USB_DEV" 2>/dev/null)
if [ -z "$FDISK_OUT" ]; then
    error_exit "Failed to read disk info with fdisk."
fi

# Extract the end sector of the iso9660 partition
ISO_END=$(echo "$FDISK_OUT" | grep "^${USB_PART}" | awk '{print $4}')
if [ -z "$ISO_END" ]; then
    error_exit "Could not determine end sector of iso9660 partition."
fi

# Extract total sectors
TOTAL_SECTORS=$(echo "$FDISK_OUT" | grep "^Disk $USB_DEV" | grep -o '[0-9]\+ sectors' | awk '{print $1}')
if [ -z "$TOTAL_SECTORS" ]; then
    error_exit "Could not determine total disk sectors."
fi

# Calculate start and size of the new partition
PART_START=$((ISO_END + 1))
PART_SIZE=$((TOTAL_SECTORS - PART_START))

# Check space (needs at least 1 MB = 2048 sectors)
if [ "$PART_SIZE" -lt 2048 ]; then
    error_exit "Not enough free space to create a new partition (need at least 1 MB)."
fi

# Proactively wipe ISO-9660 signatures to prevent Gparted detection issues
echo "Wiping ISO-9660 signatures..."
wipefs -a -t iso9660 "$USB_DEV" 2>/dev/null || {
    error_exit "Failed to wipe ISO-9660 signatures on $USB_DEV."
}

# Remove any existing secondary partitions
echo "Removing existing secondary partitions..."
sfdisk --delete "$USB_DEV" 2 2>/dev/null

# Create a new partition using sfdisk
echo "Creating new partition..."
echo "start=$PART_START, size=$PART_SIZE, type=c" | sfdisk --append "$USB_DEV"
if [ $? -ne 0 ]; then
    error_exit "Failed to create partition on $USB_DEV."
fi

# Check if the new partition was created
NEW_PART="${USB_DEV}2"
if [ ! -b "$NEW_PART" ]; then
    error_exit "Failed to create partition $NEW_PART."
fi

# Refresh the partition table and wait for kernel to recognize new partition
echo "Refreshing partition table..."
partprobe "$USB_DEV"
sleep 2
for i in {1..3}; do
    if [ -b "$NEW_PART" ]; then
        break
    fi
    sleep 1
done
if [ ! -b "$NEW_PART" ]; then
    error_exit "New partition $NEW_PART not detected by kernel."
fi

# Format the new partition as FAT32
echo "Formatting new partition as FAT32..."
mkfs.vfat -n "DATA" "$NEW_PART" 2>/dev/null
if [ $? -ne 0 ]; then
    error_exit "Failed to format $NEW_PART as FAT32."
fi

# Verification of FAT32, 3 tries
for i in {1..3}; do
    if blkid -o device -t TYPE=vfat | grep "$NEW_PART" >/dev/null; then
        break
    fi
    sleep 1
done

if ! blkid -o device -t TYPE=vfat | grep "$NEW_PART" >/dev/null; then
    error_exit "Could not verify FAT32 filesystem on $NEW_PART, but partition was created. Check with 'lsblk -o NAME,FSTYPE,LABEL'."
fi

# Display success message
echo "Success! New partition $NEW_PART created with FAT32 filesystem, labeled 'DATA'."

Altoid · 2025-05-27 20:23:10

Hello:

greenjeans wrote:

... introduced some additional latency ...

I've given that some thought.
The weakest link here is the Class 2 2.0Gb SD Card + SD Card reader.
disks clocks it at an average read rate of 10.5MB/s, average write speed is probably slower.
By comparison, the SAS drive from which the *.iso file was read is clocked at an average read rate of 105.2 MB/s.
ie: 10X higher using the same size (10MB) sample.

greenjeans wrote:

... cli version of the script ...

No need.
Patch the script, test it and let me know the additions.
ie: line number and syntax so I can just add them verbatim to the original.

Best,

A.

Edit:
Posts crossed while I was making espresso.
I'll run the tests and post as soon as I get it done, later tonight or early tomorrow.

.

Last edited by Altoid (2025-05-27 21:13:33)

greenjeans · 2025-05-27 20:45:39

Sweet, thank you!!

Just need to try sleep 1 or maybe sleep 2, just add it on:

GUI script : Should be line 125
CLI script : Should be line 106

That's an empty line in both scripts right before the "# Check if the new partition was created" function. It may take more than that, but let's try the simplest thing first.

Lol, if we can get it to work on your set-up i'm pretty sure it's bulletproof!

P.S. I owe you a beer my friend, if you ever find yourself in the Midwest section of the US, give me a shout!

Altoid · 2025-05-27 21:13:11

Hello:

greenjeans wrote:

... thank you ...

You're welcome.

Done.
Ran the whole process over again, just in case.
ie: format and write *.iso with mintstick and then the new script as executable.

Here is the terminal printout:

[root@devuan isos]# sudo ./fscli.sh
This utility is for use on an existing liveUSB with an ISO-9660 filesystem
created by Mintstick. It will create a secondary FAT32 data partition labeled
'DATA' in the remaining space. WARNING: Existing secondary partitions will be
overwritten, and data on them will be lost.

Ensure only one liveUSB with an ISO-9660 filesystem is plugged in.
Run 'lsblk -o NAME,FSTYPE,LABEL' or 'blkid' to check connected devices.

Continue? (y/n): 
y
Wiping ISO-9660 signatures...
/dev/sdg: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31
Removing existing secondary partitions...
Creating new partition...
Checking that no-one is using this disk right now ... OK

Disk /dev/sdg: 1.89 GiB, 2032664576 bytes, 3970048 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x23927a24

Old situation:

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1  *       64 2333951 2333888  1.1G 17 Hidden HPFS/NTFS

/dev/sdg2: Created a new partition 2 of type 'W95 FAT32 (LBA)' and of size 798.9 MiB.
Partition #2 contains a vfat signature.
/dev/sdg3: Done.

New situation:
Disklabel type: dos
Disk identifier: 0x23927a24

Device     Boot   Start     End Sectors   Size Id Type
/dev/sdg1  *         64 2333951 2333888   1.1G 17 Hidden HPFS/NTFS
/dev/sdg2       2333952 3970047 1636096 798.9M  c W95 FAT32 (LBA)

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
Refreshing partition table...
Formatting new partition as FAT32...
mkfs.fat 4.2 (2021-01-31)
Success! New partition /dev/sdg2 created with FAT32 filesystem, labeled 'DATA'.
[root@devuan isos]#

Script exited without errors and SD Card boots my 1000HE as expected.

greenjeans wrote:

... if you ever find yourself in the Midwest section of the US ...

Of course ...

Best,

A.

greenjeans · 2025-05-27 21:31:26

(emoji doing the happy dance!)

Awesome, one last question my friend and i'll stop harassing you, did you add the extra sleep command to the script to get it to work or did the CLI version work for you without having to add the extra code?

Altoid · 2025-05-27 22:46:57

Hello:

greenjeans wrote:

... one last question ...

No problem.

greenjeans wrote:

... add the extra sleep command ...

No, did not touch it.
Just copied the script, labelled and made executable.

greenjeans wrote:

...work for you without having to add the extra code?

Apparently ...

But I think I found a use case where the script does not work.
ie: in UEFI boxes.

As you may recall, I used a Chimaera i386 *.iso.file from the Devuan repository.
devuan_chimaera_4.0.3_i386_desktop-live.iso

This *.iso file did not generate a #$%& UEFI partition when I wrote it to the SD Card.
ie: as expected, gparted reported a single *.iso file while disks reported an *.iso file and the remaining unformatted/empty space.

Then I tried a Bookworm based #!++ i386 *.iso file to see how it would work. -> cbpp-12.0-i386-20230611.iso
Find it here you may want to try it out and see what happens.

TL;DR
Using the #!++ *.iso, Mintstick generates a first partition with an *.iso image, a second UEFI partiton and the remaining empty space.
As a result, the script will delete the partition containing the UEFI shit.

I expect that the same thing will happen with any modern *.iso file beyond Chimaera or equivalent.

In this last test, it deleted the partition with the UEFI shit, left the unformatted empty space untouched and threw the same error we both experienced.
You may want to consider the script looking only for empty and unformatted space.

It's fine with me, all my hardware is non-UEFI (BIOS boot) so I just created a a FAT32 DATA partition by hand.
But how about the cases you will be working on?

That said, the error does not seem to be reproducible.
And since both of us have seen it ie: different hardware, a pause may be effectively needed somewhere in the script.

Best,

A.

Last edited by Altoid (2025-05-27 23:13:22)

The officially official Devuan Forum!

#1 2025-05-23 22:18:32

Does anyone here use Mintstick for making livUSB's? Need testers.

#2 2025-05-23 23:09:00

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#3 2025-05-25 22:36:19

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#4 2025-05-25 23:40:53

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#5 2025-05-26 01:22:28

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#6 2025-05-26 12:34:14

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#7 2025-05-26 13:21:05

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#8 2025-05-26 13:21:13

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#9 2025-05-26 14:25:24

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#10 2025-05-26 14:36:45

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#11 2025-05-26 15:21:48

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#12 2025-05-26 21:29:11

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#13 2025-05-26 23:10:33

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#14 2025-05-27 00:13:26

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#15 2025-05-27 12:22:19

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#16 2025-05-27 13:01:05

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#17 2025-05-27 14:55:19

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#18 2025-05-27 15:54:12

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#19 2025-05-27 18:55:51

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#20 2025-05-27 20:12:35

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#21 2025-05-27 20:23:10

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#22 2025-05-27 20:45:39

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#23 2025-05-27 21:13:11

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#24 2025-05-27 21:31:26

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

#25 2025-05-27 22:46:57

Re: Does anyone here use Mintstick for making livUSB's? Need testers.

Board footer