* Third Time: miboot.floppy results in red X over the little Tux-Icon
in the center of the grey screen, before a potential fb driver from the
kernel takes over
Mmm, what do you mean before a porential fb driver takes over ? Do you think
the kernel is loaded or not ?
From what I experienced the last day I would say he doesn't read in the
whole floppy (although I gave it a lot of trys, also with other disks,
so I would exclude floppy failure, also it works with other images and
the one I built custom)
* 20051029: boot.img cannot work (and it did not), because using hmount
[...] ; hdir you will find out that the miboot environment is missing in
that image, so there is no loader to take the included vmlinuz on it's
back. however, using 20050615 boot.img-floppy + a little plastical
surgery with hfsutils to replace zImage there with the stray vmlinuz you
supply in 20051029 DOES work - so you ought to fix the building process
or whatever.
A look at the build log :
http://people.debian.org/~luther/d-i/images/2005-10-29/build_powerpc_floppy_boot.log
Shows that :
# Since miboot is not in the archive yet, but used for daily builds,
# we test for its existence, and use it if available. If not, we resort
# to some grungy HFS hacking to make believe it is there.
echo READY TO DO MIBOOT ...
READY TO DO MIBOOT ...
if [ -x /usr/bin/miboot ]; then \
echo DOING MIBOOT; \
echo device ./tmp/powerpc_floppy_boot/boot.img.new >
./tmp/powerpc_floppy_boot/miboot.conf; \
echo kernel ./tmp/powerpc_floppy_boot/vmlinux.gz root=0200 load_ramdisk=1
prompt_ramdisk=1 devfs=mount debconf/priority=medium >>
./tmp/powerpc_floppy_boot/miboot.conf; \
miboot -c ./tmp/powerpc_floppy_boot/miboot.conf; \
echo MIBOOT DONE; \
else \
hmount tmp/powerpc_floppy_boot/boot.img.new; \
hcopy -r ./tmp/powerpc_floppy_boot/vmlinux.gz :vmlinuz; \
hattrib -b :; \
humount; \
fi
Mmm, ... investigating, it seems that for some obscure reason miboot was no
more executable, fixed, so tomorrows build should be ok.
Thanks, I'll give them a try. Will the floppy come out when asking for
root.bin?
Joeyh, i think i want to get ride of the else copy, and *NOT* build those
miboot floppies for the official realeses, since they caused more harm than
help for the sarge release.
If a boot floppy without the miboot part would be of any use to someone,
you might as well keep the else branch - as for the official releases,
is it really such a problem to have people test such a disk on some
machines before including it in, say sarge? There is two logical ways
one can go to get something stable, a) don't include it b) test it. I'm
asking this in curiousity, as I really can't imagine - not to piss
someone off. If you decide to include stuff without having done b)
sufficiently, than *please*, at least put a bold README onto those
floppy directorys warning that this is untested, maybe with some
pointers to discussion threads (speaking of the official stable sarge
dist) and bugs that are known about.
unlike the old 2.4 images, or those 2.2 images from woody (which I
obviously can't forget as each newer boot set seems to get worse - or
Please, consider that we are all helping you out of our own free time, and the
last you could do is stay polite and stop denigrating our work without
knowledge of what is going on and such. Also, if you had filed a proper bug
report, like asked on the debian-installer page, instead of random rants, it
would have helped us find the issue earlier.
Please, consider that testing things takes time too and it's also done
on my free time, I did not at all intend to denigrate your work or the
like. In fact I'm using it and I wan't to get it as useful again as it
was, in the points I criticized. I am thankful for what is done and
understand that kernel changes/dist upgrades take time and nerves. It's
frustrating to see how dedicated people work on beautiful stuff that in
the end can't be put to work, since they do not seem to have a little
patience with their testers. Both of our time is put to better use
fixing+testing things than ranting each other. Let us concentrate on
the rational parts.
So, while sending problems to /dev/null might be comfortable, there just
might be more fun in helping each other out.
*minus all the rants*
regards,
Christian
ps: i'll have a look at the debian-installer page
pps: if you decide for /dev/null please let me know, so that I won't
keep sending you mails you won't read
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
