On Fri, Jul 14, 2000 at 08:07:44PM +0200, Anne POSSOZ wrote:
> mount -o loop -t ext2 .../update-disk-20000419.img /mnt/update
> cd .../RedHat/instimage/usr/lib/anaconda
> cp -a /mnt/update/* .
I copy the contents to misc/src/anaconda. From there, I type "make
install" (which recompiles stuff and copies it to RedHat/instimage),
followed by a "make clean" (to avoid keeping in misc/src/anaconda the
.pyc/.o/.so files, which are never used during installation anyway; CD
space is very precious).
>
> 1) update for sources
> .....................
> For misc/src/ there is no update.
I *suppose* there is, at least to some extent. Just try the above. I have
to admit that this was a guess of mine, based on no form whatsoever of
documentation, but so far it seems to work here. ;)
> This can be a problem if we find a bug, for example in the loader.
> The loader in initrd.img on bootnet-20000407.img has changed but
> we do not have the corresponding source files.
What has changed is that you can now use anaconda update disks. As far as
I can tell, if you merge the sources from the update disk, there's no
need for the update disk itself anymore. ;) And thus, you can still use
the old loader (I do). Of course if new problems were to surface, it
would be necessary to have the sources for the loader.
> The patch for this file is in attachment.
> (although I suspect that, if we patch the nfs server for the instimage/
> this file can stay empty and it is necessary only when using
> phisically the update diskette)
Thanks for the patch.
I found a few more problems with anaconda and kickstart files. It took me
a whole day to figure them out, also because I had never programmed in
Python before. ;)
First of all, as soon as I managed to find how to run anaconda in test
mode (which is not THAT much helpful, anyway), I noticed that the
kickstart was being removed every time I ran the installer! Line 308 of
anaconda says "os.unlink(kickstart)"; I wonder why?!?
Then, if I passed the exact name of a card to "xconfig" in the kickstart
file, I'd get an error at line 174 of file xf86config.py, which says
'self.devID = self.vidCards[self.primary]["NAME"]'. As far as I can tell,
that's trying to access key NAME in the array of associative arrays
vidCards at position self.primary (which equals to 0). The problem is
that vidCards is set, a few lines before, to a string (the parameter
"card"). I solved this by replacing "self.vidCards = [card]" with
"self.vidCards = self.cards (card)" (method "cards" returns an
associative array matching the string it is passed). I had still
problems, though, because vidCards is still NOT an array of arrays. It
looks to me as if the code in method "cards" is quite ambiguous, as it
can return a single array or the whole card database (look at the two
statements at the very end of it, "return card" and "return cards"). I'm
not a Python expert, so I can't really tell how this should be fixed.
I've found, though, that removing "[self.primary]" is enough here.
Last but not least, the one problem that took me a whole afternoon and
night to master (I learnt how Python and its debugger work, in the
meantime). If a mouse type is not selected in the kickstart file, I get a
nasty error message when anaconda is trying to write the XF86Config file.
In xf86config.mouseSection, if self.mouse is not set, it gets set to
Mouse(mousetype=("none", "none", "null")). In mouse.py that triggers (at
line 93) a call to mouse.set, with the same parameters. The problem is
that set has a different argument signature!
That still shouldn't occur, because during the installation anaconda asks
which kind of mouse is attached to the computer. So, the self.mouse test
should not fail in the first place.
I eventually tracked this down to line 852 of todo.py, which says "if
(todo.instClass.mouse):". todo.instclass has no "mouse" attribute,
because it is the Kickstart object (and I had specified no "mouse"
statement in the ks file). On the other hand, todo itself has a
"mouse" attribute, which is set according to what the user says. All I
did was to add an elif statement at line 856:
elif (todo.mouse):
todo.x.setMouse(todo.mouse)
which seems to work here (I'm reburning a CD for the umpteenth time to
test it). That might or might not cause problems if one chooses not to
install X at all (I can't tell, I don't feel that much familiar with how
anaconda really works). Though the same could be said of the code in the
"if" statement right before it...
> I am still unable to figure out why the ks=cdrom:/ks.cfg option
> is not working but I have no real way to debug it without the
> source of the used loader.
In my experience you need to specify that manually at the lilo prompt OR
build custom boot images. I do the latter this way:
* edit misc/src/trees/boot/syslinux.cfg. In the entry "label linux", add
"ks=cdrom:/ks.cfg" to the "append" command.
* change directory to misc/src/trees
* run "make"
* run "do-make"
The last two steps are highly CPU- and disk-intensive, so I suggest you
try the procedure on the fastest machine you can get your hands on. As a
nice bonus, you get the boot images to use an updated kernel (if you
bothered replacing the kernel RPMs on the CD, of course). On some setups
this comes quite handy. Watch out for any error messages about running
out of space, though (it can happen, especially with bootnet.img).
Apparently the scripts just ignore errors, instead of halting execution!
Of course, again, you should try the above at your own risk; I do not
make any warranties it will work for you. It's just based on my
experimentations and inspections of source files/scripts/Makefiles and
not on any form of official documentation.
--
"A true zen saying, nothing is what I want" (Frank Zappa)
Rudi Chiarito SGML/XML, user interface, i18n Amiga Inc.
[EMAIL PROTECTED] http://amiga.com/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
