Well, for people who don’t understand why it’s needed, the Installer suggestion will still be confusing (should I accept or not, is it risky), for the others they will systematically accept and still rant it’s not done automatic.
The point is it should be automatic. The content of the partition will be changed anyway, so what’s the purpose to NOT change the type of partition accordingly automatically ?
Currently Installer does not format the partition by itself. You have to go in DriveSetup and do it manually.
If Installer had a mode where you select a partition and it wipes it and formats it, or a mode where it does that for an entire disk, then yes, it makes sense to set it up all corectly.
For a manual setup, maybe it should block you from installing and tell you to go in DriveSetup and fix it yourself, or offer to change the settings automatically and wipe the partition.
This way, you can’t run Installer anymore with incorrect settings. But if you want (for whatever reason), you can still do it with DriveSetup where you can control every little detail of your partitioning if you think you know better.
And what about making Haiku UEFI bootloader don’t care about partition type but relying only on actual detection of a BFS volume on that partition?
Agree. But it still would be helpful if DriveSetup would give the user a hint when they are going to do some weird things with the partitions, e.g. “You’ve formatted the partition to Be File System, would you like to update its type too?” → “No / Yes (recommended)”
DriveSetup is not ment for that IMO. A “easier” utility that is prescriptive should do this.
i.e something that implicitly assumes a partition table, and sets the partition type based on what you partition it to.
For me, relying on partition type value is like relying on file extension to assert the actual content type: fragile and too old school.
Any reason haiku bootloader can’t just rely on the actual BeFS detection from the partition content ?
Seems more frickle to me, what’s the benefit to ignoring this?
Do you have something like Mac’s Disk Utility in mind? I’m up for having it, but let me share my concerns regarding the development approach we tend to take.
I’ve noticed that quite often people prefer to have a perfect solution instead of making a small change that would immediately make user’s experience better. And that would have been okay if there were enough Haiku developers to build all the planned things in a timely manner. But with the limited resources we currently have when smaller pragmatic solution is rejected in favour of a bigger and better one, that bigger is usually too big to attract developers so it stays unimplemented for years.
Do you remember the multilib discussion in another thread? We could have been able to launch 32-bit apps on 64-bit Haiku for 7 years already, but someone thought the proposed solution was not perfect, so in the end we have neither the imperfect nor the perfect one. Now don’t get be wrong, I like the idea of having an automatic mode in the Installer, or having a new more user-friendly app for disk partitioning, but who’s going to do it? And can they commit to deliver it for Beta 6, or will we still see a thread like this next year with frustrated users asking why things just don’t work as expected?
OTOH any of the simpler fixes proposed in this thread can be quickly done even by someone like me who usually avoids C++ like the plague. It won’t be perfect but it will solve the issue users currently have, and then when someone decides to dedicate more time we can replace it with a better solution.
I think that DriveSetup should work like diskmgmt.msc from Windows where partition creation and formatting is single atomic operation, not two. It is much less confusing.
I fully agree.
The simple solution is to fix Installer. There is no need to touch DriveSetup.
Lots of people have lots of ideas and opinions. Who will be the first to write a patch and actually fix any of this?
The proposed solution isn’t complete anyway, IIRC it doesn’t have fully working signal handling.
I think that should not have prevented merging it. It can be changed and improved after merging.