Bug#31450: boot-floppies 2.1.4 fails to build for m68k
Adam Di Carlo wrote:
> >> Michael, first off, care to help with the documentation of the
> >> Installation System? Cf
> >> http://www.debian.org/~aph/boot-floppies/m68k/install.html . I
> >> need the m68k stuff to be critiqued, corrected, and filled out.
> >> You can send me text in ASCII or SGML (linuxdoc), I don't mind.
A quick comment on the install guide is attached, I've written it while
the boot floppy stuff built ... (I just printed the couple of pages, no
sweat).
> > For starters, check
> > http://www.linux-m68k.org/debian-{atari,mac}.html.
>
> Yes, I'm aware of those.
OK ... I'm sorry for never submitting those to the boot floppy team,
they've been ready for a while now.
> > There's Franky's
> > Amiga install guide out somewhere too, I forgot the URL.
>
> http://www.informatik.uni-oldenburg.de/~amigo/debian_inst.html
Thanks, I'll look into that for booter info ...
> And don't forget:
>
> ftp://baltimore.wwaves.com/pub/MacLinux/debian-support/Debian-2.0-Mac-Install.html
Probably outdated;
http://www.mac.linux-m68k.org/docs/debian-mac-install.html
is the only (moderately) up to date copy.
> > The machine specific install guides available would fit in section 6
> > I guess. I only had a brief look at them but will have a closer look
> > (wish I could get it as ASCII text :-)
>
> Well, actually, the whole documents would have to be severely ripped
> down and then re-threaded into the boot-floppies Install Manual.
No problem as long as it's not me doing it. But just cut&paste text
from them ...
> Technical note: I'm using 'SGML marked sections' (cf
> http://www.sgml.u-net.com/book/sgml-8.htm) for architecture dependant
> portions, i.e., '<![ %i386 [ ... ]]>'.
I've seen similar concepts in other metafile systems... I don't do SGML,
and I rarely write HTML (or docs, for that matter).
> My focus is on documenting the *official* installation system. Some
> of those documents reference stuff which isn't really part of the
> official boot-floppies package. This should be fixed. Example: in
> the m68k boot disks, basecont.txt is called base-contents, but there's
> no code in the actual boot-floppies packge that does this. That's a
> bit of a conundrum for me since it is probably done by hand; I can't
> just monitor code changes in CVS to pick up changes.
There seems to be code that does this, I haven't created base-contents
manually ...
> I'm not trying to be a fascist, I'd just like to see the ports come
> into the mainstream. If we wanna rename files around, cool, but lets
> get the boot-floppies package to actually do that as well.
Yikes. As long as we can get away using MSDOS format floppies, fine.
The problem is, we can't.
> AFAIK, Mac isn't actually supported by the boot-floppies package, is
> it?
No, Mac boot floppies are made roughly like :
- take a MSDOS format Atari boot floppy
- delete the booter, kernel and sysmap
- copy Mac kernel and sysmap to floppy
- take floppy to a Mac
- copy booter to floppy, start booter, select kernel and ramdisk
on floppy, set kernel options, save preferences to preferences
file on floppy.
=> MS-DOS format Mac boot floppy image. Some Macs can boot from
that one if they can find a Linux or DOS box to write it to disk.
Used as resc1440mac.bin.
- copy contents of that floppy to folder on disk ('debian' is
a good name).
- pack folder with StuffIt into install.sit
=> use for disk based install
- take MacOS format floppy, copy folder content to floppy, start
booter, select kernel and ramdisk again, set kernel options,
save preferences.
- build floppy image with DiskCopy.
=> MacOS format boot floppy image.
The first three steps can be automated on any Linux box. Manipulating
the MacOS files is something I can't see any feasible way even with
hfsutils
and macutils. But I haven't tried a lot.
> >> You can set whatever kernel you like in the top-level makefile.
> >> How is this a bug?
>
> > Yea, that's right, it's a feature. Hardcoded kernel versions later
> > on are worse. And the unavailability of a Mac kernel image package
> > will force me to fake one in the end.
>
> > I guess I was complaining that these m68k features are still not
> > known or considered in the boot-floppies team. I admit that I
> > started out without reading the README :-)
>
> Oh, I'm very glad you brought them up. The fact that the
> pre-selections mechanism has no facility for dealing with (inevitable)
> package drift between ports is a big big bug.
I agree. Each arch would need to define what's release critical (or
even possible) to have, that needs to go into the package list for
boot-floppies.
> I wish you'd bring up more, since you're clearly doing home things by
> hand which I think should be automated.
I'd wish they could be automated. I build the Mac kernels on a PC but
not
as Debian package. I can't copy the Mac booter to a floppy image in
Linux
(hfsutils doesn't do floppy images IIRC). I can't handle floppies on a
Mac under Linux.
> > It gets even better; both ramdisks and base system have an
> > incomplete set of device files in /dev. Has all sorts of funny side
> > effects. Patch (for part of the problems, untested on base yet) and
> > description in a separate followup.
>
> Excellent. I hope Enrique wakes up soon and integrates these changes.
>
> BTW, I'm not a code hacker, I'm just a documenter.
Sorry about unloading all these build details on you then. The bug
report
was FUBAR, I hope Enrique reads it at all.
> > It's missing. Question goes to Franky: I'll extract the booter from
> > the 2.0 set if necessary, ok?
>
> I'd be happy to add this to CVS in the appropriate place, whereever
> that may be, if you like. Or go ahead and do it yourself? Do you
> work out of the boot-floppies CVS area?
Nope. I've only started with the boot-floppies yesterday, after ethernet
on the Quadra I build on came alive the day before. Only in 2.1 kernels,
which I can't use to build or install packages due to the nice
chown/lchown
feature. Even apt isn't possible.
Building floppies and base takes about 80 minutes on that machine, I
don't
even want to speculate how long it would take on the 030 at home. With
the
students back soon, CVS over the university dialup isn't an option.
Using
this Quadra isn't a real option either, unfortunately.
>
> >> > * recode * libc6-pic * recent makedev
> >>
> >> What's the issue here? I believe these are indeed required to
> >> build.
>
> > They are - is it mentioned somewhere, did I miss something? Didn't
> > show in James' source dependencies, at least.
>
> > grep Depends control
> Depends: libc6-pic, slang1-pic, sysutils, makedev (>=2.3.1-10), newt0.25, newt0.25-dev, popt, zlib1g, zlib1g-dev, recode
Thanks; I should start using things that simplify life... The source
depenencies
on the m68k server I grabbed may be a couple of days old, I'll check
again.
> > makedev (slink/binary-m68k as of yesterday) isn't recent enough, it
> > doesn't know generic-m68k (or generic, for that matter:
> > 'generic-generic not known'. Duh.).
>
> If you tell me the needed ver number, I'll be happy to tweak the
> versioning for 2.1.5.
I wish I knew. Need to file a bug against makedev and see what that
stirs up.
> > Something strange happens at the end of the whole install (after
> > adding some of the devices required manually to speed up the thing):
> > I can't log in; the login never prompts for the password but claims
> > incorrect login. Any idea on this?
>
> No, I'm just a humble manual writer!
Must have been a result of the broken device files. The current build
worked.
Just landed on the usual spot on master.
> > I'll see that I get a new set of base and rescue disks out tonight;
> > don't touch the current set, it's totally broken. New build in
> > progress.
>
> Cool, glad to see you guys are agressively working on this stuff.
That's the tail end of the holiday period. Meaning I'll be back to the
lab bench later this week, ending the 'aggressive' period.
Michael2.1:
- CPU requirements include a FPU currently.
- There's no m68k SMP system. Period. And no Pentium either (and some
m68k users are almost religious about their Intel hate, so please
delete that reference).
- At this time, kernel version for m68k is 2.0.33pl1.
2.2:
- Floppy is the least feasible installation method on m68k Amiga floppies
are only 720k on most machines, and notoriously unreliable (beyond the
level of 'reformat a different floppy, not the same') from what I hear.
Macs (for the most part) can use 1.44 MB DOS floppies with a common
system extension to import data or to launch the booter. There's no
floppy driver for Mac in the kernel, so floppies are not an option
to install anything from.
Summary: 'copy the floppy images to disk and click on the booter icon'
is the most common boot method on Atari, Amiga and Mac (yes, all of those
have a GUI OS :-).
- bootable CD for m68k? I don't think so. We hope to get the base files,
kernels, ramdisk and so on unpacked on the CD and bootable from CD but
three-way multisession is a bit over the top I think. Franky had been
working on the CD thing but got too busy to continue that; I don't
even have a CD drive, much less a writer, don't know about the
others.
<rant>
There hasn't been any official m68k CD yet (even though some morons
built CDs off hamm in the past, with fun stuff like Joliet extensions
that aren't even supported by the Debian install kernels :-). The
top, so far: Steve McIntyre (??) building slink CDs at a time where
there's no 2.1 boot floppy set.
</rant>
- storage systems not supported by boot disks? All available drivers are
built as modules and can be loaded at install time. SCSI, IDE disks
and CD-ROMs are compiled in. Floppy is insupported or useless ...
2.5:
- off the record:
Don't even get me started. Do you want me to pull Mac support because of
Apple's retro behaviour? We've been granted _no_ documentation on
anything in the Macs. It's all been a reverse engineering project, either
by us or by NetBSD.
Try e-mailing Steve Jobs; if nothing else it will annoy him a bit.
That's all you can hope for...
3.2:
- cfdisk is irrelevant for m68k, we have atari-fdisk, amiga-fdisk and
mac-fdisk. (VME??)
3.3:
- No firmware tweaks; check that your hardware is supported by Linux. (FAQ)
- boot your native OS and start the installation from there. See 2.2 comment
for the 'bootable CD' problem.
- overclocking: Amiga and Atari users should know what they're doing,
for Macs, there's only one known acceleration (9.81 m/s^2).
- bad RAM: Atari TT RAM boards are notorious, Amiga users may need to exclude
RAM using a booter memfile, no known problems with Macs (on top of the
usual :-)).
4.1:
- Note that all m68k archs (VME may be different?) have to be booted from
the native OS. You need to make sure you even stored the house key in a
safe place so you can enter the remodeled house again. Ataris have the bulk
of the OS in ROM, Mac users need to have the install floppies for MacOS.
Amiga ??
4.2:
- Atari (Falcon) and especially Mac: swapping is painful, you don't want
to try. Get as much RAM as possible.
5.1:
- rawrite2.exe doesn't exist for m68k (rawwrite.ttp existed for Atari,
what happened to it??). Amiga users will unpack install.lzh on the
AFFS partition (creates debian/), Mac users can either unpack install.sit
and copy the rescue and drivers image in the resulting debian/ folder.
Or they get DiskCopy and dump the DiskCopy floppy image to floppy. Only
Atari can use floppy to install.
- loadlin.exe is bootstra.ttp (Atari), Penguin-16 (Mac) and I don't know what
for Amiga. See the machine specific install guides.
- base2_0.tgz is base2_1.tgz I believe.
5.2:
- From native OS partition: this is the main install method, see above.
- Floppy based boot: only for Atari currently.
5.3:
- I haven't seen a m68k CD yet. Don't promise too much. BIOS ??
5.5:
- only for Atari. Use rawwrite.ttp if it can be found.
5.6:
- lowmem.bin not available so far.
6.1:
- Amiga installs from unpacked install.lzh, not floppy.
- Atari may use floppy or install.lzh, autoboot of Linux booter from
floppy doesn't work.
- Mac may install from floppy, but without reset (booter runs from MacOS).
(covered in mach specific install docs).
- there won't ever be a boot: promt.
- lowmem.bin not available for m68k, and dumping it to floppy dosen't
make sense on Amiga (default 720 kB disks, not PC format) and Mac
(no floppy driver). Dumping it to a disk filesystem is OK as long as
the lowmem.bin can handle that. root.bin needs to be read from disk
filesystem though.
6.2:
- low memory systems: I won't be able to install at all with only 5 MB
on my Mac unless I change the requirement for 6 MB. 2.0 ran with
5 MB, what's different in 2.1?
- need separate fdisk ({atari,amiga,mac}-fdisk) for each machine; dinstall
has to call the right one unless we have a full shell.
6.8:
- again, separate fdisk binaries, different ways to mark Linux partitions
etc.
6.11:
- On Mac, a quirk of the HFS filesystem default 'personality' makes each
directory show up three times in the path list. For example, files found
in /debian will result in path list
/instmnt/debian/.resource
/instmnt/debian/.finderinfo
/instmnt/debian/
Only the last choice is the real directory, the other two are representations
for the resource fork and finder data of MacOS.
6.13:
- I hope the bug with the 'not connected to a network' has been fixed
(resolv.conf and other netconfig files not created) ?? Otherwise I suggest
to recommend always to run the full network config by answering 'yes'
there.
6.14:
- selection of path to base archive needs special magic like for kernel
and modules on Mac.
6.16:
- Makes no sense for m68k, except maybe for VME. Amiga LILO is not available
as a Debian package IIRC, it's used by a number of people and should
be stable for all I know, but it's not packaged. (neither is amiboot...)
Atari LILO is a recent development, Roman should comment on that; I've not
tried it yet. May be packaged with ataboot ...
Mac can only be booted by a MacOS application (Penguin), recently even as
INIT (system extension that runs early at boot). Configuration of the
INIT is impossible from Linux so far (involves editing MacOS preferences
files which have data in the resource fork, HFS doesn't use or manipulate
the resource fork).
6:17:
- for reasons described above (6.1) boot floppies make little or no sense
except on Atari.
7:
- should be not much different than the present Intel one :-)
8.2:
- Mac has a MacOS floppy option for those without PCAccess.
8.3:
- SCSI or IDE disk support sure is nice to have, too. Floppy isn't important
except for Atari. And the modules should be someplace handy. Loopback
support required to get the modules out of drv1440.bin.
8.4:
- relevant for Atari only. Others might need to cat the floppy images; if
there's a way to do that from the rescue disk, please share.
Reply to: