Resetting an msftdata flag with gparted

[fox]

I noticed the other day that one of my two Ubuntu partitions has a flag set as "msftdata", whereas the other is "boot, esp". There is a problem with the former if I try to access that partition from the Mac partition on my internal drive. I am trying out a piece of Paragon software which lets one access ext2, 3 or 4 partitions (as well as read or write to them) from the Mac. The software allows me to access the files on the Ubuntu partition with the boot,esp flags, but not the one with the msftdata flag. I would like to change that flag to boot,esp with gparted, but I don't know if this would damage the partition so that I could no longer access it. Advice please?

[Jason]

I don't think it would damage the partition. I don't believe flags affect data on a partition, just how the partition is treated. For example, if you want to boot off a partition, it has to have the 'boot' flag. Removing it would just mean that it wouldn't be a partition that you could boot from. In other words, your boot manager wouldn't recognize it as an OS that it could boot from without it.

If it's irreplaceable data, definitely back it up although you should be doing that already. More info here about parted flags and it looks like msft is used to define an MS partition or for compatibility purposes with older versions of parted if it's a Linux partition.

https://www.gnu.org/software/parted/manual/html_node/set.html


Update:

Shortly after I wrote this I realized that it's not necessary for the boot flag to be enabled on a partition to boot it if a boot manager is installed in the MBR. I used the cross-out styling as to admit that I erred and not just re-write history.

[fox]

Thanks for the reassurance. I thought that was the case. When I changed it in gparted from msftdata to boot,esp (from another Linux partition), it just changed it without requiring me to apply the operation, so I guess it was pretty trivial. At any rate, the partition booted and I'm writing from it now.

[Jason]

Glad it worked without a hitch. Under "msftdata" on that page, it says that changing it requires setting a competing flag like 'boot' or 'msftres' so I guess every partition has to have one of those flags enabled. or perhaps another competing flag as 'esp' says it's synonymous with 'boot' (if you're using a GPT partition system). So I'm surprised a partition can have both ('boot' and 'esp') but maybe it's so that the partition or drive can be booted no matter what drive partition scheme is being used?

[fox]

Actually, my Ubuntu 20.04 partition on the internal SSD has no flags set, but it boots. But that partition was created a long time ago (actually, copied from that of another drive), so I don't know how I did that. Also, there is no boot flag on my Mac partition. I'm looking at these partitions with gparted.

As far as removing and replacing flags goes, I think that replacement is the only option in gparted. But I suspect that you can remove a flag without replacing it if you use the command line. In this case, I'm happy to replace the msftdata flag with a boot flag.

[Jason]

Actually, my Ubuntu 20.04 partition on the internal SSD has no flags set, but it boots. But that partition was created a long time ago (actually, copied from that of another drive), so I don't know how I did that. Also, there is no boot flag on my Mac partition. I'm looking at these partitions with gparted.

Do either of those partitions boot up first when you turn on the computer? Grub will need to know where to get its configuration from (the startup executable for it is in the MBR) Otherwise, I believe it's the boot manager that handles those partitions (i.e. you need a boot-related flag on one of the partitions). Check for that. Being marked with the 'boot' flag means the computer will boot that partition (or drive) first.

[Jason]

This is an interesting tidbit from Wikipedia under the topic 'Boot flag':

Other boot loaders used by third-party boot managers (such as GRUB or XOSL) can be installed to a master boot record and can boot primary or extended partitions, which do not have the boot flag set.

It sounds like you only need the boot flag set if you don't have a bootloader installed OR GRUB is set on another partition instead of in the MBR. Without a bootloader or a partition, the BIOS won't know what partition to start up, at least if there's more than one. It might not be needed if there is only one.

[fox]

My situation is complicated by my being on a Mac and using rEFInd as my boot manager.

[Jason]

My situation is complicated by my being on a Mac and using rEFInd as my boot manager.

That may be but it doesn't really matter what boot manager you use. By the time the computer loads the boot manager, it doesn't care which one is bootable. It'll load whatever you like whether it's bootable or not. The BIOS needs to know what partition to start from (if there's more than one). So you either need the boot flag set in the partition with a way to boot like a boot manager or have the boot manager stored in the MBR and the manager takes over. At least that's with a DOS formatted disk (as opposed to GPT). If there's more than one bootable partition, it still needs to know where to start which is why GRUB is usually installed in the MBR. In other words, BIOS -> MBR -> BOOT MANAGER.

I don't know how it works with EUFI or if it has the equivalent of an MRB. Since a system with it always has an EFI partition (I think?), it might be that the EUFI chip finds the EFI partition either automatically or it's hard-coded and the boot manager takes it from there. If somebody knows, feel free to post. I tend to only learn what I need to manage my own computers and so far, I haven't had to deal with one with EUFI stuff on it.