removing packman package
Larson, Timothy E.
Thanks,
Tim
--
Tim Larson
App Admin, Intercall Production Services
Erik van der Kouwe
Re-install your system, then install the packages you wanted to
retain. Be sure to store all data you care about in /home, since that
is on a subpartition that does not get wiped on a re-install (and, as
always, preferably also have a backup elsewhere).
With kind regards,
Erik
Larson, Timothy E.
> retain. Be sure to store all data you care about in /home, since
> that
> is on a subpartition that does not get wiped on a re-install (and,
> as
> always, preferably also have a backup elsewhere).
D'oh.... :( I guess this is just that much more incentive to get pkgsrc ported.
Alen Stojanov
Larson, Timothy E.
Toward that end, is there an equivalent to other systems' ar.h somewhere? BSD make assumes definition of ARMAG and friends...
Erik van der Kouwe
> Toward that end, is there an equivalent to other systems' ar.h somewhere? BSD make assumes definition of ARMAG and friends...
BSD make should not be a problem, it has not only been added to the base
system but has even replaced the old MINIX make.
With kind regards,
Erik
Larson, Timothy E.
> base
> system but has even replaced the old MINIX make.
Well, then, this is very curious. The first step of building pkgsrc is to build a bmake that is known to work with it. Using the native make (in 3.1.5) it considers an "all" target to be up-to-date, even though none of the dependencies even exist yet. When I specify using gmake, I get further, but build dies when ARMAG definition doesn't exist (as mentioned).
If native make IS the BSD make, I think I ought to be able to tell it so, and thus skip the step. I've never tried bootstrapping pkgsrc on a system with BSD tools though. (NetBSD doesn't require bootstrapping - everything needed is in the base system.) OTOH, if /usr/bin/make is BSD make, why the strange error? One would think it would work in that case.
Thanks,
Erik van der Kouwe
> (in 3.1.5)
This is a pretty old version, you should upgrade to 3.1.7. There is no
release yet, but I have a recent image at
http://www.cs.vu.nl/~vdkouwe/minix3_1_7_ide_r6433.iso.bz2
With kind regards,
Erik
Larson, Timothy E.
>
> This is a pretty old version, you should upgrade to 3.1.7. There is
> no
> release yet, but I have a recent image at
> http://www.cs.vu.nl/~vdkouwe/minix3_1_7_ide_r6433.iso.bz2
Wow...development must move pretty fast if my image from less than 3 months ago is already considered old! :) I'm used to a 0.0.x difference not being that big a deal.
I think I'm going to stick with 3.1.5 until I believe I have a pkgsrc process that seems workable. Then, wiping and upgrading to whatever is current, and verifying the process on a clean system, would be helpful. Unless there's some kind of serious roadblock to this port effort that requires an upgrade sooner.
Erik van der Kouwe
ATM 3.1.6 is the stable release, so anything before that is considered old.
The reason for the recommendation is that, if someone makes changes to
MINIX, they are much easier to merge in if they were working on a
version close to trunk. There are many crosscutting changes these days
(build system and the restartability framework spring to mind) that make
one's life hard unless one stays up to date with trunk.
With kind regards,
Erik
Antoine Leca
>> BSD make should not be a problem, it has not only been added to the
>> base system but has even replaced the old MINIX make.
>
> Well, then, this is very curious. The first step of building pkgsrc
> is to build a bmake that is known to work with it.
Only if the current make do not comply. Present Minix (-current, trunk)
does comply (or at least it should).
> Using the native make (in 3.1.5) it considers an "all" target to
> be up-to-date, even though none of the dependencies even exist yet.
Yes. This is because, under the old make, you had to do "make depend" to
actually activate the dependencies graph, it was not automatic.
Because of that, and other reasons, Arun Thomas did a great work here
(thanks Arun) and ported (and is porting) the BSD make infrastruture to
Minix. You should make you a favour and upgrade to -current, if you want
to use a more modern make.
And since tracking -current from 3.1.5 is quite difficult, you better
should follow Erik's advice and install directly from the image it
published.
> When I specify using gmake, I get further, but build dies when
> ARMAG definition doesn't exist (as mentioned).
It is probably SARMAG which it is seeking really. Does not matter.
Furthermore, I guess pkgsrc will not accomodate easily ACK... <g>
This happens because pkgsrc assumes ar.h is present; there are much more
assumptions on this kind; and these are the reasons why pkgsrc is not
yet ported: there is no free cake!
Antoine
Larson, Timothy E.
> > be up-to-date, even though none of the dependencies even exist yet.
>
> Yes. This is because, under the old make, you had to do "make depend"
> to
> actually activate the dependencies graph, it was not automatic.
>
> Because of that, and other reasons, Arun Thomas did a great work here
> (thanks Arun) and ported (and is porting) the BSD make infrastruture to
> Minix. You should make you a favour and upgrade to -current, if you
> want
> to use a more modern make.
Ahh, so inclusion of BSD make is a change that's happened since 3.1.5. Good to know! Did this happen in 3.1.6, or in -current? Once this is done, I'll have to report minimum version it is expected to work with.
> > When I specify using gmake, I get further, but build dies when
> > ARMAG definition doesn't exist (as mentioned).
>
> It is probably SARMAG which it is seeking really. Does not matter.
> Furthermore, I guess pkgsrc will not accomodate easily ACK... <g>
>
> This happens because pkgsrc assumes ar.h is present; there are much
> more
> assumptions on this kind; and these are the reasons why pkgsrc is not
> yet ported: there is no free cake!
Precisely. So I need to find where Minix keeps the corresponding definitions and functionality, if it does at all, and figure out a way to supply them (or work around the need for them) if it does not.
Tim
Antoine Leca
> Ahh, so inclusion of BSD make is a change that's happened since
> 3.1.5. Good to know!
Yes.
> Did this happen in 3.1.6, or in -current?
There is no clear-cut answer. Formally, it was introduced (as bmake,
alongsides the old make) in revision 6080; then in revision 6188 old
make was deprecated and the BSD variant became the "official" make...
but since then, there have been at least 2 more revisions to have more
parts of the tree to be build without problems with the new tool.
Since 3.1.6 is rev. 6093, you have it as an integral part, but it is
much less useful than are revisions later than 6188.
> Once this is done, I'll have to report minimum version it is expected
> to work with.
By the way, there is no special magic here, just have a look at
https://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=%2Ftrunk%2Fsrc
Everything is described there!
> So I need to find where Minix keeps the corresponding definitions and
> functionality, if it does at all,
Sorry, I cannot parse this. What are you after?
Ar format? for ACK, ar(1) tells you it's an alias for aal(1), then
src/commands/aal have the details, and arch.h is the close correspondant
to BSD's ar.h; if you prefer the GNU toolchain, the details are within
bigports/binutils-2.{16.1,20} in binutils/ar* (or on the 'net ;-) .)
As you see, nowadays we have two toolchains (and there are more to come)
and this is something most packages are not prepared to handle!
The most obvious example is autoconf+libtool, where the only way (that
I know) to build two sets of libraries is to do:
configure OPTION1 && make && make install
make distclean
configure OPTION2 && make && make install
Not really clean IMHO. And it definitively does not scale well.
> and figure out a way to supply them (or work around the need for them)
> if it does not.
This is another task, and it has to do with NetBSD's pkgsrc. Sorry,
I cannot help you much here; I am trying to use it (with Minix and
Interix, with the second supposedly already ported), and I find it a bit
difficult, so I realize this is not easy.
Antoine
Larson, Timothy E.
> > 3.1.5. Good to know!
>
> Yes.
In short, it definitely looks like I'd be in a much better place upgrading my Minix installation. Seems many of the problems I'm trying to work through right now have already been solved.
Looks like I'll be temporarily moving my HD back to a machine with a CD drive soon. Any chance an easier upgrade procedure is in the works?
Larson, Timothy E.
> no
> release yet, but I have a recent image at
> http://www.cs.vu.nl/~vdkouwe/minix3_1_7_ide_r6433.iso.bz2
Thank you. Do you produce these snapshot builds periodically? If so, having them in a browseable directory would be helpful.
Erik van der Kouwe
>> This is a pretty old version, you should upgrade to 3.1.7. There is
>> no
>> release yet, but I have a recent image at
>> http://www.cs.vu.nl/~vdkouwe/minix3_1_7_ide_r6433.iso.bz2
>
> Thank you. Do you produce these snapshot builds periodically? If so, having them in a browseable directory would be helpful.
No, I only make them occasionally, generally when I think someone from
the newsgroup could use them. They typically don't remain in my web
directory for a long time, as it is limited in space.
I've heard of plans to produce snapshots more regularly on the main
site, but I don't know how much progress has been made there.
With kind regards,
Erik
Erik van der Kouwe
> Looks like I'll be temporarily moving my HD back to a machine with a CD drive soon. Any chance an easier upgrade procedure is in the works?
One (somewhat risky) procedure is to use QEMU or KVM. For example when
running QEMU in Linux, one could do:
sudo qemu -hda /dev/sda -cdrom minix-cd-image.iso -boot d
This way one can install MINIX without ever needing a CD-ROM, which is
very convenient. However, make sure that you know what you're doing, be
very careful and back up everything that is valuable. Don't ever touch a
partition in the guest that is mounted by the host (and vice versa).
Also resist the temptation to ever mount MINIX partitions in Linux,
their FS driver is broken. It sometimes reads incorrect data and
corrupts filesystems when writing.
With kind regards,
Erik
Antoine Leca
> In short, it definitely looks like I'd be in a much better place
> upgrading my Minix installation. Seems many of the problems
> I'm trying to work through right now have already been solved.
I think. Plus, if you find something worth fixing, doing a bug report
_with_a_suitable_patch_ is as easy as using
svn diff > my_proposal_for_a_fix.patch
This way, there is a chance the patch will be picked up by the guys at
VU and incorporated back in the trunk!
> Any chance an easier upgrade procedure is in the works?
Well, unless you are only a few revision away from trunk, using a CD is
WAY more easy than any other upgrade procedures I have seen or thought!
Doing it Erik's way (virtualizing) is conceptually the same thing, it
saves burning the CD and is the only option if there are no
Minix-readable CD in sight (netbook, USB CD), but you have to run the
risk of an accident against the rest of your hard disk. As he said,
"make sure that you know what you're doing."
Antoine
Larson, Timothy E.
> >
> > Thank you. Do you produce these snapshot builds periodically? If
> so, having them in a browseable directory would be helpful.
>
> No, I only make them occasionally, generally when I think someone
> from
> the newsgroup could use them. They typically don't remain in my web
> directory for a long time, as it is limited in space.
>
> I've heard of plans to produce snapshots more regularly on the main
> site, but I don't know how much progress has been made there.
Couldn't you put your snapshots on the main site, until a more regular system is developed?
> One (somewhat risky) procedure is to use QEMU or KVM. For example
> when
> running QEMU in Linux, one could do:
>
> sudo qemu -hda /dev/sda -cdrom minix-cd-image.iso -boot d
>
> This way one can install MINIX without ever needing a CD-ROM, which
> is
> very convenient. However, make sure that you know what you're doing,
> be
> very careful and back up everything that is valuable. Don't ever
Simplistic upgrader script idea:
*Install base 3.1.7 system.
*tar -c /minix3.1.7.tar /
*tar -t /minix3.1.7.tar > /etc/minix3.1.7.contents
*rm /minix3.1.7.tar
*tar -c /minix3.1.7.tar /
*Distribute this version containing the contents file. People install it. Great fun.
*Time goes by...
*Install base 3.1.8 system.
*tar -c /minix3.1.8.tar /
*tar -t /minix3.1.8.tar > /etc/minix3.1.8.contents
*rm /minix3.1.8.tar
*tar -c /minix3.1.8.tar /
*Then distribute this version, which also has a contents file.
*Now we can compare contents of releases with a script:
**cd /
**Find highest /etc/minixX.Y.Z.contents file.
**tar -x minix3.1.8.tar /etc/minix3.1.8.contents
**diff /etc/minixX.Y.Z.contents /etc/minix3.1.8.contents > /tmp/minix3.1.8/contents.diff
**tar -x minix3.1.8.tar /bin /boot /dev /lib /mnt /root /sbin /tmp /usr /var
**For every line in /etc/minix3.1.8.contents, if it matches "^etc", move the existing file to /tmp/minix3.1.8, extract the new file, diff the two and save it in /tmp/minix3.1.8/possible/path/filename.diff, delete the old one from /tmp/minix3.1.8 dir.
*Now, hopefully, you have a 3.1.8 system, albeit possibly with a few lingering files from the older system.
*Lastly, you can manually inspect the /tmp/minix3.1.8/*diff files for files that disappeared, or changes you need to merge in. This could be automated at some point, allowing interactive merging of diffs within the script, and asking if the old files should be removed.
This is all pseudocode, and not tested. Feel free to take shots at it-I wouldn't be surprised if I've missed something obvious. :) If you think this sounds reminiscent of NetBSD's procedure, you'd be right. Contents files could be created retroactively, if someone wanted to do so, allowing the script to work for people upgrading from <= 3.1.6 too.
Erik van der Kouwe
>> No, I only make them occasionally, generally when I think someone
>> from
>> the newsgroup could use them. They typically don't remain in my web
>> directory for a long time, as it is limited in space.
>>
>> I've heard of plans to produce snapshots more regularly on the main
>> site, but I don't know how much progress has been made there.
>
> Couldn't you put your snapshots on the main site, until a more regular system is developed?
...
> Simplistic upgrader script idea:
It is more convenient to put on my own website and provide a link here;
there will be snapshots once a systematic approach has been developed.
Having snapshots is nice, but there are many things having higher
priority. A CD image (or other update procedure) is only needed for the
big upgrades, the regular updates are done using SVN (see
http://wiki.minix3.org/en/DevelopersGuide/TrackingCurrent).
With kind regards,
Erik
Larson, Timothy E.
> priority. A CD image (or other update procedure) is only needed for
> the
> big upgrades, the regular updates are done using SVN (see
> http://wiki.minix3.org/en/DevelopersGuide/TrackingCurrent).
Oh well, I'd hoped to focus on my software porting and not have to spend cycles on Minix itself, but it is looking more and more unavoidable at this stage. Guess I might as well take the plunge! :)
Erik van der Kouwe
>> Having snapshots is nice, but there are many things having higher
>> priority. A CD image (or other update procedure) is only needed for
>> the
>> big upgrades, the regular updates are done using SVN (see
>> http://wiki.minix3.org/en/DevelopersGuide/TrackingCurrent).
>
> Oh well, I'd hoped to focus on my software porting and not have to spend cycles on Minix itself, but it is looking more and more unavoidable at this stage. Guess I might as well take the plunge! :)
I think keeping up to date using SVN is generally easier that performing
an update as you described. This is especially the case if you modify
the source tree yourself, since SVN merges the changes and allows you to
resolve conflicts.
Once you executed the steps on the Wiki page, most of the time you'll
only need to "cd /usr/src; svn update; make world" to update (in those
other cases you'll need to check docs/UPDATING and follow instructions
there).
With kind regards,
Erik
Larson, Timothy E.
> spend cycles on Minix itself, but it is looking more and more
> unavoidable at this stage. Guess I might as well take the plunge!
> :)
Plunge was more like a belly-flop. :D "make world" did not work (as I expected), so I followed the procedure to build BSD make.
cc -g -Wall -DHAVE_SETENV -DHAVE_STRERROR -DHAVE_STRDUP -DHAVE_STRFTIME -DHAVE_VSNPRINTF -DUSE_SELECT -D_POSIX_SOURCE -D_MINIX -DTARGET_MACHINE=\"i386\" \
-DTARGET_MACHINE_ARCH=\"i386\" \
-DMAKE_MACHINE=\"i386\" -c arch.c -o arch.o
"arch.c", line 138: cannot open include file "ar.h"
"arch.c", line 400: MAXPATHLEN undefined
"arch.c", line 531: SARMAG undefined
"arch.c", line 531: (strict) array size is 0
"arch.c", line 535: unknown struct-type
"arch.c", line 535: size of local arh unknown
"arch.c", line 536: MAXPATHLEN undefined
"arch.c", line 560: unknown selector ar_name
[snip]
"arch.c", line 1088: illegal use of selector ar_date
make in /usr/src/commands/make: Exit code 1
These are the same things I was seeing when working with the pkgsrc version, because of missing headers and definitions. I assume the "cd include && make includes" step of make world would have put the new headers in place, but without BSD make to put them there, I'm not able to build it. Heh.
It looks to me as if I can just copy the include directory over manually. But when I tried, I got:
"/usr/include/minix/type.h", line 196: NR_IRQ_VECTORS undefined
Erik van der Kouwe
Are you trying to upgrade using SVN straight from MINIX 3.1.5? That's
probably a bit too much difference. I'd recommend you install 3.1.6 or
3.1.7 and track trunk afterwards. Don't forget to read docs/UPDATING.
With kind regards,
Erik
Larson, Timothy E.
> That's
> probably a bit too much difference. I'd recommend you install 3.1.6
> or
> 3.1.7 and track trunk afterwards. Don't forget to read
> docs/UPDATING.
Tried checking out 3.1.6 and building that, but reboot panics in SEF. Guess I'll be moving my HD after all. Fetching your 6433 snapshot now.
Larson, Timothy E.
> Guess I'll be moving my HD after all. Fetching your 6433 snapshot now.
CD is good, because my laptop will boot from it. But I cannot get any of the three i386 desktops I have to boot from it, even if I use the boot floppy. Even borrowed a CD drive from a fourth machine to try that. When it doesn't boot the CD, it sits at a blinking cursor. When I try the floppy, I get as far as "Boot medium driver: AT driver mapped onto controller c0." before it stops.
Dagnabbit...now I'm stuck.
Tim
Erik van der Kouwe
>> Tried checking out 3.1.6 and building that, but reboot panics in SEF.
>> Guess I'll be moving my HD after all. Fetching your 6433 snapshot now.
>
> CD is good, because my laptop will boot from it. But I cannot get any of the three i386 desktops I have to boot from it, even if I use the boot floppy. Even borrowed a CD drive from a fourth machine to try that. When it doesn't boot the CD, it sits at a blinking cursor. When I try the floppy, I get as far as "Boot medium driver: AT driver mapped onto controller c0." before it stops.
That's weird, at the VU we never have problems booting on the bare
hardware, yet there have been a couple of reports here the last few
months. Could you provide us with some hardware details about the
machines you're using? Maybe we can find a similar box here and see
where it fails.
The best way to debug booting problems is using a serial null-modem
cable BTW, so if you have one of those lying around you could give that
try. A first step would hen be to cut off the boot at the boot menu by
pressing escape, then typing "verbose=2", "ctty 0" and "boot".
With kind regards,
Erik
AntoineLeca
> When I try the floppy, I get as far as "Boot medium driver: AT driver mapped
> onto controller c0." before it stops.
Are you using AHCI command set? If yes, disable it and stick with IDE
(Legacy).
@Erik or Tom: we really should implement some test to detect AHCI
devices (with PCI: it is a class disitinct from ATA=IDE), and emit at
least some warning...
Antoine
Larson, Timothy E.
> hardware, yet there have been a couple of reports here the last few
> months. Could you provide us with some hardware details about the
> machines you're using? Maybe we can find a similar box here and see
> where it fails.
Dell GX1
Dell GX60 - small form factor
Dell GX260 - small form factor
I can get you dmesg from the GX1 and GX260 under their normal OSs, if that would help. Let me know what details you're looking for. The GX60 is my regular (CD-less) Minix machine. I tried the CD drive from the GX1 and another machine in it, as well.
Today over lunch I have a Dell 760 I can try, but I think that's my last shot.
Evgeniy Ivanov
Probably it's the same issue as this one:
http://groups.google.com/group/minix3/browse_thread/thread/d702d03a4a425d05/df87f56d54a0321f?lnk=raot#df87f56d54a0321f
Serial output is available there.
--
Evgeniy Ivanov
Antoine Leca
>> That's weird, at the VU we never have problems booting on the bare
>> hardware, yet there have been a couple of reports here the last few
>> months. Could you provide us with some hardware details about the
>> machines you're using? Maybe we can find a similar box here and see
>> where it fails.
>
> Dell GX1
> Dell GX60 - small form factor
> Dell GX260 - small form factor
Well, something pretty weird is occurring...
I have several Dell's available here. 3.1.5 boots smoothelessly from all
the ones I tested, that is, unless the CD drive is brocken :+)
However, *none* of them booted 3.1.6 rev. 6084 (with the new starting
method using "no emulation mode", introduced in revision 5918.)
Tested until now:
GX260
GX270
Dimension C521 (with AMD cpu!)
Vostro 200 and 220
The same CD boots OK from an old Compaq, and I believe it worked OK for
a Intel Atom-based motherboard.
This definitively looks like an issue with El-Torito stuff and its
conformance; particularly since the GX*'s use Phoenix BIOSes, while the
C521 has an Award and Vostro have AMI...
Antoine
Larson, Timothy E.
> Dell GX60 - small form factor
> Dell GX260 - small form factor
>
> I can get you dmesg from the GX1 and GX260 under their normal OSs,
> if that would help. Let me know what details you're looking for.
> The GX60 is my regular (CD-less) Minix machine. I tried the CD
> drive from the GX1 and another machine in it, as well.
>
> Today over lunch I have a Dell 760 I can try, but I think that's my
> last shot.
Have not tried the 760 yet (working through lunch today, so I can't pop it open and play with it), but I thought I would add that my Dell Latitude D630 boots from the r6433 CD just fine.
Larson, Timothy E.
> starting
> method using "no emulation mode", introduced in revision 5918.)
>
> for
> a Intel Atom-based motherboard.
>
> This definitively looks like an issue with El-Torito stuff and its
> conformance; particularly since the GX*'s use Phoenix BIOSes, while
> the
> C521 has an Award and Vostro have AMI...
What can be done about this?
Antoine Leca
>> [Dell's] *none* of them booted 3.1.6 rev. 6084 (with the new
>> starting method using "no emulation mode", introduced in
>> revision 5918.)
>>
>> conformance;
>
I do not understand your question. Do you expect an answer like
"Fight that bug" ?
Antoine
Erik van der Kouwe
> I have several Dell's available here. 3.1.5 boots smoothelessly from all
> the ones I tested, that is, unless the CD drive is brocken :+)
>
> However, *none* of them booted 3.1.6 rev. 6084 (with the new starting
> method using "no emulation mode", introduced in revision 5918.)
>
> Tested until now:
> GX260
> GX270
> Dimension C521 (with AMD cpu!)
> Vostro 200 and 220
>
>
> The same CD boots OK from an old Compaq, and I believe it worked OK for
> a Intel Atom-based motherboard.
>
> This definitively looks like an issue with El-Torito stuff and its
> conformance; particularly since the GX*'s use Phoenix BIOSes, while the
> C521 has an Award and Vostro have AMI...
That is a sensible explanation, I think it will be hard to debug though.
Thanks a lot (also to Timothy) for your help on this one.
With kind regards,
Erik
Antoine Leca
>> This definitively looks like an issue with El-Torito stuff and its
>> conformance; particularly since the GX*'s use Phoenix BIOSes, while the
>> C521 has an Award and Vostro have AMI...
>
> That is a sensible explanation, I think it will be hard to debug though.
You mean, it would be hard to debug several 4-10-year old BIOSes and
make them fully conformant to El Torito specs? Yes, certainly very
difficult to do :-)
On the other hand, we can implement workarounds... Judging from earlier
discussions in both "Bart's PEs" and similar "emergency" CDs (the
introduction of http://www.nu2.nu/bootcd/ have a good resume), and about
IsoLinux [from SysLinux fame], it appears that many BIOSes fail to fully
conform, but most are able, in "no-emulation" mode, to load one 2-KB
sector at the standard place.
If I remember correctly the results of IsoLinux discussions, the
workaround there was to have that first sector to (eventually) load the
rest of the bootstraping code: however, it is something which makes much
sense in IsoLinux case, because it is much like the way SysLinux boots
itself off a FAT file system, but might not be proper of another project.
Back to the bases, in Minix case, the boot process works as follows:
- at the end of BIOS phase, IPL (initial process load) loads one
512-byte sector at 0000:7C00, and jumps to it
- in Minix case, the code is from bootblock.s, which loads at
1000:0000 a bunch of sectors which addresses(normally the content
of boot/boot) are hard-coded into the sector, then jumps to 1000:0030
(over the 16 bytes prefix added in rev. 5918 and the 32-byte a.out
header, assuming short form)
- boothead.s is entered at the beginning, and immediately jumps to
1003:0025, setting BX to 0
- then boot is at command.
In the new stuff for CD booting, if I understand correctly despite the
lack of documentation and only superficially looking at release.sh and
writeisofs.c, the El Torito specs are used in no-emulation mode, which
boils down to the CD instructing the BIOS to load at 1000:0000, from CD
sector 0x14, about 0x3E (62) 512-byte sectors of the prefixed,
unstripped boot/boot (which is, according the header, 31.09 KB long).
Then the processs looks like:
- at the end of BIOS phase, IPL (initial process load) loads several
(15? 16? only one?) 2048-byte sector at 1000:0000 (unless bugged BIOS
with hardwired 07C0:0), and jumps to it
- in Minix case, the code in the 16-byte prefix header does a forward
jump to 1000:0040 (over the a.out header)
- boothead.s is entered at the second entry point, and immediately
jumps to 1003:0020, setting BX to 1
- then boot is at command.
As you notice, there are several pitfalls meanwhile.
The fact the loaded file is truncated is not an actual problem because
it only affects to the unstripped boot[exec], so it only drops part of
the symbol table; however there is a genuine bug asleep here (but I did
not find it, the code is writeisofs.c!writebootimage appears to
correctly manage that case, it even takes care of rounding _up_ to an
integer number of _2048_-byte sectors, in order to avoid possible errors
of the 15-or-16 kind I mentionned above...)
Still, we have two possible problems which are inherently linked to the
method used here:
- one is to assume the BIOS will correctly load boot at the requested
segment position (1000 in Minix case), instead of the "standard" 0x07C0
- the other is to assume the BIOS will correctly load the requested
number of CD sectors (and here I know some faulty BIOSes do not.)
I assert Dell's BIOSes suffer from at least one of those. Of course I
can be wrong!
I believe a possible although overkill workaround can be to restore the
same number of steps as we use in normal boot, following a scheme along
the lines of:
- insert another entry in the CD001 catalog, pointing to BOOT
- at the end of BIOS phase, based on El-Torito informations, IPL loads
one 2048-byte sector at 07C0:0000, and jumps to it
- *new* code is invoked (say, cdboot.s), which reads catalogs etc.
from the CD, then loads at 1000:0000 the content of BOOT,
then jumps to 1000:0030 (exact same address as bootblock.s), or
alternatively 1000:0040 or whatever (if we want boot to be able to
discriminate the CD case from the FD/HD one, or future PXE or EFI)
and the rest would be the same steps as done in the last 20 years...
(we could even erase the 16-byte prefix, which I personaly find to be
pretty ugly; however now this is just my humble opinion here ;-) )
Another, alternative, way could be to have the code in boothead.s to
check if it was (wrongly) loaded at 07C0 and then relocate itself;
similarly, we could have some code which checks if only 2048 byte were
loaded, and if not which would load the rest from the CD (this also
requires the mini-ISO image to have an entry for BOOT.)
A third, completely different approach, could be to use hard-drive
emulation instead. Then there are no 1.4 MB limit (which was the
blocking factor in the first place). Of course, the bad thing is we have
to "waste" as much memory as the size of the harddisk image loaded (16MB
these days); and since this kind of emulation is *not* the most used
(read, the one used with Windows and Linux), there is an important
possibility it does _not_ work everywhere either.
Antoine