Jump to content











Photo
- - - - -

Grub4dos some flash work Fat16 some Fat32??

grub4dos usb creation

  • Please log in to reply
11 replies to this topic

#1 msetzerii

msetzerii
  • Members
  • 5 posts
  •  
    Guam

Posted 07 October 2021 - 09:10 AM

Trying to create a process to support booting my G4L project and thought I had a simple single solution that would work for linux and windows users.

Created a 64M iso image that contained a partition that had the grub4dos setup as a regular usb boot loader, and also as an UEFI boot loader.

Using 4 scandisk USB drives 3 8G and 1 30G the process worked great, but required the partition to be formatted as FAT16 or it would get a message that the GRLDR was not found, but file was there. Since using FAT16 worked fine on all these flashes, thought I had a solid solution.

BUT  hand another flash that I just tried it on. PNY 120G flash, and it fails to boot if the partition is formatted with FAT16, but manually did the same process with it formatted to FAT32, and it then works just fine..

So, not clear on what could possible be the issue???

 

Problem is that the bootlace programs no longer work under 64 bit windows, so copying the files from a zip file is no problem, but making the usb bootable is the issue. With linux bootlace works to install it. But windows seems to have no way to do it that I've found.

 

So, created an iso that has the grldr installed and it can be copied to flash using dd in linux, or using rufus in windows.

To the scandisk flashes this worked with the FAT16.  but PNY flash fails, and requires FAT32. Don't know what causes the issue, or how one would know what flash would require FAT16 and which would need FAT32??

 

All files copied to the partitions regardless of FAT16 or FAT32 are exactly the same? So, it must be something in the GRLDR.

 

So questions.

1. Is there any program that can do what bootlace is with 64bit windows?

2. If not, any ideals on how one would know which would require FAT16 and which FAT32? Wouldn't be hard to create two iso files with the FAT16 and FAT32, but don't want people to have to download both, and have to figure out which one works?

3. Was looking at create two ISO files that just had the FAT16 and FAT32 setup with the bootloader installed. The iso files are 67108864 in size being 64M, but with compression the files are 16320 or 16272. So, could be downloaded like that, then uncompressed, and burned to flash. The zip file with all the kernels and ramdisk and support files is about 50M, and could just be unzipped to the resulting flashes?

 

Rather complex process, so thought I'd see if someone might have a solution, or at least some direction on how to come up with a single solution?

 

Know that I don't know enough at this point.

Thanks for your time.

 



#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 07 October 2021 - 10:12 AM

I already replied to you on github - can you follow those suggested steps?

Which version of grub4dos are you using?



#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 October 2021 - 10:56 AM

I would first try to understand what the base issue is, there is no (known) reasons why a FAT16 should work and a FAT32 would not (or viceversa), it might be some peculiarities of either the flash stick (i doubt it) or some peculiarities of this (or that) motherboard BIOS (more probable).

 

There are no particular issues to use grub4dos directly to "install itself", however, in a case such as yours where a "very static" image is used, maybe the "universal" solution could be the UMBR, a "special" MBR code that directly chainloads grldr from a (fixed) blocklist, which is obviouosly "filesystem agnostic".

 

But I am not sure to understand the whole scenario.

Why a .iso?

Do you want it to be burned to CD/DVD besides dd-ed to flash USB?

 

can you describe waht your final goal(s) is/are (as opposed on how you thought of reaching it/them)?

 

:duff:

Wonko



#4 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 07 October 2021 - 11:20 AM

As in the ReadMe files inside the grub4dos download docs folder, bootlace is for DOS and Linux (not Windows).

For Windows we have grubinst.exe which can be found in the grubutils pages.

https://github.com/c...aster/grubutils

I use this with the LockDismount.exe tool which first dismounts the USb drive from Windows so that the grubinst tool can lock access to the USB drive and write to the MBR, etc.

The RMPrepUSB download includes grubinst.exe and the 'Install grub4dos' button will install the boot code for you.

 

