DumbDD

[gsteemso]

true. I didn't know about the other partitions but I agree completely with your assessment.

 

[Phipli]

true. I didn't know about the other partitions but I agree completely with your assessment.

I could be incorrectly crossing over two separate discussions, but that was what I was trying to work out. A bit of jiggery-pokery on a modern machine to pre-tweak the image and a raw disk write could be the solution to all this.

 

[saybur]

On that note, for my purposes, it would be great if I could run this in System 6, 7 or 8.1 at VERY latest. saybur, what’s the minimum OS your very alpha version will run?

Should run in 6.0.4(ish) and up but it's untested on anything other than 7.5.5

if I'm then running this on a PB1400 that boots from IDE (and has the .iso on a PCMCIA->CF card), then there's no chance it'll overwrite my boot volume?

Well it shouldn't but this is hot code so I'm not comfortable saying it definitely will not. It seems unlikely unless the OS maps IDE devices onto SCSI IDs or something like that.

Would be prudent to have anything important backed up just to be on the safe side, but obviously that advice applies to any system (not great about following it myself)

 

[Phipli]

Re-reading the other thread, the disk image should be already converted into a single multi partition disk. So that's good news

 

[Snial]

it sounds like his Whole Disc Image includes the partition table. That would cause any system that mounts the drive to ignore the unused space because it is not mapped, but should not cause any actual problems.

Correct!

The .iso will include an ISO <whateverthestandardnumberis> partition map, just as any other optical disc. If the PA-RISC system can boot from a CD it shouldn't have any trouble reading it.

That's the idea.

In the other thread Snial was talking about appending two other disks, so the data that would be ignored in that scenario would be two other disks, including their partition tables and data partitions. Unless the image he is writing has already been modified to have a valid partition table for all three partitions, or he is only writing the image from a single CD.

The whole installation is on 3 CDs. So, the first .iso would contain the normal .iso partition table and the PA-RISC system should boot from it and won't see the other CDs, but that's fine.

For the Debian installation, I understand that the first .iso is the core installation and the other(s) are additional packages. So, I think it should be possible to mount those on reboot based on the sector offset and then install the packages.

So, I was thinking this would be reasonable, because I did something similar when playing with a MAME-based SparcStation 1 emulator on my Mac mini 2012. I couldn't get the FD to work, but I could create a HD image with a missing partition; then mount that missing partition from within SunOS and dd to it. Then I could shutdown and from the host side, dd the data back out. It was very crude, but worked. In the future I plan to use the emulated ethernet to transfer data, now that I have a better grasp of how to link it up to virtual network interfaces on the Mac.

But thinking about it again, I might be wrong, or at least a bit wrong. I would need to mount the other .iso images as .iso's so that the target (the PA-RISC system) understands their partition maps too. Maybe that's reasonable: the other .iso s on the HD won't be on partitions on the HD, so it's not like it's partitions within partitions.

It does mean that DumbDD needs to be able to specify the target offset, which I hadn't considered earlier... though I could get around that too just by joining them all together. However, I might not do that as I might not want to write 2GB in one go, just 644MB at a time.

 

[Phipli]

Correct!

That's the idea.

The whole installation is on 3 CDs. So, the first .iso would contain the normal .iso partition table and the PA-RISC system should boot from it and won't see the other CDs, but that's fine.

For the Debian installation, I understand that the first .iso is the core installation and the other(s) are additional packages. So, I think it should be possible to mount those on reboot based on the sector offset and then install the packages.

So, I was thinking this would be reasonable, because I did something similar when playing with a MAME-based SparcStation 1 emulator on my Mac mini 2012. I couldn't get the FD to work, but I could create a HD image with a missing partition; then mount that missing partition from within SunOS and dd to it. Then I could shutdown and from the host side, dd the data back out. It was very crude, but worked. In the future I plan to use the emulated ethernet to transfer data, now that I have a better grasp of how to link it up to virtual network interfaces on the Mac.

But thinking about it again, I might be wrong, or at least a bit wrong. I would need to mount the other .iso images as .iso's so that the target (the PA-RISC system) understands their partition maps too. Maybe that's reasonable: the other .iso s on the HD won't be on partitions on the HD, so it's not like it's partitions within partitions.

It does mean that DumbDD needs to be able to specify the target offset, which I hadn't considered earlier... though I could get around that too just by joining them all together. However, I might not do that as I might not want to write 2GB in one go, just 644MB at a time.

Are you sure the merge script doesn't just extend the first image and move the package files onto it?

 

[saybur]

Are you sure the merge script doesn't just extend the first image and move the package files onto it?

The Debian script it looks like it merges all .isos into a single readable image, complete with combined package lists and the like.

 

[Snial]

The Debian script it looks like it merges all .isos into a single readable image, complete with combined package lists and the like.

Aaah, OK. I'd looked at the web page talking about this and then forgot about it. So, perhaps that solves one problem: it results in a merged .iso . In this case, the .iso would be about 1.932GB I think, less than 2GB. Sorry about that.

This is from:

Post in thread 'How do I write Macintosh CD images to physical CD's?'

Wednesday at 11:16 AM

OK, I have a related question: I'm planning to put 3x 650MB Debian .iso's onto a single 2.1GB SCSI HD (an actual SCSI HD) as a single image. There's a web page telling me how to merge the .iso's:

MergeDebianIsos - Debian Wiki

wiki.debian.org

However, my PowerBook 1400 is my only properly working SCSI Mac. So, the workflow is:

DebianIsoDownloads -> Mac mini i5 -> CF Card -> PowerBook 1400c -> External SCSI HD.

Now, with Mac OS X I could use dd to copy the .iso's block by block. I'm not sure what I should use with Mac OS 8.1. I certainly don't want a partition table...

• Snial

Of course, where it says: "I certainly don't want a partition table", it means I don't want an Apple Partition Table, the original .iso partitions are fine and expected.

 

[Phipli]

The Debian script it looks like it merges all .isos into a single readable image, complete with combined package lists and the like.

I was thinking it would be strange if it didn't and the description on the page sounded like it did.