unmounted partitions: GPT on legacy BIOS #235

parted has support in the GPT partitions it creates for classic BIOS booting, it handles this by using partition flags to mark a "legacy boot" partition. to start digging into it, collect the partition flags from lsblk.

I'm tempted to mark this as something to straight out hide from display, but I can also see tagging these as "legacy_bios" in the unmounted display.

note that nothing gets pushed to the stable current master inxi, everything goes to pinxi, I just committed this to pinxi however. I generally don't accept git pulls/pushes etc however because I'm often working on pinxi locally and it's a pain trying to deal with changes coming from elsewhere, but it's easy enough to just copy over the patch if it's basic.

I don't actually use git or its features, to be clear, the real master is my local pinxi, which I then push whenever it seems to be working ok to the github pinxi, so I can grab it more easily from other systems, and other people can check it for fixes etc, and inxi itself is never updated until next inxi happens, which is when current local pinxi gets copied over to inxi, and a few small things changed, then inxi next is pushed to github, but inxi itself is never anything other than the last 'stable' version of pinxi that was copied to inxi master branch [not merged, copied, as in a file replacing another file]. The only time I run inxi is right before I commit next inxi to github, to make sure it's not crashing, but otherwise I don't use inxi at all, since it's always behind inxi except for the day of release, when they are pretty much the same.

Note that partition/unmounted/disk/raid are a real pain to work with because they are all interconnected, so I tread very carefully in this area.

ah! i was wondering on the interconnectedness here. I'm going to play about in my local copy, but I figured at least adding more stuff to collect would be a good starting point. I'll see what I get.

When I did the rewrite of old inxi to perl, the last components I did were those 4, because they are by far the most complicated and interwoven of anything in inxi/pinxi. But you are right that adding more stuff to collect is in general a good idea, you can see in the debugger data collector stuff that I've added for that reason, but never actually used in inxi, sometimes because it's just not clera what the data really is in the real world, the variety, etc, sometimes because the tools are not consistent or available on most systems, it varies.