Partition Manager feedback
- IanJeffray
- Posts: 163
- Joined: Mon Jan 18, 2021 1:51 pm
Re: Partition Manager feedback
I can format a 2GB dom, and I get a 1.5GB partition and a 417MB "Unusable" bit.
I can then format the "unusable" bit, but IDEFS doesn't offer it as a mountable drive.
I can then format the "unusable" bit, but IDEFS doesn't offer it as a mountable drive.
- IanJeffray
- Posts: 163
- Joined: Mon Jan 18, 2021 1:51 pm
Re: Partition Manager feedback
That's complete crap, sorry. Bad memory. I hooked up a serial cable today and accessed the BIOS ("ABLE") and found that the ROM and boot scripts etc are actually stored in flash, so there should be no special nonsense going on with the disc.IanJeffray wrote: ↑Thu Apr 20, 2023 11:52 pm Well. It's really a 40GB disc. And there's a boot partition that only the BIOS can see - that's where the RISC OS softload ROM sits, etc.
I'm guessing there's some shenanigans in IDEFS to hide that bit of the disc from RISC OS and maybe that's how it's getting confused.
- IanJeffray
- Posts: 163
- Joined: Mon Jan 18, 2021 1:51 pm
Re: Partition Manager feedback
The thick plottens.
Somehow there's a working 6.4GB Linux installation on this same disc!
Code: Select all
/ # df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 6.4G 272.4M 5.8G 4% /
tmp 61.2M 0 61.2M 0% /tmp
dev 61.2M 0 61.2M 0% /dev
var 61.2M 0 61.2M 0% /var
/ # ls -l /dev/root
lrwxrwxrwx 1 root root 4 Apr 22 16:07 /dev/root -> sda7
/ # fdisk -l
Disk /dev/sda: 40.0 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 974 7823623+ 0 Empty
/dev/sda2 975 1218 1959930 82 Linux swap
/dev/sda3 1219 2556 10747485 83 Linux
/dev/sda4 2557 4864 18539010 5 Extended
/dev/sda5 2557 3773 9775521 83 Linux
/dev/sda6 3774 4017 1959898+ 82 Linux swap
/dev/sda7 4018 4864 6803496 83 Linux
- IanJeffray
- Posts: 163
- Joined: Mon Jan 18, 2021 1:51 pm
Re: Partition Manager feedback
I reckon this A9 IDEFS is simply mis-reporting the drive size because I've just put a new 32GB SSD in and it reckons it's 29.31GB with 30.5GB filecore partition on it. Simtec partitioning. Except it was formatted on an ArcIn32 !
Re: Partition Manager feedback
I was hoping to get away without the Resources files. Try the version I've just uploaded.
Yes, I figured that from looking at IDEFS last night. Its a right hatchet job, they've essentially taken a 26bit Module and wrapped everything in MSR/MRS to keep using R14 for the flags. The SWI's that PM uses are byte-for-byte identical to the older Module I based support on.IanJeffray wrote: ↑Sat Apr 22, 2023 4:07 pm found that the ROM and boot scripts etc are actually stored in flash
That can't be the case, the drive size comes from the drive itself via an IDENTIFY command and the "partition" sizes come from the FileCore drive size. It's more likely IDETool is rounding the "partition" sizes incorrectly.IanJeffray wrote: ↑Sat Apr 22, 2023 5:57 pm I reckon this A9 IDEFS is simply mis-reporting the drive size
I'm still trying to figure out how that's happening. When you create a partition covering the full 2GB, what does it say for "max" MB?IanJeffray wrote: ↑Sat Apr 22, 2023 4:00 pm I can format a 2GB dom, and I get a 1.5GB partition and a 417MB "Unusable" bit.
Are you sure you're not seeing another drive? When a drive is initialised it wipes the first 32 sectors, which will clear any MBR or GPT partition tables.IanJeffray wrote: ↑Sat Apr 22, 2023 5:11 pm Somehow there's a working 6.4GB Linux installation on this same disc!
I'm afraid my knowledge of Linux involves Googling every command
- IanJeffray
- Posts: 163
- Joined: Mon Jan 18, 2021 1:51 pm
Re: Partition Manager feedback
But this has nothing to do with IDETool -- the new SSD was formatted with APDL tools. IDETool hasn't touched this new drive. Why it shows as "Simtec" partitioning scheme I'm not sure. There's not really a partition table there. But PM shows the wrong disc size nonetheless.JonAbbott wrote: ↑Sat Apr 22, 2023 9:29 pmThat can't be the case, the drive size comes from the drive itself via an IDENTIFY command and the "partition" sizes come from the FileCore drive size. It's more likely IDETool is rounding the "partition" sizes incorrectly.IanJeffray wrote: ↑Sat Apr 22, 2023 5:57 pm I reckon this A9 IDEFS is simply mis-reporting the drive size
I can assure you there's only one drive in this box. The 'fdisk -l' command shows what Linux sees as the partition table and the other commands show that the Linux root filesystem is on the 'sda7' partition at the end of the disk. This might be why the filecore FS and Linux FS can be 'overlaid' just now - until lots is written to the filecore FS and would presumably crap on the Linux root FS at the end of the disk. A bizarre situation really.JonAbbott wrote: ↑Sat Apr 22, 2023 9:29 pmAre you sure you're not seeing another drive? When a drive is initialised it wipes the first 32 sectors, which will clear any MBR or GPT partition tables.IanJeffray wrote: ↑Sat Apr 22, 2023 5:11 pm Somehow there's a working 6.4GB Linux installation on this same disc!
I'm afraid my knowledge of Linux involves Googling every command
- IanJeffray
- Posts: 163
- Joined: Mon Jan 18, 2021 1:51 pm
Re: Partition Manager feedback
Same error. I don't see any extra resources being loaded in there though anyway... ?
Re: Partition Manager feedback
Sorry about that, I've uploaded a revised version. I'd managed to include the wrong resources files!IanJeffray wrote: ↑Sat Apr 22, 2023 10:15 pm Same error. I don't see any extra resources being loaded in there though anyway... ?
- IanJeffray
- Posts: 163
- Joined: Mon Jan 18, 2021 1:51 pm
Re: Partition Manager feedback
That now runs fine on the A9 without Aemulor.JonAbbott wrote: ↑Sun Apr 23, 2023 7:19 pmSorry about that, I've uploaded a revised version. I'd managed to include the wrong resources files!IanJeffray wrote: ↑Sat Apr 22, 2023 10:15 pm Same error. I don't see any extra resources being loaded in there though anyway... ?
Re: Partition Manager feedback
v0.99 (10-07-23) attached.
This build adds initialising a Pi Boot drive, which is the last feature I'm going to add prior to v1.00. The FAT and FileCore partitions areas can be resized if required, or just accept the defaults to use the full drive for FileCore and have a 50MB FAT Boot partition. During the FileCore format process, the FAT partition is linked to !Boot.Loader. Once formatted it will attempt to download and extract the OS ROM and HD4 options selected and will also pull down some additional packages to make it a usable machine, such as !PackMan, NetSurf and its dependencies. It will also pre-configure the Boot to set the time via NTP and IP to use DHCP although currently there's no option to set the hostname - it defaults to "RISCOSpi"
There's currently no method under RISC OS to check if the OS volume name has been seen by FileCore, so ensure the FileCore volume name is unique before initialising to avoid problems. There is however one show-stopper. AcornHTTP has dependencies on !Boot, which prevent hot-swapping the OS drive to format a new drive. The only workaround I've found to date is to format the new drive via a USB adapter.
I've also spotted an issue when FAT32FS is loaded. If FAT32FS has seen the new drive before it's formatted and the drive already contains a FAT partition, FAT32FS will corrupt the FAT when the machine is shutdown. The workaround is to avoid touching the new drive within RISC OS before initialising it as a Pi Boot drive.
MassFS support has been added for both FileCore and FAT drives on the A9home, although this is currently untested.
SCSIFS hosted drives should now support 48-bit LBA, provided the underlying SCSIFS supports 16 byte SCSI Op's.
I've also added some workarounds to handle drives formatted with FAT32Format, where the FAT partition can exceed the physical drive size and the Volume ID is missing from the root directory.
Changes
This build adds initialising a Pi Boot drive, which is the last feature I'm going to add prior to v1.00. The FAT and FileCore partitions areas can be resized if required, or just accept the defaults to use the full drive for FileCore and have a 50MB FAT Boot partition. During the FileCore format process, the FAT partition is linked to !Boot.Loader. Once formatted it will attempt to download and extract the OS ROM and HD4 options selected and will also pull down some additional packages to make it a usable machine, such as !PackMan, NetSurf and its dependencies. It will also pre-configure the Boot to set the time via NTP and IP to use DHCP although currently there's no option to set the hostname - it defaults to "RISCOSpi"
There's currently no method under RISC OS to check if the OS volume name has been seen by FileCore, so ensure the FileCore volume name is unique before initialising to avoid problems. There is however one show-stopper. AcornHTTP has dependencies on !Boot, which prevent hot-swapping the OS drive to format a new drive. The only workaround I've found to date is to format the new drive via a USB adapter.
I've also spotted an issue when FAT32FS is loaded. If FAT32FS has seen the new drive before it's formatted and the drive already contains a FAT partition, FAT32FS will corrupt the FAT when the machine is shutdown. The workaround is to avoid touching the new drive within RISC OS before initialising it as a Pi Boot drive.
MassFS support has been added for both FileCore and FAT drives on the A9home, although this is currently untested.
SCSIFS hosted drives should now support 48-bit LBA, provided the underlying SCSIFS supports 16 byte SCSI Op's.
I've also added some workarounds to handle drives formatted with FAT32Format, where the FAT partition can exceed the physical drive size and the Volume ID is missing from the root directory.
Changes
- Added max size checks when formatting a FAT partition
- Switched FAT boot code to use local RESTORE/DATA for the code block
- Added MassFS support (untested)
- Now uses the FAT volume label from the BPB if the ATTR_VOLUME_ID entry is missing from the root directory (FAT formatted with fat32format)
- Fixed an issue in the GPT partition trawler where it was reporting error for every invalid partition, instead of reporting there are invalid partitions
- FileCore wasn't setting root_size correctly for E format
- Fixed a potential buffer overrun when creating the FileCore Map in memory
- Added Initialise Pi Boot drive
- Added streamed ZIP extractor
- Added HTTP file downloader
- Added creation of a DOSDisc file linked to the first partition in the FileCore formatter
- SCSIFS now uses (16) command variants if required for 48-bit LBA
- Added a check for MBR partitions exceeding the drive size (drives formatted with fat32format)
- Corrected an issue where a partition that exceeds the drive size would cause an Unallocated block to be shown at the end of the drive
- When updating an existing GPT or MBR partition table, the existing Boot sector is now used as the basis, to ensure any existing Boot code is retained
- When initialising a drive, the existing partition scheme is now ignored when writing the new scheme
- When dismounting partitions, non-FileCore partitions are now ignored to reduce the chance of "Insert disc xyz" prompts
- "Mount with FAT32FS" will now warn if FAT32FS does not support the underlying filesystem
- Switched Pi CONFIG/TXT "ramfsfile" line to use "initramfs" instead
- Added !!CMOSInit to the Hook folders which saves the CMOS on first boot
- Fixed an issue in SCSIFS where it was performing SCSI Ops on the wrong drive
- Added detection of Watford Electronics and Risc Developments IDEFS
- Fixed an issue that caused SCSI writes to fail
- MonitorType is now configured before saving the Pi CMOS
- Pi packages are now skipped if HardDisc4 contents is set to "None"
- Changed !Boot.Choices.Internet.Startup to detect EtherUSB or EtherGENET
- Added Advanced Pi options for Resolution, Hostname, Domain, Audio via jack, Upscaler selection, Overscan, ARM Boost on Pi4 (aka 1.8GHz), 4Kp60 on Pi4
- Moved Pi Window templates to a separate Template file
- SCSI op wasn't setting "read safe" correctly
- Now checks if the Pi support library is present before attempting to load it
- Added a meaningful error when an Internet connection fails
- No longer prompts about open files on individual partitions when dismounting all logical drives, if you've already accepted there are open files on the filesystem
- Fixed a Zone overrun when allocating FileCore Map entries to the PiBoot FAT area
- Corrected an issue when writing FileCore defects, where it might try to write a FreeLink pointing into the Spare bits
- Initialise Pi Boot drive was not showing the drive in the Window title
- Added an additional check before calling DiscOp, to ensure the SWI is known
- Corrected an issue with the FileCore Disc End Bit marker on CHS addressed drives, which could be in the wrong place if the drive size didn't align with a cylinder boundary
- If SCSI READ CAPACITY (16) returns an invalid result, it now falls back to the SCSI_Initialise 2 values
- ATAFS support added (Yellowstone IDE Podule)
- Added an additional check in FileCore for a valid full DiscRec zone
- Asm routines now clear V on exit
- Switched ICS and HCCS partition write table code and add drive code from EVAL's to direct IDEFS read/write function calls
- Corrected an issue where a rogue unallocated region might be shown at the end of a GPT partitioned drive, if the drive was fully allocated
- Partitioning schemes and drives that use CHS addressing are now restricted to CHS addressable limits
- Fixed a potential Abort that occurs if the expected Filer task isn't found when restarting the filesystems
- FileCore validation now only checks for a valid new defect list if the Big Flag is set in the DiscRec
- Combined the partition write and backup code for Simtec/HCCS and Yellowstone into an external library to remove code duplication
- Drives performing CHS to LBA mapping are now restricted to the CHS limits on Podules that use cylinder based partitioning (Simtec/ICS/HCCS/Yellowstone)
- Fixed an issue on Simtec where formatting any partition, other than the last, could cause partitions after it to disappear depending on the IDEFS version
- Fixed an issue with HCCS where it would only check the Primary Master when validating the physical drive count
- CDFS now reports the drive being checked, prior to checking the device
- CDFS now includes the SCSI ID in the physical device name
- CDFS audio track info added
- Partition 1 is now checked to be data, before attempting to call CDFS_DescribeDisc as I've seen stack corruption when it returns an error
- ATAFS drive refresh will now prompt and correct *Configure ATADiscs
- ATAFS wasn't restarting the filesystem correctly after changing ATADiscs
- CDFS fixed an array bounding error when there were more than the max supported partitions
- Pi.Internet was checking the wrong Module versions
- Was incorrectly marking a full-disc FileCore as partition type "Unallocated", causing the menu to show "New volume" instead of "Format volume"
- HDFFS now performs a CheckMap after remounting a drive as a workaround to a crash in FileCore
- Corrected typos reported by Jan De Boer
- Added SparkFS to the Pi Boot disc
- wrapped DISMOUNT and URL_GetURL in UpCall claims to avoid prompts for missing discs
- Added a timeout to streamed ZIP extraction
- ZIDEFS now reports if IDEFSDrives is misconfigured when rescanning the drives
- ZIDEFS wasn't performing discop's correctly
- The main window block was being overwritten on WIMP versions <3.50, causing strange redraw behaviour when the window was resized
- Modified Module version code to handle Oak SCSI Podules
- Added a fall-back to restart SCSIFS if it doesn't support Service Call &20103
- When adding drives, it wasn't checking if the maximum number of drives that the program supports has been reached
- SCSIFS was releasing a device, even if it hadn't claimed it
- Was addressing the wrong drive when checking if a drive supports SCSI 16 commands
- If a Full-disc FileCore was found, it was resetting the partition count to 1, instead of increasing it by 1, causing any RISX iX partitions to not be shown
- Castle SCSI cards are now detected
- GPT wasn't reading the full GUID volume name
- Corrected GPT primary/backup write order to match EFI spec
- GPT was not preserving the Attribute bits on GUID partition entries
- Reverted Simtec partitioning to use the OS drive size to work out where the next partition starts
- Writing the partition table to Simtec and HCCS would fail
- Simtec/HCCS partitioning was not being detected after a drive was initialised