installer iso does not check whether C: is bootable
rofl0r opened this issue · comments
just installed svardos iso svardos-20240118-cd.iso to an actual SD card with FAT32 on it (i used qemu and -drive file=/dev/sda,format=raw,id=hda ), and svardos install ran through without issues, it told me to remove install medium and reboot, but the bootable flag on the SD wasn't set so the boot failed. i guess the installer should check this and offer some sort of option to make the "disk" bootable.
Hi rofl0r, you are right that the SvarDOS installer makes a partition "bootable" only when it creates it (but really it's FDISK that does the job under the hood when creating the partition).
In the situation when the drive already has an existing non-active partition and SvarDOS is installed on it, there is nothing that will make it bootable.
It would probably be safe for the installer to execute "FDISK /activate" once the installation process is over, just in case.
Only issue is that the syntax is FDISK <driveid> /ACTIVATE:<partid> and while the installer knows the drive's id, it does not know which slot of the partition table is being occupied by whatever appears as "C:"... Not sure how to do that and I'd rather avoid parsing the MBR myself. @boeckmann any chance FDISK could help here? I've looked at the list of options but did not find anything like "activate the first FAT primary partition found on drive 1", can you think of a different approach that could solve this in an elegant way?
I will think about how this can be solved. Perhaps a call like FDISK /ACTIVATE without a partition id could activate the first FAT partition found. But not sure how to handle the case where the installation partition is not the first primary. Perhaps one could scan the DOS structures to find a mapping between a drive letter and the disk partition.
There would also be the option to do it manually by outputting a message like: "No active partition defined. Press RETURN to start FDISK to select an active partition..."
Easiest to the SvarDOS installer would probably be FDISK /ACTIVATE:<driveletter>, where <driveletter> is the installation drive, and FDISK does the rest. This would be the hardest to implement. But I like this most. So if you agree, I will try to implement this in the next time.
Perhaps a call like FDISK /ACTIVATE without a partition id
That was the first thing I tried, wishfully thinking "maybe it will sort it out on its own". :)
Perhaps one could scan the DOS structures to find a mapping between a drive letter and the disk partition.
FDISK has this information already (FDISK /INFO) - but I did not find a way to ask it. Best would be to make it activate a letter, not a partition drive...
There would also be the option to do it manually by outputting a message like: "No active partition defined. Press RETURN to start FDISK to select an active partition..."
But then it could also be that the active partition is not the one where SvarDOS is being installed to... so we circle back to "figure out the mapping between DOS letters and the partition table".
Easiest to the SvarDOS installer would probably be FDISK /ACTIVATE:
<driveletter>, where<driveletter>is the installation drive, and FDISK does the rest.
I didn't want to suggest it plainly not to sound demanding, but I do believe it would be the most elegant solution. :-)
If you'd be willing to add such feature to FDISK that would be really awesome. Then I will use it in the installer right away.
Fine, then we agree on the most elegant solution :-)
The only thing I have to make sure is that FDISK and the kernel agree on the drive letters assigned. The current algorithm of FDISK drive letter assignment is modeled after the kernel algorithm. But that may disagree if for example the kernel does not support FAT-32, while FDISK does. I have to think about some safety net.
The current algorithm of FDISK drive letter assignment is modeled after the kernel algorithm. But that may disagree if for example the kernel does not support FAT-32, while FDISK does. I have to think about some safety net.
Maybe rely on INT 21h/AH=32h to fetch the DPB? It contains the address of the first data sector.
Maybe rely on INT 21h/AH=32h to fetch the DPB? It contains the address of the first data sector.
This is what I also intend. If it this lies within the boundaries of the partition I know I have the right one.
For reference, the following tools list this stuff: https://github.com/boeckmann/dpbinfo
For reference, the following tools list this stuff: https://github.com/boeckmann/dpbinfo
lDebug's dpb.eld likewise. But the DPB doesn't list the hidden sectors nor the int 13h unit number. The data start sector number is within the partition, not the unit. Further, int 21h service 32h doesn't return FAT32 EDPBs in FreeDOS.
You can call the ioctl to get the hidden sectors but this doesn't seem to return the unit number either. Example: https://hg.pushbx.org/ecm/instsect/rev/c42352ff3c97
You can walk the UPB chain instead to find the unit that corresponds to a DPB. This will contain both the int 13h unit number and the hidden sectors. It is queried using int 2Fh service 08h: https://fd.lod.bz/rbil/interrup/dos_kernel/2f0803.html#4327
However, the UPB format differs depending on whether FAT32 is supported I believe.
before this turns into a huge task, maybe it would suffice to just check whether the bootable flag is set on any partition, and if not just print something at the end of the install "no bootable partition detected, please run fdisk before rebooting" and give the user an option to do that.
@ecm-pushbx Yes you are right, I probably have to use INT2F,0803 to get a pointer to the first DDT (FreeDOS) / UDSC (EDR), and walk the chain to find the INT 13 device number for the given logical device.
Regarding the hidden sectors returned by 440D,0860, the EDR kernel returns the absolute sectors from the beginning of the disk even for logical partitions, while MS-DOS / FreeDOS return the relative hidden sectors from the start of the extended partition. But we are dealing with primary partitions, so this should be no matter of concern in this case. Nevertheless this is a major discrepancy in the BPB structure.
FreeDOS has ddt->offset to calculate the absolute sector of a read / write operation [1], while EDR always(!) uses BPB_HIDDEN for this [2], to my understanding.
[1] https://github.com/FDOS/kernel/blob/8552d833bbca657591fa8e6f7276d307d7d0c7c6/kernel/dsk.c#L837
[2] https://github.com/SvarDOS/edrdos/blob/419c30bfd67d6e49cb1fc9ed2bc99444f8c0653d/drbio/disk.asm#L1157
One thing to consider: If we activate a partition automatically this might have some undesired side-effects, with the most ugly being the change of drive letter assignment. For example, if you have a disk with two primary partitions C: and D: and no active partition, then C: will become D: and D: will become C: if one activates the second partition. Bad thing if the user and the installer think they are installing on drive D:. This gets more complex if there is more than one disk.
Procedure could be like this: Let the user choose a volume for installation and check if this is active. If not, ask the user if this volume should be made active and warn him about the possible change of drive letters. If he continues make the changes and reboot immediately, so that potential changes in DLA are performed prior to starting the installation process.
I'm not sure this is a problem - but it does suggest that it's better (safer) to activate the partition before actual installation. So partition activation should be inserted within the installer at such moment:
1. create partition (if none exists)
2. activate partition (if currently not active) <------------- here
3. overwrite the MBR with unbootable code
4. REBOOT if anything done in steps 1 or 2
5. format partition (if not formatted)
6. unpack files
7. SYS C:
8. reboot
It also means that FDISK should be able to report (eg. through its exit code) whether it performed any partition activation or not, so the installer would know that a reboot is needed to make sure drive reordering is final.
Procedure could be like this: Let the user choose a volume for installation and check if this is active. If not, ask the user if this volume should be made active and warn him about the possible change of drive letters. If he continues make the changes and reboot immediately, so that potential changes in DLA are performed prior to starting the installation process.
Yes, that would be it - with the little exception that the installer does not ask the user for the destination drive currently, it always targets C: (or D: if installer is being run from C:, because that likely means C: is a USB bootdisk)
before this turns into a huge task, maybe it would suffice to just check whether the bootable flag is set on any partition, and if not just print something at the end of the install "no bootable partition detected, please run fdisk before rebooting" and give the user an option to do that.
I see I did not address this suggestion, so just to comment - indeed such approach could be a good compromise, although it would obviously fail if the drive has more than one partition and the active one is not the partition where SvarDOS is being installed. Also, this subject will become slightly different once SvarDOS uses the EDR kernel by default, because drive letter assignment is different between EDR and FreeDOS. So all in all I think it is best to keep this issue pending for the time being, and revisit it once the move EDR is finalized.
Just thought of it now - maybe SYS could be a better tool for the job? It does a LOT of boot-related magic already, supports different DLA schemes, resolves drive letters into partition ids, etc... it "just" lacks the ability to set the "active" flag next to the partition in the MBR.
current bleeding edge version comes with an installer that takes care of modifying the MBR of the drive where SvarDOS is installed so the correct partition is made active.