Partition Manager
Pages: 1 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Doug Webb (190) 1181 posts |
Hi Jon, Using 1.01 build on my iMX6 I see two instances of the main drive: One is SCSI 0:0.0 (SCSI::4) 223.56 GB capacity and the other, SCSI 0:0.8 (SCSI::4). Version 1.00 23/7/23 shows things correctly. |
Andrew McCarthy (3688) 607 posts |
Some good news, using the v1.01 29/07, I no longer experience the drive re-ordering I’d seen before. I’ve emailed the debug file, forgetting that despite a desktop dismount of the newly created image on Shutdown, I get a message to reinsert the drive. |
Paul Sprangers (346) 525 posts |
1. PM now creates a Pi Boot disc on a SD card in a USB stick, although I had to skip quite a few ‘Failed to connect’ or similar errors. Eventually, there’s a !Boot directory with Choices, Recourses, RO520Hook, RO530Hook and Loader. The latter just contains CMDLINE/TXT and CONFIG/TXT. No Elf files and such. There’s an Apps directory and a Utitlities directory too. I’ll send you the debug file. By the way, I noticed that when starting PM with CTRL held down, it does NOT recognise the stick. |
Jon Abbott (1421) 2652 posts |
Should be fixed in today’s build
If you’re referring to the order of Filer icons on the taskbar – that’s down to the individual filers. IF PM has to reinitialise a filesystem, the order might change depending on how the filesystem filer works.
Did you build a Pi Boot drive with the same discname as an existing drive (itself included)? I’m wondering if RISCOS has cached a previous version of the drive. I’m assuming it was the Filecore partition on the new SD that RISCOS was asking to be reinserted?
That sounds like it couldn’t connect to any of the download servers to pull down the required files.
I want to say that’s just coincidence as CTRL only alters scanning of ATAFS, IDEFS and ZIDEFS. If you select “Refresh drives” once PM’s loaded its equivalent to holding CTRL – does the drive then disappear? |
Paul Sprangers (346) 525 posts |
Fair enough, and I can copy the necessary files from backups. But new users will probably be left with a not working system, won’t they?
I can’t repeat this. PM now seems to work as intended. Don’t know what I did wrong the first time. Question: when I just do an Initialise, with either of the options, it inevitably leads to a ‘Disc not understood. Is it formatted’ error. Is this supposed to be normal? Question 2: When I created an Pi Boot disc on a SD card, it will always show 2 icons, one of which yields a ‘The disc drive is empty’ error, while the other will only show the contents of Loader, unless it is opened with Adjust. Is this supposed to be normal too? |
Stuart Painting (5389) 716 posts |
Are you using an SD card reader with 2 or more slots? These typically appear as separate drives under RISC OS.
That is Fat32FS doing its thing, so is to be expected. |
Paul Sprangers (346) 525 posts |
That’s it. Problem solved.
Okay, but what should I do to get RISC OS with SELECT, as with all other discs? |
Stuart Painting (5389) 716 posts |
The card will behave normally when inserted into the SD slot of the Pi. It’s only when it’s connected via an external card reader that Fat32FS gets in the way. |
Paul Sprangers (346) 525 posts |
Well, that’s it indeed. I’m nearly feeling a genuine Pi user. |
Jon Abbott (1421) 2652 posts |
Creating a “Pi Boot drive” requires an Internet connection to download all the required files to the new drive. I can add a check for an Internet connection before the process starts, to warn the user its going to fail.
Initialising a drive erases the start of the drive and in the case of MBR/GPT creates an empty partition structure. Attempting to open the drive in RISC OS without first creating a volume on the drive, will result in a “Disc not understood” error. |
Doug Webb (190) 1181 posts |
Hi Jon, Thanks for the fix which I can confirm works here. If I get time this week I will try the latest version on my RiscPC with a STD Unipod in it. |
Jon Abbott (1421) 2652 posts |
STD Unipod is on the missing Modules list – so may or may not work. I think it uses Simtec IDEFS from the A9home, so depending on how bespoke its implementation is – it might get picked up as Simtec and work…the debug log details which IDEFS its been detected if you want to check. I believe it uses MassFS for the USB, also similar to the A9home. I’ve implemented that based on conversations with the original author although its not been properly tested. It does some non-standard things to support both FAT and FileCore such as switching drives between MassFS: and MassFC: depending on the format, so without proper documentation, identifying the logical drive has its challenges. |
andym (447) 473 posts |
I have an issue with the newer versions (1.01). Version 1.00 worked with my system with two ADFS drives, scanned both drives, and displayed them appropriately. All version 1.01s manage to scan the first drive, but on scanning the second ADFS drive, freezes the machine totally. Needs a reset to get going again – even a Ctrl-Break doesn’t work. Will the log files be stored anywhere? |
Jon Abbott (1421) 2652 posts |
Only SCSIFS support has changed between 1.00 and 1.01 – do you have a SCSI card fitted?
Refer to the app Help. |
andym (447) 473 posts |
Ah. It was a multi-card USB card reader that map creating the issue. As soon as I unplugged that, it all worked again. It gets so little use, I’m not overly concerned about it. |
Jon Abbott (1421) 2652 posts |
Could you email a debug log to me please as it should not hang. Its possible SCSIFS is in a long timeout whilst PM is checking the LUN’s. |
Jon Abbott (1421) 2652 posts |
Based on debug feedback and testing I’ve done myself with several USB multi-card readers, the current 1.01 build of PM should hopefully support them. I’ve also removed most of the blocking dialogues when creating a Pi Boot drive, in favour of an infinite timeout loop and a button to manually cancel/retry the current download. The wimp poll period has also been reduced when waiting for stream data, so it should download quicker. |
Jess Hampshire (158) 865 posts |
Hi. I have been playing with 1.01 and I like it, and have a couple of requests and a question. 1. Could you add an option for USB booting for the Pi disks? Does the Raspberry Pi need its boot partition physically at the start of the drive? Thanks |
Jon Abbott (1421) 2652 posts |
Sure, what do I need to add? I’m assuming that’s a Pi4 thing as earlier Pi’s had to be “burned” to boot from USB.
I need to write a full Package Manager to replace what’s currently in Partition Manager as it’s hard-coded links that need updating when ROOL change the builds. The Package Manager will include an option to cache packages.
It needs to be the first MBR partition so should logically come “before” the FileCore partition. As RISCOS doesn’t understand MBR partitions, it’s put inside the FileCore drive at the start of the disc, which also allows !Boot.Loader to both point to it and essentially map it out of the FileCore map. |
Jess Hampshire (158) 865 posts |
>Sure, what do I need to add? I’m assuming that’s a Pi4 thing as earlier Pi’s had to be “burned” to boot from USB. Thanks, it’s the default filesystem that needs to be changed. >> Does the Raspberry Pi need its boot partition physically at the start of the drive? It would be interesting to see if putting the details for the FC partition in the last partition slot, and the Pi Boot in the first slot, but physically after it would work and not cause problems. (Presumably the Pi Boot would have to be within some boundary.) |
Jon Abbott (1421) 2652 posts |
As in Configure FileSystem? I’m not totally sure how that would be implemented as the system needs to initially boot to create !Boot.Loader.CMOS. The CMOS file is created by an Obey file that PM drops into !Boot.RO520Hook.Boot.PreDesk called !!CMOSInit – which is currently hardcoded for SDFS. If I can detect the boot drive, I can make !!CMOSInit create !Boot.Loader.CMOS on the correct drive and then configure FileSystem to the matching filesystem.
Why would you want it moved? It’s a bootstrap partition that’s pretty much ignored once booted. MBR is so old (pre Arthur) I’ve not managed to find a definitive specification, but reordering the partitions might break something as I think its generally accepted partitions are consecutive for gap detection. |
Jess Hampshire (158) 865 posts |
> As in Configure FileSystem? Yes. I managed to get a stick booting to desktop (but it had none of the ROOL customisations and looks like RO 3.7 etc) by following steps in various instructions I found that didn’t work on their own. But it did include configure filesystem scsi, manually running the !boot and then copying CMOS file manually. I can do more experiments to see which steps actually did it, if that would help. (What is the smallest drive that will work?). > Why would you want it moved? It’s a bootstrap partition that’s pretty much ignored once booted. The overlapping partitions idea, although very clever is a bit horrid. But all the time you are talking about a drive that will only be used with RISC OS, it’s fine and will serve as protection if plugged into other systems. But I’m thinking in terms of when you are using multiple systems. (RISC OS is brilliant at some things, but useless at others, so if you want a single device, multiple booting is vital). > MBR is so old (pre Arthur) I’ve not managed to find a definitive specification, but reordering the partitions might break something as I think its generally accepted partitions are consecutive for gap detection. I’m pretty sure I have seen out of order partitions in the past, without issues. (However “without issues” would only be known on those specific old systems.) As far as RISC OS goes, it would know nothing, apart from DOSFS? As far as the Pi loader goes, there has to be some limit within which the loader partition must be contained (eg within first 8GB). If out of order partition are legal (and respected) it would give far more flexibility and interoperability. |
Jon Abbott (1421) 2652 posts |
Those customisations are only found in the full SD image – they’re not in Harddisc4 or if they are, it doesn’t default to them.
Although it’s not ideal, PM does create a drive that’s legal for other OS’s. A protective MBR partition is added to cover the region FileCore occupies so you can move the drive between OS and add additional partitions after the FileCore partition.
RISC OS sees a “full-disc” FileCore drive only. !Boot.Loader is a file within the FileCore drive, it’s not seen as a partition. The Pi Firmware only sees the first MBR FAT partition as far as I’m aware. The limit of which is the MBR limit of 2^32-1 sectors or 2TB with 512 byte sectors.
I don’t believe moving the Bootstrap partition would add anything as its a partition that should really be ignored by all OS. If you need interoperability, create a drive that has space at the end and add a FAT partition as a 3rd partition. |
Chris Hall (132) 3567 posts |
but reordering the partitions might break something The filecore partition always resides at a fixed offset, just clear of the partition table. It knows its size from its own internals not from any partition table. If you create a dual-partition image using !SystemDisc it will protect the filecore partition with a partition table entry (type=filecore) that extends to the end of the filecore partition. The DOSFS image file also has a partition table entry to protect its FAT partition but the space it reserves just ‘happens’ to be where the contents of the filecore file Boot:Loader reside. The partitions overlap but I do not think the partition table entries actually overlap. |
Jess Hampshire (158) 865 posts |
> If you need interoperability, create a drive that has space at the end and add a FAT partition as a 3rd partition. I’ve already done that with your app. But the situation I was thinking of is using partition tools on a different system. I’m not suggesting a change of default behaviour, but if it works, it could could be an interesting use at your own peril option. |
Pages: 1 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29