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

Re: m68k boot-floppies

> > Two in parallel ... I obviously never tried this. But the tmp files should
> > have the PID as part of the file name - what are these names like? 
> Hmm, forgot the logfile, its something like /var/tmp/boot-floppies/fwgXbla
> but it seems to be the same in every build, the same file for the same
> loopback mounted image.

That's bad - maybe tmpnam() is broken? 
> > Nope, I'll gladly download the Atari part for a test. I'll even dig out my
> I am copying the stuff to my boot-floppies/2.2.10 directory right now (va).
> A copy is available for ftp at
> Thats what came out of the build, I guess things will be sorted in the
> release subdirectory, when all filenames match with the scripts.

I've downloaded the stuff and a few things strike me as odd:

- resc1440.bin: root.bin is missing. Well, it won't have fit anymore so we
can as well dump the bootargs stuff unless I can find a way to load kernel
and ramdisk from different floppies. 

- drivers-1.bin isn't a MSDOS floppy image, apparently. What is it? (dd to
a floppy doesn't result in anything readable by mtools)

- Loading keymap: the installer fails to find /atari/atari-de.bmp. Small
surprise, it is actually called atari/atari-de.bmap in the tarball.
Manually loading the map went fine so it's not broken as such. 

- The directory layout for the install files is a bit odd. Seems we are
expected to replicate the mirror tree exactly:


is what is looked for. After moving the files into their proper places,
dbootstrap still thinks the install is broken even afer unpacking
everything. This may be due to:

- configure modules: depmod -a as well as modprobe complain that the
modules' owner isn't root. Silly me, I forgot the chown -R root when
building the kernel packages. Can you please add a chown -R root to the
drivers.sh, before the drivers.tgz gets packed up? 

The rest went fine, except for some error message during system init
(while updating locate database or such, user nobody tried su and run
/bin/sh which failed). Odd. The whole apt configuration etc. went smooth
and it seems like this is a definite improvement over slink there. 

The zip drive is full with the base install alone so I'll stop now. I
could repair all of the glitches during install from the shell without a
single reboot. Needs no improvement for all I care :-) 


Reply to: