You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even though QEMU supports it, the UI of UTM allows not to specifiy details.
e.g. IDE drives are created in this sequence:
IDE0.0
IDE0.1
IDE1.0
IDE1.1
but in reality, each of these four allow for two drives, a master and a slave; which is why QEMU has the index command.
So there could be:
IDE0.0 index 0
IDE0.0 index 1
IDE0.1 index 0
IDE0.1 index 1
IDE1.0 index 0
IDE1.0 index 1
IDE1.1 index 0
IDE1.1 index 1
This is particularly relevant, as CD-ROM drives are created as
IDE0.1
as this is the MS-Windows standard. But some legacy operating systems, in particularly NeXTSTEP and OpenStep, which as predecessors of macOS/i(Pad)OS would be particularly interesting to run on a Mac or iOS device, expect the CD-ROM drive to be at:
IDE0.0 index 1
it is thus impossible to install these operating systems under UTM.
Similar issues are applicable in regards to SCSI, where it’s impossible to indicate target and LUN (logical unit number). Again, certain legacy operating systems expect certain devices to be accessible under a specific target and LUN, and UTM simply sequentially allocating them, all with LUN0, isn’t allowing this to work.
The text was updated successfully, but these errors were encountered:
This is particularly relevant, as CD-ROM drives are created as
IDE0.1
as this is the MS-Windows standard. But some legacy operating systems, in particularly NeXTSTEP and OpenStep, which as predecessors of macOS/i(Pad)OS would be particularly interesting to run on a Mac or iOS device, expect the CD-ROM drive to be at:
Is that the reason behind NeXTStep/OpenStep not being able to proceed in the instillation process?
On Aug 29, 2024, at 01:03, Austin ***@***.***> wrote:
This is particularly relevant, as CD-ROM drives are created as
IDE0.1
as this is the MS-Windows standard. But some legacy operating systems, in particularly NeXTSTEP and OpenStep, which as predecessors of macOS/i(Pad)OS would be particularly interesting to run on a Mac or iOS device, expect the CD-ROM drive to be at:
Is that the reason behind NeXTStep/OpenStep not being able to proceed in the instillation process?
—
Reply to this email directly, view it on GitHub <#6529 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN7IO7RLEEH5QOPHXV3IZTZTZJL3AVCNFSM6AAAAABLYYQLJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJWGM4DENRWHA>.
You are receiving this because you authored the thread.
Even though QEMU supports it, the UI of UTM allows not to specifiy details.
e.g. IDE drives are created in this sequence:
IDE0.0
IDE0.1
IDE1.0
IDE1.1
but in reality, each of these four allow for two drives, a master and a slave; which is why QEMU has the index command.
So there could be:
IDE0.0 index 0
IDE0.0 index 1
IDE0.1 index 0
IDE0.1 index 1
IDE1.0 index 0
IDE1.0 index 1
IDE1.1 index 0
IDE1.1 index 1
This is particularly relevant, as CD-ROM drives are created as
IDE0.1
as this is the MS-Windows standard. But some legacy operating systems, in particularly NeXTSTEP and OpenStep, which as predecessors of macOS/i(Pad)OS would be particularly interesting to run on a Mac or iOS device, expect the CD-ROM drive to be at:
IDE0.0 index 1
it is thus impossible to install these operating systems under UTM.
Similar issues are applicable in regards to SCSI, where it’s impossible to indicate target and LUN (logical unit number). Again, certain legacy operating systems expect certain devices to be accessible under a specific target and LUN, and UTM simply sequentially allocating them, all with LUN0, isn’t allowing this to work.
The text was updated successfully, but these errors were encountered: