Partition Manager
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... 29
Jon Abbott (1421) 2640 posts |
I need to see the complete debug/txt file before I can investigate why they are not being detected as a FileCore drive. I’ve been doing all by FileCore testing on 3 RiscPC, so guess it’s down to differences in the version of HForm used and what it’s doing in the MBR partition table area. PM has to work around years worth of hacks and changes that aren’t necessarily compatible with GPT/MBR partitioning handlers. From some of the debug/txt files, it’s evident that some fixing of the MBR table is going to be required before some of these drives will work when the OS supports partitions. I don’t envy the person that implements that. Hopefully we can pick them up as part of this and get the MBR’s to a standard it can support. A gentle reminder to folk helping in this mammoth task. Please only post the debug/txt if something is wrong. When posting, I need to see the complete file and please describe the issue as best you can. As this site isn’t really suited to sharing this kind of debugging information, you can sign up to the JASPP forum and reply to the thread there with attachments. Failing that we can start a thread for this on StarDot as I will be engaging with that community in the next phase, once initialising full disk FileCore drives is coded so we can replace HForm. |
Doug Webb (190) 1156 posts |
Hi Jon, 0.38 works again on the Iyonix, 5.29, but only for ADFS::4. The free space is reported as 1010MB by PartMgr but Diskinght and Freemap report it as 1011Mb so perhaps a rounding issue? Any way all this plus debug and screen shots put on JASPP feedback thread. |
Bryan (8467) 468 posts |
Sorry. I thought I had posted sufficient. If you think it will help I can repeat one of the tests tomorrow. (The debug file has been over-written and the drives returned to the cupboard) |
Timothy Baldwin (184) 242 posts |
will we be able to specify which drive the system will boot from Wrong. Filing system is read from “CMOS”, ADFS reads default drive from “CMOS”, don’t know about other device drivers. TerritoryManager will load some modules if the configured territory is not already loaded.
Correct.
This is only the case since DOSFS 0.88, 14th April 2012 earlier versions do not load anything at this stage. 2. MBR has a bootable flag on the partitions, but GPT does not. GPT has a bootable flag that is like the MBR, see UEFI 2.8 chapter 3 which defines the MBR boot flag as:
And it defines the GPT boot flag as “Legacy BIOS Bootable” and states:
The boot flag is only only well defined for use by a program in the MBR to load execute a program in first sector of the marked partition. There are no grounds to say it is available for RISC OS to identify a Filecore partition containing !Boot rather than the bootloader to identify a FAT partition containing the RISC OS ROM image.
GUID + partition entry attributes are used by ChromeOS and the Systemd Discoverable Partitions Specification which is a good approach, but should be overridable by a configuration file (ie virtual “CMOS”) or command line option when RISC OS is loaded from a filing system. |
Bryan (8467) 468 posts |
This was my question and with hindsight I asked the wrong question. On my A410 and RPC systems, I always knew which drive would be the boot drive as it was clearly specified in CMOS and the hardware fixed the drive numbers. On a Raspberry Pi with two SCSI drives, again I can specify that the system will boot from SCSIFS Drive 4. But the trouble is that I have no way of specifying which USB adapter will be Drive 4. |
Raik (463) 2052 posts |
Very nice job. Thanks for that.
I’m not Anton ;-) but I use the “same” 2TB HDD created with Antons tools. PartMgr 038… The complete size of the 2TB device is not displayed correct… Second try: Remove the GPT SSD and plug to SCSI and plug my 1TB Backup device to SATA (FileCore+FAT partition create with Antons PartiFC). The second FAT partition is ignored but works with FAT32FS without problems. Next try: Remove the GTP device and plugin an 2GB EADSFS (PowerTec IDE partman) device from A4. The hdd is splited to 4×512MB. The first partiton is usable on Ti but ignored by PartMgr. |
Jon Abbott (1421) 2640 posts |
No problem, you weren’t to know which bits I needed to look at. I would appreciate just one full debug/txt for the moment, that should give me the information I need.
Thanks for the correction, I’ve revised my comment. I keep forgetting about ADFS as none of my modern RO machines support it and I haven’t used it in years!
UEFI has a boot flag in the Boot Manager flag, GPT does not as far as I can tell. MBR is a requirement of GPT, but only for the Protective Partition so it’s boot flag should not be used. As no RISCOS machines are UEFI (correct me if I’m wrong on this) and we have to cover a range of legacy kit, we can probably “ignore” UEFI spec.
Yes, it seems to be the most sensible approach. Whoever implements the Partition bounty also needs to consider softloaded OS, where a Boot FileCore partition will be needed to load the OS, before any Partition Manager can decide how to boot correctly. |
Anton Reiser (471) 63 posts |
Not exactly. There is a little bug in PROCdebug_block_dword: the last 3 characters in the ASCII text are missing. Partition type 7 on my Win/Linux disc is now correctly recognized as NTFS or exFAT. On a other disc, the partition type 0×0c (FAT32 LBA) is shown as
|
Jon Abbott (1421) 2640 posts |
Thanks for the report, I’ll grab the debug files later and investigate.
If you’re referring to the red partition, it’s not been ignored. It correctly read the volume name, but has marked it red as DOSFS would not be able to read it fully. FAT32FS reads in a different way to work around the OS drive size limitation. As I mentioned early on, some consideration needs to be made around FAT32FS becoming part of the OS as DOSFS can’t handle DOS partitions that FileCore can’t fully access. The alternative is DOSFS is modified to handle DOS partitions outside of a FileCore partition.
Are you referring to SCSI::4 in the image, which is showing as fully unallocated? PowerTec IDE support is out of scope of this currently (would be phase 2), I’d need detailed specs on how it’s partitioning before I could support it. I would however like to see the debug/txt output for the drive so I can at least get the initial partition displaying. I suspect what’s happened is it’s tried GPT, then MBR, found a valid MBR signature but no partition information and subsequently not tried FileCore.
Thanks, I’ll modify the code. That explains Raik’s 2TB showing as 1TB.
It was a quick hack I put together at the last minute, I’ll correct.
Did it recognise it as FAT? Is it just the volume name that’s unknown? |
Anton Reiser (471) 63 posts |
No. ‘FAT32’ is not shown. |
Andrew McCarthy (3688) 602 posts |
Confirmed, FAT32 is not shown. The box here is red with < unknown > and the disk size displayed. Its also not present in the debug text. Should the volume list only show information for those devices that are mounted? In contrast to those devices displayed above it? Currently I see all devices in the top panel, but not in the volume list; therefore I’ve assumed the volume list is only presenting the mounted devices. |
Raik (463) 2052 posts |
I think we “speak” about differnt devices. fat32fs:free … gives… Fat32Backup |
Bryan (8467) 468 posts |
OK. No problem. I do not have anywhere else to put it and I am reluctant to create yet more logins, so I have posted the Pi4 5.28 debug file in Tests on this forum. SCSI::4 is an mSATA mounted via an adapter from RISCOSbits (HForm on a Pi) |
Jon Abbott (1421) 2640 posts |
v0.39 available The next one for you is a 516 MB Rust from a RiscPC600 If it’s SCSI::4 in your debug/txt file – its being detected as FileCore so I’m not sure how it’s subsequently shown as unallocated.
The free space reported by OS_FSControl 55/49 in debug/txt is &3F284000 = 1059602432 / 1024 / 1024 = exactly 1010 MB
FileCore limits? I’ve added addition debugging output which will confirm when FileCore can’t read the start and end LBA of a FAT partition.
The volume list shows volumes that are fully accessible by FileCore
FileCore limits perhaps, try latest version to confirm.
I’ve copied the debug log, you can delete – thanks. |
Andrew McCarthy (3688) 602 posts |
v0.39. Started without the SSD FAT partition open. Opened FAT partition, quit Partition Manager and retarted. There was delay, so here’s the debug.txt: Log deleted. |
Anton Reiser (471) 63 posts |
Same here.
|
Doug Webb (190) 1156 posts |
Hi Jon, Tried 0.39 on my Iyonix and the free space is now correctly reported as 1011MB on ADFS::4 but still no ADFS::5. It is also OK on the ARMBook where it sees SDFS::0 correctly. Finally it is OK on the ARMX6 apart from not seeing SDFS::1 still. Coming along nicely so thanks for all your efforts. |
Jon Abbott (1421) 2640 posts |
Thankyou for all the reports so far, the feedback has been invaluable. I believe I’ve resolved most of the issues and having gone back through a lot of the reports, I have the queries below. If I’ve missed anything, please let me know. @Doug Webb, looking back through all your debug/txt on the Iyonix, I suspect my code is querying the wrong IDE device, as when you switched the drive it gave the same response. Odd thing is, the code works on my RiscPC’s. Could you confirm ADFS::5 is the Slave on the Primary IDE? @Anton Reiser/Raik, is your 4K drive size now showing correctly? @David Pitt, is your Titanium now displaying SCSI::1 correctly? @Alan Adams, is your SCSI::6 still showing “< unknown >” as the FAT volume name? Other reports: @Bryan and others reporting full disk FileCore drives that either aren’t showing or are showing as a single FAT partition. This issue might be a quirk of the version of HForm used to format the drive. From the few reports I’ve seen so far, they either have MBR partitions that only have a FAT partition, or the MBR partition is blank. It’s a major issue to resolve as we run the risk of breaking GPT/MBR partitioning in an effort to detect full disk FileCore drives. The sensible route is to fix the MBR, but that’s also the most impractical. The alternative is to detect full disk FileCore first, but that will then ignore the MBR partition on Pi’s etc. Another option is to check for a full disk FileCore, when an MBR is detected that doesn’t fill the disk, but that will detect ghost FileCore partitions that have legitimately been deleted. The final option, given we’re moving to partitioning, is to make assumptions based on the presence of a Partitioning Module or OS variable that indicates partitioning is being used. ie Everything prior to partitioning support will expect to see a full disk FileCore on every drive – which mirrors how the OS works. For the edge cases and to cover migration from pre to post partitioning, where there’s simply no way to determine if it’s a valid MBR or a full disk FileCore, it defaults to MBR and I provide an option to manually recheck the drive for full FileCore, overriding the detection? I’d appreciate some suggestions, as whichever route I take is not going to be perfect. I’d particularly like to hear from the Partition bounty author and coder(s) to see how they propose covering this particular issue. There’s possibly a simple solution that I’ve missed. |
Raik (463) 2052 posts |
Yes… Look at Free and division by 1024. Thanks a lot. |
Doug Webb (190) 1156 posts |
Hi Jon,
ADFS::4 and CDFS::0 are on the primary interface. ADFS::5 band CDFS::1 are on the secondary interface. Cable Select is used not primary/secondary. CDFS::0 is the prime DVD Writer and if I remember rightly this layout was suggested as best for burning CD’s/DVD’s from data on the primary hard disc. I could be wrong on this as it was so long ago that the Iyonix was purchased/set up and it isn’t my primary machine now. |
Bryan (8467) 468 posts |
Hi Jon, I think the only issue I am seeing now is on MBR SD or memory sticks larger than 4GB with a single FAT32 partition less than 4GB. (This enables the Pi 4 to hardware boot either from SD or USB whilst allowing RISC OS to read the device) Everything on Partition Manager works except that the FAT 32 partition name is shown as < unknown> in both the graphic and text. RISC OS SDFSfiler correctly shows the name Pi4boot. Correction: It is only such SD cards which have < unown> names when plugged into either the SDcard slot or via an adapter into USB. Memory sticks show the name correctly. Debug File is shown in updated Tests topic on this forum. Once again I will delete when you have copied it Update 2: It ocurred to me that the difference might be because one of then is plugged into the Pi USB-C socket, so I sawpped them over. It is still the SD card partition whch shows < unknown>. |
David Pitt (3386) 1248 posts |
It is showing as a single unallocated space. Debug etc is here |
Jon Abbott (1421) 2640 posts |
That confirms by suspicion that my code is checking the wrong drive. It’s checking the Slave device on the Primary controller, instead of the Master device on the Secondary controller. I’ll fix the code.
Is the partition red? Unless it’s a 4K drive, FileCore won’t be able to address the whole partition, so my code might not be able to read RootDir – this should be visible in the logs and the partition should be red. @Alan Adam’s SCSI::6 has a similar issue except the partition is definitely accessible by FileCore. My code is a bit of a hack though, as it doesn’t follow RootDir cluster chains and assumes the ATTR_VOLUME_ID entry is in the first cluster. I’ll revisit this at some point. @David Pitt, is your Titanium now displaying SCSI::1 correctly? Cross checking the 0.39 debug/txt with a previous version, the DiscOp that reads the GPT has returned a different sector. I think I understand what is happening. I believe that where its trying to read the partition table on the physical disc, its actually getting sectors from within the partitions. I need to figure out how to: 1. Only discover physical drives and ignore virtual drives from PartMan I’ll wade through the PartMan code and see how its reading physical sectors. |
Alan Adams (2486) 1140 posts |
It still shows as Also, SDFS::1 still doesn’t show. SDFS::0 is correctly shown. Debug output is here: http://www.adamshome.org.uk/RiscOS/partmgr-039-debug.txt |
Jon Abbott (1421) 2640 posts |
Could you upload the debug/txt somewhere please. If its a Titanium – it will be the issue I mention above. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... 29