P.S. Another issue with your Dell BIOS is that it may have the 'single partition' bug. Some BIOSes, if they see a single partition on a (small) USB drive will treat it as a floppy drive. grub4dos 0.4.6a does not support booting from a USB floppy. That is why I strongly suggest that you always test with a virtual machine first - to eliminate any peculiar  BIOS features/bugs. Some BIOSes will look at the total capacity of the USB drive and if it is below a certain size it will boot it as a floppy device - but if above that size, it will boot it as a hard disk!

 

So I strongly suggest you test using a VM (VBox/VMWare/QEMU) because this means we are using a 'known good' BIOS.



#5 msetzerii

msetzerii
  • Members
  • 5 posts
  •  
    Guam

Posted 07 October 2021 - 12:02 PM

To try to respond to the posts.

Trying to make a simple way to setup my project for users. Many of whom are not experts.

In past, used syslinux in which the iso image could be burned to a CD or copied to a flash since it was a hybrid iso.

Also, had a process where the kernel and ramdisk could be booted from a flash using grub4dos.

 

Recently had a user that got 140 new systems Dell 3080s that no longer offer non-UEFI booting, so neither the syslinux cd or regular usb would work. Was able to create a flash image that had both grub4dos to boot the regular usb, and had an EFI setup to boot using grub2 the same kernel files and ramdisk.lzma file. Thus having a single usb that could boot either as a normal flash with grub4dos or UEFI flash to boot grub2.

 

Found that it was reporting that GRLDR was not found on the flash, or any other device if machine if it was formatted as FAT32??

File was obviously there on the partition, but booting failed. Tried formatting as FAT16 instead of FAT32, and it worked? Don't know why.

 

Later redid the flash to using grub4dos efi to do the booting as well as with the regular. So, having one menu.lst basic setup. Also, the font file used by grub4dos was different that the grub2, so reduced size. Figured that it would work as FAT16 on all machines.

 

Did just look at the grubinst that was mentioned but it shows that it is 7 years old, and the setup uses the bootlace install the the --gpt option, since the UEFI boot requires the partition to be gpt??  So don't see that working. Also looked at the rpmprep, and it doesn't show anything abou the gpt partition installation of grldr?

 

Using an iso image that already has the grldr installed via the bootlace using windows works. With linux, once can copy the iso file to the flash device, and it installs the boot loader and the partition with all the files. One advantage over the syslinux hybrid, the extra space of flash can be used, instead of it being setup as a read-only device.

 

Again, thought everything would work with the FAT16 setup, but ran into the issue with the PNY flash, where it doesn't work with FAT16, but does with FAT32.

 

Ideal was that I would create a iso image that anyone could download, and then just burn to a flash to use in one simple step. Similar to the syslinux version with a cd or flash.

 

So, don't know what the FAT16/FAT32 issue , or if it is an issue with the bios or flash or what.

 

Script that I use to create the image and burn (write) to flashes. -F16 is Fat16 and changing that to -F32 does Fat32, so nothing else is changed in the creation. This creates the ISO file and copies the files, and uses the bootlace.com to install the boot loader. It then shows the usb devices that are available, and gives the option to actually copy the iso to the flash. I've also taken the iso and writing it using rufus, and it then boots as well.

 

#!/usr/bin/bash
ver="-0.60"
#create a 64M blank file to create Image
dd if=/dev/zero of=g4lefi$ver.iso bs=1M count=64
#create gpt disk format
parted -s g4lefi$ver.iso mklabel gpt
#create single partition, set esp on and boot flag
parted -s g4lefi$ver.iso mkpart G4L 1MiB 100%
parted -s g4lefi$ver.iso set 1 esp on
parted -s g4lefi$ver.iso set 1 boot on
#Use fdisk to display the status
fdisk -l g4lefi$ver.iso
#Create a loop setup to access the partition within file
#losetup --offset $((512*2048)) --sizelimit $((512*131038)) --show --find g4lefi$ver.iso
sectors=$(sfdisk -l g4lefi$ver.iso | tail -n 1 |tr -s ' ' | cut -f4 -d' ');
losetup --offset $((512*2048)) --sizelimit $((512*sectors)) --show --find g4lefi$ver.iso
#Format the Partition a Fat16 (For some reason using Fat32 fails to fine boot loader??
mkfs.fat -F16 /dev/loop0 -n G4L
#Now that partition exist, mount and copy files
mount /dev/loop0 /mnt
cd /mnt || exit
unzip /home/msetzerii/g4l0.60alpha/g4l-lite-fc33.zip
cd /root || exit
umount /mnt
losetup -d /dev/loop0
#Installation of the grub4dos boot loader onto gpt disk image file
#bootlace programs don't seem to work from windows 64bit at all??
./bootlace.com --gpt g4lefi$ver.iso
#Two be able to transfer image to flash, have system find what it shows as.
#Filters out my CD/DVD, primary disk, and ramdisk.
#Only get lines with sd and then only need 1st line. Located in bytes 26-28
#Flash most times shows as sdb, but sometimes shows as sdc??
disks="none none on"
fsarchiver probe 2>&1 | sed '/^$/Q' >/tmp/fsarchiver
for a in $(ls -l /dev/disk/by-path/*usb* 2>/dev/null | grep -v part |sed 's_^.*/s_s_g' | sort) ; do
    b=$(grep "$a" </tmp/fsarchiver | cut -b21-51);b=$(echo ${b} |tr ' ' '_')
    disks="$disks $a $b OFF ";
done
Xdialog --radiolist "Select USB to be overwritten\nAll data will be lost on it." 15 60 4 $disks 2>/tmp/flash
flash=$(cat /tmp/flash)
rm /tmp/flash
##flash=$(grep -v "sr0\|sda\|zram" </proc/partitions | grep sd |head -n 1 |cut -b 26-28)
#If a value is returned proceed with copy of the g4lefi$ver.iso to flash.
if [[ "$flash" > "sd " ]] ; then
    clear
    echo copying g4lefi$ver.iso to /dev/"$flash"
    dd if=g4lefi$ver.iso bs=64MiB of=/dev/"$flash" & PID=$!
    echo "THIS MAY TAKE A WHILE, PLEASE BE PATIENT WHILE WGET IS RUNNING..."
    while ps hp $PID >/dev/null ; do
        printf  "▓"
        sleep .25
    done
    echo copy finished
#copy of 64M image to a flash that is larger results in an error in setup.
#The flash will work with error, but using parted -l, it will offer to fix issue.
#This will then allow the other space to be used. Don't know if windows has a similar process.
    echo fix GPT layout by running parted -l
#    echo "Enter Fix (after warning message displays)"
    echo -e "Fix" | parted -l ---pretend-input-tty
#    parted -l
else
    echo "No selection"
fi
#At this point, the flash should have dual boot capabilities.
#Can be booted as a regular USB using the grub4os boot loader
#Can be booted as UEFI USB using the EFI boot loader.
#Have asked question on why it works using Fat16 but not Fat32 on grub4dos
#Sees the gpt or regular grub4dos bootloader placed by bootlace
#But fails with message that it can't find grldr program on actual partition??

Don't want end users to have to deal with something like this. Ideally was hoping to just have them download the iso, and use rufus to write it to the flash. Now it looks like I'll need two iso's one with Fat16 and one with Fat32, and they will have to just try one and see if it works, and if not try the other one. So, downloading about 128MB of files?

 

Been doing the G4L project since 2004, so trying to keep things simple.. (sort of).

Since I don't know what is causing the issue with FAT16/FAT32, and have not way to control machine bios' out there. Might not be a nice clean solution..

Getting the UEFI booting process requires adding 100 lines to the kernel config file to support the framebuffers and fbcon setup.

Again, thanks for the feedback.



#6 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 07 October 2021 - 12:25 PM

Recently had a user that got 140 new systems Dell 3080s that no longer offer non-UEFI booting, so neither the syslinux cd or regular usb would work. Was able to create a flash image that had both grub4dos to boot the regular usb, and had an EFI setup to boot using grub2 the same kernel files and ramdisk.lzma file. Thus having a single usb that could boot either as a normal flash with grub4dos or UEFI flash to boot grub2.

 

 

USB_FORMAT supports to make UEFI-MBR USB drive bootable with UEFI Secure Grub2 which chainloads UEFI Grub4dos (Grub4efi) and Windows Boot Manager.

In MBR BIOS Mode it supports booting with Windows Boot Manager and Grub4dos and chainloads Grub2.

 

Various Boot Images can be used such as Windows VHD as FILEDISK or as RAMDISK

and PE WIM or  Linux ISO files booting from RAMDISK and Linux in VHD booting as FILEDISK.

 

Download:  from wimb GitHub  -   USB_FORMAT-60 and UEFI_MULTI-60  and  VHD_WIMBOOT_Trusted-60

 

Download File E = Encrypted Password = bootwimb

 

Manual:  VHD_WIMBOOT.pdf   - See Best Answer



#7 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 07 October 2021 - 12:45 PM

No - grub4dos and grub4efi will boot from a normal MBR Legacy partitioned drive.

GPT is not required for UEFI booting - this is a common misconception!

 

Just make a FAT16 USB drive - normal legacy partition

Install grub4dos boot loader (I suggest to both MBR and PBR)

Add grub4efi files (just copy on)

 

UEFI booting just needs to see a FAT partition (Legacy or GPT disk) and it will look for the default boot file

 

If a UEFI32 BIOS then the firmware will look for a \EFI\BOOT\BOOTIA32.EFI file

If a UEFI64 BIOS (99% of systems these days) then it will look for \EFI\BOOT\BOOTX64.EFI file

 

That is all that is required to UEFI-boot (a FAT partition and a .EFI boot file with the correct name).



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 October 2021 - 01:28 PM

I can confirm word by word (for what it matters) what Steve6375 just posted, to (hopefully) clarify:

1) BIOS only executes (maybe) the code that is on first absolute sector or LBA0 (and as such the MBR must contain code)

2) UEFI only executes (maybe) the code that is in either (depending on architecture) \EFI\BOOT\BOOTIA32.EFI (very rare) or \EFI\BOOT\BOOTX64.EFI residing on a FAT (16 or 32) volume that is (on MBR) active[1] or (on GPT) has the ESP GUID of 

C12A7328-F81F-11D2-BA4B-00A0C93EC93B

If you prefer, UEFI can boot BOTH from MBR and GPT style disks indifferently, while BIOS can only boot from MBR style disks or MBR-hybrid GPT ones.

 

For smallish images/targets (such as a flash USB) there is no real need of adding the complexity of GPT partitioning, but if you want to follow this route, there are no issues in making a MBR-hybrid GPT one, and to do this you need a suitable MBR code.

 

If you don't want the final users fiddle with the image, using the UMBR is a "perfect" solution, and BTW with it (or with my alternative - BTW syslinux/makebootfat derived "special" MBR and "underfloppy") you may also have the grldr before and outside any partition/volume. 

 

The only drawback of the UMBR or similar is that it is not easy to replace or update the grldr, but since in this case it is a "static" image that you build, that is a non-issue.

 

Check this:

http://reboot.pro/in...showtopic=22317

particularly the little scheme attached here:

http://reboot.pro/in...=22317&p=215423

 

:duff:

Wonko

 

 

 

[1] I believe this may depend on some UEFI implementations, some do not even require that the volume is the active one if I recall correctly

 

P.S: seeing from your bash that you are using mkfs.fat "plainly", it is likely that the issue is there, mkfs.fat has a ton of possible parameters, you are using none and the default ones may be not "good enough", I am thinking of the (common on smallish devices) issues with CHS vs. LBA and more loosely geometry of the volume in the BPB.



#9 msetzerii

msetzerii
  • Members
  • 5 posts
  •  
    Guam

Posted 08 October 2021 - 04:27 AM

Think I found what was causing problem, but not 100% clear on why??

Had found on web instruction to setup a flash with 2 partition, but I only needed the 1, so copied just that part.

It used this info in process

losetup --offset $((512*2048)) --sizelimit $((512*131038)) --show --find FILENAME

 

Think they used the wrong value. Showed using sfdisk to get number, but think it should have been the Sectors value instead of the End value.

Changing it to the Sectors value process seems to work fine with the FAT32 format.
 

Device      Start    End Sectors Size Type
g4lefi.iso1  2048 131038  128991  63M EFI System

So, not sure why using 128991 instead of 131038 had it fail with FAT32, but work with FAT16 on sandisk flashes?

So, now the created flash has FAT32 with gpt. Tried using msdos with process but bootlace.com doesn't like updating a iso file?

The bootlace.com with --gpt works fine?

 

So, the original code I had copied probable had a bug, but since it then setup a second partition after the first, it might have corrected it??

 

So now, I can create a single ISO file that can be copied to a flash, and at least with the ones I have it works for all.

 

Did do test with rufus to just create a flash with grub4dos, and it worked, but used whole flash. Then just putting the files on partition allowed it to work.

 

Also, tested using rufus to write the ISO file to a flash versus using the dd on linux to write same file.

Did a comparison of the disk images between 2 8G flashes and expected them to be identical, but found there are 449 bytes that have different values??

 

24 bytes between 529 thru 604?

30 bytes between 1041 thru 1184?

 

Next difference isn't until 1048644??

ISO file has 67108864 bytes, so note sure why the 449 bytes are different between dd copy and rufus writing it?

Compared all files on partition and they 100% match at the file level.

 

Would be nice to fully understand the differences, but guess have a working solution.

 

The lines in script to create the iso file are here up to the bootlace part.

 

#!/usr/bin/bash
ver="-0.60"
#create a 64M blank file to create Image
dd if=/dev/zero of=g4lefi$ver.iso bs=1M count=64
#create gpt disk format
parted -s g4lefi$ver.iso mklabel gpt
#create single partition, set esp on and boot flag
#parted -s g4lefi$ver.iso mkpart G4L 1MiB 100%
parted -s g4lefi$ver.iso mkpart G4L fat32 1MiB 100%
parted -s g4lefi$ver.iso set 1 esp on
parted -s g4lefi$ver.iso set 1 boot on
#Use fdisk to display the status
sfdisk -l g4lefi$ver.iso
sleep 5
#Create a loop setup to access the partition within file
#losetup --offset $((512*2048)) --sizelimit $((512*131038)) --show --find g4lefi$ver.iso
#seems wrong value was used sectors value is 128991 - 131038 was last sector??
sectors=$(sfdisk -l g4lefi$ver.iso | tail -n 1 |tr -s ' ' | cut -f4 -d' ');
echo $sectors
losetup --offset $((512*2048)) --sizelimit $((512*sectors)) --show --find g4lefi$ver.iso
mkfs.fat -F32 /dev/loop0 -n G4L
#Now that partition exist, mount and copy files
mount /dev/loop0 /mnt
cd /mnt || exit
unzip /home/msetzerii/g4l0.60alpha/g4l-lite-fc33.zip
cd /root || exit
umount /mnt
losetup -d /dev/loop0
#Installation of the grub4dos boot loader onto gpt disk image file
#bootlace programs don't seem to work from windows 64bit at all??
./bootlace.com g4lefi$ver.iso --gpt

 



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 October 2021 - 09:38 AM

About the math:
if a partition starts on LBA 2048 and ends on LBA 131038, it has 131038-2048+1=128991 sectors in it.
Normal partition viewers expose:
Start of partition LBA address
Number of sectors in partition (size in sectors)

The tool you are using seemingly exposes also the End LBA address of the partition, you probably confused the size with the address, it can happen.

Again, if you don't need to "burn" the image to optical disk, i.e. the destination is only flash sticks, there is no need to make a .iso out of it, but if you want to make one, you need to make a iso-hybrid image:

https://wiki.syslinu...title=Isohybrid

:duff:
Wonko

#11 msetzerii

msetzerii
  • Members
  • 5 posts
  •  
    Guam

Posted 08 October 2021 - 10:19 AM

