Regression on gptfdisk 1.0.9 (on -current)
 

Some time a month or so ago in my testing of gnome liveslak images I lost the ability to write disks with Eric's iso2usb.sh script. It no longer worked at all and would completely destroy any partition table on said disk when ran. Chalked it up to PEBCAK and started testing in virt-manager instead.

Did a fresh install and it kept happening there as well. Then recently I tried a MX Linux live usb thingy and the program I used to write to usb worked within my VM, which finally gave me the idea, it's not me... it's Slackware!

As of 2 weeks ago Arch pushed a patch (there's actually 3 they added) to gptfdisk from this merge request, and I told myself to try it out on Slackware but hadn't gotten to it. Today was that day, and what do ya know? IT WORKS!

This is likely important to patch, as gdisk seems to destroy any partition table that even looks it's way, and I'm honestly amazed no one has complained about this yet, surely someone has wiped a drive by now?!?

Anyway, now I can safely resume writing persistent isos to usb now for testing and I am happy again I no longer need to use VMs to do this.

Out of curiosity I followed your links. FWIW, the arch patch is not for gpt but popt, that parses command-line options (from man popt). The pull-request to gpt seems to address possible (maybe unexpected) output from popt. Which of these patches did you test?

I only tested them together with the gptfdisk 1.0.9 sources and built a new package. Previously, if using gdisk, it would write a partition entry and save etc and the disk would appear fine. But using the liveslak iso2usb.sh script on the same drive (which also uses gdisk) it would wipe the partition data and crash immediately with an error about it requesting to write beyond the available space.

Since applying the 3 patches, the program works as expected now and no longer corrupts gpt headers/disks during writing. Whatever the patches are patching (I'm not on that machine currently), it seems to be working as intended now.

I wonder why those disk tools use external library for parsing command line options... Anyway good information, thanks