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

Re: hfs boot floppy versions
* 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
Reply to: