[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian installer image for Debian/m68k



On Mon, 4 Sep 2017, Laurent Vivier wrote:

> Le 02/09/2017 à 07:33, John Paul Adrian Glaubitz a écrit :
> > On 09/02/2017 05:34 AM, Finn Thain wrote:
> >> The "-probe" and "--netatalk" options are not listed in the upstream 
> >> man page for xorrisofs which makes me think that both the m68k and 
> >> the powerpc code here has bit-rotted.
> > 
> > No, not bit-rotted. But rather, they were never implemented in 
> > xorrisofs which is used these days instead of the classic mkisofs. 
> > There is still genisoimage from the cdrkit package which is a fork of 
> > the original cdrecord and hence the original mkisofs. I was just using 
> > the wrong tool.
> > 
> >> The hfs options look okay but they are for yaboot on PowerMacs. To 
> >> create bootable CD for 68k Macs would be a different process (using 
> >> EMILE SCSI CD-ROM drivers) etc.
> > 
> > Laurent probably knows what to do here :).
> >
> 
> I've built (but not tested) a bootable CDROM:
> 

Nice!

> http://vivier.eu/debian-9.0-m68k-NETINST-1-emile.iso
> [currently uploading, available in 30 minutes]
> 
> 165011456 bytes
> 
> md5sum:
> 
> 0b53ed7fc453ef235f67519db76dad60  debian-9.0-m68k-NETINST-1-emile.iso
> 
> steps:
> 
> on x86:
>     ./configure
>     make clean
>     make tools
> 
> on m68k:
>     ./configure
>     make clean
>     make all
> 
> on x86:
>    mkdir mnt/cdrom
>    sudo mount debian-9.0-m68k-NETINST-1.iso mnt/cdrom/ -o loop
>    cd mnt/cdrom
>    mkdir ../../bootable
>    find .| cpio -p ../../bootable
>    cd ../..
>    sudo umount mnt/cdrom
>    sudo vi bootable/install/cdrom.conf
> 
> --8<---------------------------------------------------
> timeout 5
> default 0
> vga default
> 
> title Sid Install
> kernel /install/kernels/vmlinuz-4.12.0-1-m68k
> initrd /install/cdrom/initrd.gz
> 
> title Sid Install (Expert Mode)
> kernel /install/kernels/vmlinuz-4.12.0-1-m68k
> args priority=low
> initrd /install/cdrom/initrd.gz
> 
> title Rescue Mode
> kernel /install/kernels/vmlinuz-4.12.0-1-m68k
> args rescue/enable=true
> initrd /install/cdrom/initrd.gz
> --8<---------------------------------------------------
> 

I guess this should be packaged up as part of emile, such that debian-cd 
can insert pathnames.

> .../emile/tools/x86_64-linux/emile-mkisofs -e
> .../emile/second/m68k-linux-scsi-driver/apple_driver -c
> /install/cdrom.conf boot.iso bootable
> 
> The generated mkisofs command is:
> /usr/bin/mkisofs -quiet -hfs -joliet -R -boot-hfs-file
> /tmp/emile-mkisofs-emchAx -graft-points -o boot.iso mnt/cdrom/
> 

That last token should be "bootable", not "mnt/cdrom", right?

This looks like shell script calling a C program to generate a shell 
script, (which now has to be called from the existing debian-cd bash 
scripts).

Instead of shell script generation and temporary files with fixed TMPDIR 
and hard-coded choices like "/usr/bin", "-quiet -joliet -R", all written 
in C, did you consider post-processing the output of mkisofs? E.g.

# mkisofs -quiet -hfs -joliet -R -boot-hfs-file X -graft-points -o boot.iso mnt/cdrom/

where X is some dummy partition map of a suitable size.

Then a hypothetical command to fix up the partitions in the APM in the 
ISO,

# emile-Y -e .../apple_driver -c .../boot.conf boot.iso

I suppose this would be analagous to editing the existing partition map on 
a harddisk.

Then emile-mkisofs could become a shell script for the convenience of 
those users who might want to re-use/adjust it.

The debian-cd scripts can't use that command because they don't actually 
call "mkisofs", and don't use -quiet etc. But they would be able to call 
a hypothetical "emile-Y" command to post-process the ISO.

FYI the debian-cd scripts are here,
https://anonscm.debian.org/cgit/debian-cd/debian-cd.git/tree/tools/boot/stretch/boot-m68k

This is just my $0.02 based on a superficial reading. I guess you've 
probably already considered this approach (?)

-- 

> /tmp/emile-mkisofs-emchAx is created by emile-mkisofs and
> contains the partition map and the bootloader.
> 
> Laurent
> 
> 

Reply to: