Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems
92 views
Skip to first unread message
Alan Tu
Apr 30, 2018, 11:00:04 AM4/30/18
to
Hi, I'm having trouble bootting Debian 9.4 on a QEMU-emulated MIPS
malta virtual machine. I know QEMU introduces some complexity, but I
think my problem is more of a misunderstanding of Linux boot concepts.
I've tried different permutations, and reading, but am stuck.
I installed Debian inside a virtual disk image. Here is the output of
"fdisk -lu" that shows the partition setup of this disk image. I think
it shows a valid and recognized first partition, as set up at
install-time.
$ fdisk -lu debian_mips32b.img
Disk debian_mips32b.img: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6c0f31a2
Device Boot Start End Sectors Size Id Type
debian_mips32b.img1 2048 15992831 15990784 7.6G 83 Linux
debian_mips32b.img2 15994878 16775167 780290 381M 5 Extended
debian_mips32b.img5 15994880 16775167 780288 381M 82 Linux
swap / Solaris
Booting this doesn't work. If I supply the same Debian initrd image I
used to install, I see the installer language selection menu, not the
system. Despite the fact I don't attach a virtual CD-ROM install
media.
If I don't point qemu at the initrd RAM disk, the kernel seems to
start, but it has problems.
# qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
-nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
-append "root=/dev/sda1"
I've attached the console output, but note:
[ 0.000000] Kernel command line: root=/dev/sda1 console=ttyS0,38400n8r
This suggests that the kernel has received my intention to look for
root on /dev/sda1. But then:
[ 0.644281] List of all partitions:
[ 0.644483] No filesystem could mount root, tried: [ 0.644669]
[ 0.644847] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(0,0)
So two questions:
1. Am I supposed to tell the virtual machine where to find the initrd
RAM disk, and do I use the same initrd downloaded from Debian as the
installer, or a different initrd from somewhere? The kernel seems to
go some way without this.
2. It seems the kernel is somehow not recognizing the partition. I'm
not sure what the problem is here.
I'd appreciate any hints. Even confirming how things are supposed to
work helps. Thanks.
Alan
malta virtual machine. I know QEMU introduces some complexity, but I
think my problem is more of a misunderstanding of Linux boot concepts.
I've tried different permutations, and reading, but am stuck.
I installed Debian inside a virtual disk image. Here is the output of
"fdisk -lu" that shows the partition setup of this disk image. I think
it shows a valid and recognized first partition, as set up at
install-time.
$ fdisk -lu debian_mips32b.img
Disk debian_mips32b.img: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6c0f31a2
Device Boot Start End Sectors Size Id Type
debian_mips32b.img1 2048 15992831 15990784 7.6G 83 Linux
debian_mips32b.img2 15994878 16775167 780290 381M 5 Extended
debian_mips32b.img5 15994880 16775167 780288 381M 82 Linux
swap / Solaris
Booting this doesn't work. If I supply the same Debian initrd image I
used to install, I see the installer language selection menu, not the
system. Despite the fact I don't attach a virtual CD-ROM install
media.
If I don't point qemu at the initrd RAM disk, the kernel seems to
start, but it has problems.
# qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
-nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
-append "root=/dev/sda1"
I've attached the console output, but note:
[ 0.000000] Kernel command line: root=/dev/sda1 console=ttyS0,38400n8r
This suggests that the kernel has received my intention to look for
root on /dev/sda1. But then:
[ 0.644281] List of all partitions:
[ 0.644483] No filesystem could mount root, tried: [ 0.644669]
[ 0.644847] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(0,0)
So two questions:
1. Am I supposed to tell the virtual machine where to find the initrd
RAM disk, and do I use the same initrd downloaded from Debian as the
installer, or a different initrd from somewhere? The kernel seems to
go some way without this.
2. It seems the kernel is somehow not recognizing the partition. I'm
not sure what the problem is here.
I'd appreciate any hints. Even confirming how things are supposed to
work helps. Thanks.
Alan
Reco
Apr 30, 2018, 12:40:03 PM4/30/18
to
Hi.
On Mon, Apr 30, 2018 at 06:30:32PM +0200, Thomas Schmitt wrote:
> > # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> > -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> > -append "root=/dev/sda1"
>
> Shouldn't there be a bootloader installed in debian_mips32b.img ?
No. One of the oddities of QEMU's malta that nobody was able to write a
working bootloader for it. OP is doing it the only way that's possible.
Reco
On Mon, Apr 30, 2018 at 06:30:32PM +0200, Thomas Schmitt wrote:
> > # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> > -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> > -append "root=/dev/sda1"
>
No. One of the oddities of QEMU's malta that nobody was able to write a
working bootloader for it. OP is doing it the only way that's possible.
Reco
Thomas Schmitt
Apr 30, 2018, 12:40:03 PM4/30/18
to
Hi,
Alan Tu wrote:
> I installed Debian inside a virtual disk image.
>From outside qemu ? That could be tricky because being unusual.
Last time i installed a virtual Debian, i did something like this:
# Create virtual disk as data file
qemu-img create debian_vm_disk.qemu 32G
# Start qemu to install Debian from netinst ISO
qemu-system-x86_64 -enable-kvm -m 512 \
-net nic \
-hda debian_vm_disk.qemu \
-cdrom debian-9.3.0-amd64-netinst.iso \
-boot d
I just tested this. A graphics window comes up, a boot loader menu appears
and offers "Graphical install", "Install", "Advanced options", ...
(I think i used "Install". It was a Debian 8 ISO which i then converted
into a Debian Sid. More than two years ago ...)
> # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> -append "root=/dev/sda1"
Maybe via
https://www.debian.org/ports/mips/
So you could learn how it roughly has to look like.
"qemu-system-mips" ... 32 bit big-endian ? A virtual SGI Iris ? Oh nostalgy.
Have a nice day :)
Thomas
Alan Tu wrote:
> I installed Debian inside a virtual disk image.
Last time i installed a virtual Debian, i did something like this:
# Create virtual disk as data file
qemu-img create debian_vm_disk.qemu 32G
# Start qemu to install Debian from netinst ISO
qemu-system-x86_64 -enable-kvm -m 512 \
-net nic \
-hda debian_vm_disk.qemu \
-cdrom debian-9.3.0-amd64-netinst.iso \
-boot d
I just tested this. A graphics window comes up, a boot loader menu appears
and offers "Graphical install", "Install", "Advanced options", ...
(I think i used "Install". It was a Debian 8 ISO which i then converted
into a Debian Sid. More than two years ago ...)
> # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> -append "root=/dev/sda1"
Shouldn't there be a bootloader installed in debian_mips32b.img ?
Maybe you first need to find somebody who has a Debian installed on mips.
Maybe via
https://www.debian.org/ports/mips/
So you could learn how it roughly has to look like.
"qemu-system-mips" ... 32 bit big-endian ? A virtual SGI Iris ? Oh nostalgy.
Have a nice day :)
Thomas
Reco
Apr 30, 2018, 12:40:04 PM4/30/18
to
Hi.
On Mon, Apr 30, 2018 at 07:54:56AM -0700, Alan Tu wrote:
> Hi, I'm having trouble bootting Debian 9.4 on a QEMU-emulated MIPS
> malta virtual machine. I know QEMU introduces some complexity, but I
> think my problem is more of a misunderstanding of Linux boot concepts.
> I've tried different permutations, and reading, but am stuck.
On the contrary. Compared to the hassle of dealing with the real
hardware, QEMU is the easy mode. If it works in that particular version,
that is.
Luckily for us, QEMU 2.8 they put in stable is in pretty good shape for
MIPS. Cannot say the same for SPARC64, for instance.
> I installed Debian inside a virtual disk image. Here is the output of
> "fdisk -lu" that shows the partition setup of this disk image. I think
> it shows a valid and recognized first partition, as set up at
> install-time.
> $ fdisk -lu debian_mips32b.img
> Disk debian_mips32b.img: 8 GiB, 8589934592 bytes, 16777216 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x6c0f31a2
>
> Device Boot Start End Sectors Size Id Type
> debian_mips32b.img1 2048 15992831 15990784 7.6G 83 Linux
> debian_mips32b.img2 15994878 16775167 780290 381M 5 Extended
> debian_mips32b.img5 15994880 16775167 780288 381M 82 Linux
> swap / Solaris
>
> Booting this doesn't work. If I supply the same Debian initrd image I
> used to install, I see the installer language selection menu, not the
> system. Despite the fact I don't attach a virtual CD-ROM install
> media.
That's expected. Installer's initrd serves one purpose exactly - to run
debian-installer. It's not supposed to boot your installed Debian
system.
> If I don't point qemu at the initrd RAM disk, the kernel seems to
> start, but it has problems.
> # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> -append "root=/dev/sda1"
That's understandable too. Debian kernel does not have any filesystem
compiled in, they all come as modules. You don't supply initrd - kernel
is unable to mount your root filesystem.
> So two questions:
>
> 1. Am I supposed to tell the virtual machine where to find the initrd
> RAM disk, and do I use the same initrd downloaded from Debian as the
> installer, or a different initrd from somewhere? The kernel seems to
> go some way without this.
The most simple way to boot Debian in QEMU is - mount your first
partition of your debian_mips32b.img in the host OS. Unless I forgot how
to count, either:
mount -o offset=1048576 debian_mips32b.img /mnt
or (don't forget kpartx -d afterwards):
kpartx -a debian_mips32b.img
mount /dev/mapper/loop0p1 /mnt
should do it.
Then you copy vmlinuz *and* initrd from MIPS root filesystem, and use
those in QEMU. Rinse and repeat after each kernel update.
> 2. It seems the kernel is somehow not recognizing the partition. I'm
> not sure what the problem is here.
See above.
Reco
On Mon, Apr 30, 2018 at 07:54:56AM -0700, Alan Tu wrote:
> Hi, I'm having trouble bootting Debian 9.4 on a QEMU-emulated MIPS
> malta virtual machine. I know QEMU introduces some complexity, but I
> think my problem is more of a misunderstanding of Linux boot concepts.
> I've tried different permutations, and reading, but am stuck.
hardware, QEMU is the easy mode. If it works in that particular version,
that is.
Luckily for us, QEMU 2.8 they put in stable is in pretty good shape for
MIPS. Cannot say the same for SPARC64, for instance.
> I installed Debian inside a virtual disk image. Here is the output of
> "fdisk -lu" that shows the partition setup of this disk image. I think
> it shows a valid and recognized first partition, as set up at
> install-time.
> $ fdisk -lu debian_mips32b.img
> Disk debian_mips32b.img: 8 GiB, 8589934592 bytes, 16777216 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x6c0f31a2
>
> Device Boot Start End Sectors Size Id Type
> debian_mips32b.img1 2048 15992831 15990784 7.6G 83 Linux
> debian_mips32b.img2 15994878 16775167 780290 381M 5 Extended
> debian_mips32b.img5 15994880 16775167 780288 381M 82 Linux
> swap / Solaris
>
> Booting this doesn't work. If I supply the same Debian initrd image I
> used to install, I see the installer language selection menu, not the
> system. Despite the fact I don't attach a virtual CD-ROM install
> media.
debian-installer. It's not supposed to boot your installed Debian
system.
> If I don't point qemu at the initrd RAM disk, the kernel seems to
> start, but it has problems.
> # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> -append "root=/dev/sda1"
compiled in, they all come as modules. You don't supply initrd - kernel
is unable to mount your root filesystem.
> So two questions:
>
> 1. Am I supposed to tell the virtual machine where to find the initrd
> RAM disk, and do I use the same initrd downloaded from Debian as the
> installer, or a different initrd from somewhere? The kernel seems to
> go some way without this.
partition of your debian_mips32b.img in the host OS. Unless I forgot how
to count, either:
mount -o offset=1048576 debian_mips32b.img /mnt
or (don't forget kpartx -d afterwards):
kpartx -a debian_mips32b.img
mount /dev/mapper/loop0p1 /mnt
should do it.
Then you copy vmlinuz *and* initrd from MIPS root filesystem, and use
those in QEMU. Rinse and repeat after each kernel update.
> 2. It seems the kernel is somehow not recognizing the partition. I'm
> not sure what the problem is here.
Reco
Alan Tu
Apr 30, 2018, 12:50:04 PM4/30/18
to
Thanks Reco. The concept I missed is, I need to grab the initrd and
kernel from the installed system, specifically from the /boot
directory. I know that now for all future architectures I mess with!
There are lots of ways to do the same thing, I'm just sharing. To
mount a partition inside raw disk image, one can use the loopback
device.
1. Determine the byte offset of the desired partition.
$ fdisk -lu
$offset=sector size * start sector
2. Create the loopback link.
# losetup -o $offset /dev/loop0 image_file
3. Mount as usual:
# mount /dev/loop0 directory
4. Copy files, edit/make changes, etc.
5. When done, umount as usual:
# umount /dev/loop0
6. Detach the loopback device.
# losetup -d /dev/loop0
Alan
kernel from the installed system, specifically from the /boot
directory. I know that now for all future architectures I mess with!
There are lots of ways to do the same thing, I'm just sharing. To
mount a partition inside raw disk image, one can use the loopback
device.
1. Determine the byte offset of the desired partition.
$ fdisk -lu
$offset=sector size * start sector
2. Create the loopback link.
# losetup -o $offset /dev/loop0 image_file
3. Mount as usual:
# mount /dev/loop0 directory
4. Copy files, edit/make changes, etc.
5. When done, umount as usual:
# umount /dev/loop0
6. Detach the loopback device.
# losetup -d /dev/loop0
Alan
Thomas Schmitt
Apr 30, 2018, 1:00:04 PM4/30/18
to
Hi,
i wrote:
> > Shouldn't there be a bootloader installed in debian_mips32b.img ?
more recently than 20 years ago.
Would my idea to install from ISO work at all ?
(I have a debian-7.4.0-mips-netinst.iso but feel not really in the mood
for trying what would happen.)
i wrote:
> > Shouldn't there be a bootloader installed in debian_mips32b.img ?
Reco wrote:
> No. One of the oddities of QEMU's malta that nobody was able to write a
> working bootloader for it. OP is doing it the only way that's possible.
And he has luck to already have found somebody who has seen a MIPS
> No. One of the oddities of QEMU's malta that nobody was able to write a
> working bootloader for it. OP is doing it the only way that's possible.
more recently than 20 years ago.
Would my idea to install from ISO work at all ?
(I have a debian-7.4.0-mips-netinst.iso but feel not really in the mood
for trying what would happen.)
Reco
Apr 30, 2018, 1:50:03 PM4/30/18
to
Hi.
In-Reply-To: <382477610...@scdbackup.webframe.org>
$ qemu-system-mips -m 2048 -nographic -cdrom /tmp/debian-7.4.0-mips-netinst.iso -boot d
qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no -kernel argument was specified
Of course if you happen to have that magic mips_bios.bin lying around -
it may even boot. Or not. Even the installation guide mentions TFTP as a
preferred way to install Debian on MIPS.
Also, that 'iso' is no way a conventional ISO9660 or UDF image:
$ file -sL /tmp/debian-7.4.0-mips-netinst.iso
/tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)
[1] https://www.debian.org/releases/stable/mipsel/ch02s01.html.en
Reco
In-Reply-To: <382477610...@scdbackup.webframe.org>
qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no -kernel argument was specified
Of course if you happen to have that magic mips_bios.bin lying around -
it may even boot. Or not. Even the installation guide mentions TFTP as a
preferred way to install Debian on MIPS.
Also, that 'iso' is no way a conventional ISO9660 or UDF image:
$ file -sL /tmp/debian-7.4.0-mips-netinst.iso
/tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)
[1] https://www.debian.org/releases/stable/mipsel/ch02s01.html.en
Reco
Reco
Apr 30, 2018, 1:50:04 PM4/30/18
to
Hi.
On Mon, Apr 30, 2018 at 06:58:13PM +0200, Thomas Schmitt wrote:
Reco
On Mon, Apr 30, 2018 at 06:58:13PM +0200, Thomas Schmitt wrote:
$ qemu-system-mips -m 2048 -nographic -cdrom
/tmp/debian-7.4.0-mips-netinst.iso -boot d
qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no
-kernel argument was specified
Of course if you happen to have that magic mips_bios.bin lying around -
it may even boot. Or not. Even the installation guide mentions TFTP as a
preferred way to install Debian on MIPS.
Also, that 'iso' is no way a conventional ISO9660 or UDF image:
$ file -sL /tmp/debian-7.4.0-mips-netinst.iso
/tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)
[1] https://www.debian.org/releases/stable/mipsel/ch02s01.html.en
PS I should be more careful with e-mail headers.
/tmp/debian-7.4.0-mips-netinst.iso -boot d
qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no
-kernel argument was specified
Of course if you happen to have that magic mips_bios.bin lying around -
it may even boot. Or not. Even the installation guide mentions TFTP as a
preferred way to install Debian on MIPS.
Also, that 'iso' is no way a conventional ISO9660 or UDF image:
$ file -sL /tmp/debian-7.4.0-mips-netinst.iso
/tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)
[1] https://www.debian.org/releases/stable/mipsel/ch02s01.html.en
Reco
Thomas Schmitt
Apr 30, 2018, 2:10:04 PM4/30/18
to
Hi,
Reco wrote:
> $ qemu-system-mips -m 2048 -nographic
> -cdrom /tmp/debian-7.4.0-mips-netinst.iso -boot d
> qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no -kernel
> argument was specified
Oops. I did not expect it to die so early.
> Also, that 'iso' is no way a conventional ISO9660 or UDF image:
> $ file -sL /tmp/debian-7.4.0-mips-netinst.iso
> /tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)
Oh, it is. But it is also a bit more than that.
It's only that the programmers of "file" did not account for that
combination as much as they did with x86 isohybrids:
$ file debian-9.3.0-amd64-netinst.iso
debian-9.3.0-amd64-netinst.iso: DOS/MBR boot sector ISO 9660 CD-ROM
filesystem data 'Debian 9.3.0 amd64 n' (bootable); partition 2 : ID=0xef,
start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 3760,
832 sectors
With the mips ISO, we have to combine file's report with info like this
$ isoinfo -i debian-7.4.0-mips-netinst.iso -d
CD-ROM is in ISO 9660 format
System id:
Volume id: Debian 7.4.0 mips 1
Volume set id:
Publisher id:
Data preparer id: XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 105591
Joliet with UCS level 3 found
Rock Ridge signatures version 1 found
xorriso can tell about the MIPS Volume Header which it created on demand
of debian-cd:
$ xorriso -report_about warning -indev debian-7.4.0-mips-netinst.iso \
-report_system_area plain
System area options: 0x00000004
System area summary: MIPS-Big-Endian
ISO image size/512 : 422364
MIPS-BE volume dir : N Name Block Bytes
MIPS-BE boot entry : 1 r4k-ip22 63436 10876928
MIPS-BE boot path : 1 /install/r4k-ip22-boot.img
But i guess it will be hard to determine which machines react on this.
My cheat sheet for boot sectors says
MIPS Volume Header
for MIPS Big Endian, e.g. SGI Indigo2
Sources:
cdrkit-1.1.10/genisoimage/boot-mips.c
by Steve McIntyre <st...@einval.com>
which refers to
genisovh by Florian Lohoff <f...@rfc822.org>
and Thiemo Seufer <seu...@csv.ica.uni-stuttgart.de>
who seem to have learned parameter settings from IRIX CD media
There are traces in the web which relate this to specs by
MIPS Computer Systems, Inc. , 1985
Silicon Graphics Computer Systems, Inc. , 2000
Mail conversations with Natalia Portillo.
Reco wrote:
> $ qemu-system-mips -m 2048 -nographic
> -cdrom /tmp/debian-7.4.0-mips-netinst.iso -boot d
> qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no -kernel
> argument was specified
> Also, that 'iso' is no way a conventional ISO9660 or UDF image:
> $ file -sL /tmp/debian-7.4.0-mips-netinst.iso
> /tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)
It's only that the programmers of "file" did not account for that
combination as much as they did with x86 isohybrids:
$ file debian-9.3.0-amd64-netinst.iso
debian-9.3.0-amd64-netinst.iso: DOS/MBR boot sector ISO 9660 CD-ROM
filesystem data 'Debian 9.3.0 amd64 n' (bootable); partition 2 : ID=0xef,
start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 3760,
832 sectors
With the mips ISO, we have to combine file's report with info like this
$ isoinfo -i debian-7.4.0-mips-netinst.iso -d
CD-ROM is in ISO 9660 format
System id:
Volume id: Debian 7.4.0 mips 1
Volume set id:
Publisher id:
Data preparer id: XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 105591
Joliet with UCS level 3 found
Rock Ridge signatures version 1 found
xorriso can tell about the MIPS Volume Header which it created on demand
of debian-cd:
$ xorriso -report_about warning -indev debian-7.4.0-mips-netinst.iso \
-report_system_area plain
System area options: 0x00000004
System area summary: MIPS-Big-Endian
ISO image size/512 : 422364
MIPS-BE volume dir : N Name Block Bytes
MIPS-BE boot entry : 1 r4k-ip22 63436 10876928
MIPS-BE boot path : 1 /install/r4k-ip22-boot.img
But i guess it will be hard to determine which machines react on this.
My cheat sheet for boot sectors says
MIPS Volume Header
for MIPS Big Endian, e.g. SGI Indigo2
Sources:
cdrkit-1.1.10/genisoimage/boot-mips.c
by Steve McIntyre <st...@einval.com>
which refers to
genisovh by Florian Lohoff <f...@rfc822.org>
and Thiemo Seufer <seu...@csv.ica.uni-stuttgart.de>
who seem to have learned parameter settings from IRIX CD media
There are traces in the web which relate this to specs by
MIPS Computer Systems, Inc. , 1985
Silicon Graphics Computer Systems, Inc. , 2000
Mail conversations with Natalia Portillo.
0 new messages