Thanks for the reply. I have had a cd iso version of the project that uses syslinux and is a hybrid so that it could be burned to a CD or copied to a flash going back to 2004 (don't recall when they hybrid was added).

I also has an archive file (zip, 7z, and exe) that contained the kernel, ramdisk.lzma, and grub4dos support files. It could be copied to a flash, the bootlace.com could be used to just install the grldr from linux, but wasn't able to get it to work with windows, but the grub4dos toolbox program, which did work with 32 bit versions of windows, but now non of those work from 64 bit windows.

I did test using rufus to create a grub4dos flash, and then just unarchive the files to the flash and that seems to work just fine.

Only issue is that it creates a partition of FAT32 format using the entire 8G of flash for the partition. In past I would create an about 100M partition of the Fat32 and use the rest of flash as ext3 or ext4 or ntfs. Once the flash is setup, it doesn't have to be redone, an one can just put the newer files onto it. So, that requires a multi-step process of creating a grub4dos flash, and then unarchiving files.

With linux it is easy to create a FAT32 flash, extract files, and use bootlace to install the grldr.

With windows the default flash creation uses NFTS, which is an issue, but the rufus doesn't seem to make that a big deal.

The extracting of files is a bit of issue. On the only windows machine I have handy, it kept giving me permission issues to write to the flash, so had to open cmd as admin, and the used the self extracting 7z exe version of archive, and it worked well afterwards.

Have about 250 to 600 downloads a week, and unfortunately, don't have any ideal on windows/linux users or what level they are at.

So, having a single file and one step to get it onto the flash. Perhaps using something other than iso??

Tried the syslinux 6.04 regular stuff, and could never get it or the EFI 6.04 to work either. Had no issues with the versions from 2004 to the 6.03 upgrading. When I had user that had new machines that no longer allowed for non-UEFI boot, I looked for a solution to do UEFI boot. First working solution was to use the Fedora UEFI boot setup, and swap my kernel and ramdisk.lzma. Got it to work, but had no video?? could telnet into machine and run it via telnet. Turned out the UEFI requires framebuffers and fbcon setup that required adding about 100 lines to the kernel .config file. Only increased kernel size by about 400K, so total kernel is about 10M. Then that worked. Then worked to get both regular booting via grub4dos, and UEFI booting using grub2 that Fedora used. Then worked to get grub4dos to handle both.

That all seems to work.

Just the problem with setup to get FAT32 to work. Seems the info I had gotten from web was a little of.

sfdisk -l g4lefi.iso
Disk g4lefi.iso: 64 MiB, 67108864 bytes, 131072 sectors
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: gpt
Disk identifier: 32790C6B-DA8E-48C7-BADC-BF6DBD32472A

Device      Start    End Sectors Size Type
g4lefi.iso1  2048 131038  128991  63M EFI System

 

The info should using teh 131038 number that fdisk or sfdisk report, but seems the 128991 is the number that needed to be used.

Now have script get the right number, and could change size if space needed. Right now only using about 85% of space with 2 10M kernel files, and the 30M ramdisk.lzma file.

 

Thanks again. For you time. Is a Free Project, and I use to use it a lot at my College before I retired after 36+ years.

Have fun with it. Have a great day and be safe.
 



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 October 2021 - 02:16 PM

Rufus is an exceptionally good tool, but it is not aimed to create "custom" usb sticks, but there are programs similar or equivalent to dd that are more suitable.

 

On so - called "modern" windows (Vista and later) there is an increasing number of "protections" to avoid direct writing to disk, so you definitely need Admin credentials and - it depends on the tool and on the area you are going to write to - you may also need to take the disk offline.

 

Rmprepusb or clonedisk might be the tools that you *need* on the windows side if you cannot for some reasons use dd for windows (a 64 bit version exists alright though it needs to be tested):

http://www.chrysocome.net/dd

but they are anyway more complex (and feature rich) than what you need.

 

A lot of projects around use (IMHO senselessly) balena etcher:

https://www.balena.io/etcher/

which at 126 MB is a huge mass of bloat.

 

If I were you I would have a look at USBimager:

https://gitlab.com/bztsrc/usbimager

 

it is small enough and it works on *any* OS, and the "simplified, wo" interface might be just what your users want/need.

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users