Matthew Winter wrote, somewhere in the digest: >Once the installation was complete, I found that the system did not make >use of the new graphical boot. I assume the installer prefers to keep >the existing config in its entirity. I doubt the installer keeps ALL configs as before when doing an upgrade...i would imagine that it would really depend on what you have editted and what is still a stock file. rpm packages can sense custom config files and can prefer yer custom configs over stock configs. It really depends on what the rpm packager decided the behavior should be. If you had a hand editted config file, rpm packages typically can either leave that config in place and give you the stock config as a backup file, or back up yer custom config and give you a new stock config. Look for files like *.rpmsave *.rpmnew *.rpmold. I always forget which type of backup file corresponds to which behavior. >I then noticed that even though I have only installed possible 4 >additional RPM's ontop of the original RHL 9, I had alot of package >dependency problems ...there is some value in trying to debug upgrade issues that only show up when you are upgrading instead of doing a fresh install. Those however are very tricky, especially dependancy issue with non-redhat rpms that you have installed. I would have thought the installer would throw up some warning messages about unresolved dependances for any installed rpms that you had, even non redhat ones. This is tough to narrow down, unless you can take the time to do repeated upgrades scenarios where you are confident of configuration you started with. If you have been living in rhl9 for a couple months, you could have an extremely personalized setup that other people just might not be able to reproduce similar upgrade bugs...its tough. >Once booted, I attempted to install the NVidia driver, rebuilding the >kernel. This failed as the NVidia driver performs a check of the CC >versions and found that they are compiled using an earlier release. I >assume NVidia will update there drivers when Severn goes into GA. I have good news and bad news for you. First the good news...right now becuase the kernel in the beta is still compiled with gcc3.2 you can in fact compile the nvidia driver...you just have to use the older gcc3.2 and not gcc3.3. In fact, you HAVE to recompile the nvidia driver with the same version of gcc that you compile the kernel with...so use the older Gcc3.2 which still comes in the beta. The bad news is...once it becomes a breeze(cough..cough) to compile the kernel with gcc3.3, i would expect that any subsequent isos that get released for this beta phase might have kernels compiled with gcc 3.3. Once this happens...don't count on the nvidia driver working from that point on..till after the beta phase is over. Nvidia has historically NOT provided any drivers that can be used as part of the redhat beta testing process. The problem is what nvidia gives you is mostly a binary only library, with a small amount of code that you can recompile to work with your kernel. Once the kernel starts being compiled with gcc3.3, the gcc3.2 compiled library/libraries nvidia provides will most likely just not work together. Personally i think you best serve the community if you just use the nv driver while yer beta testing, so that you can file bugreports for it early on, so they can get fixed sooner. For future reference, try not to obliterate a working system that you expect to use with a beta. Whether or not this beta is less buggy or not than previous betas isn't important. Always count on seeing a major show-stopper that no-one else can reproduce, when you are installing a beta release. Beta releases with 1400+ separate packages, will by their very nature,always be a good source of fiber and roughage...in the form of pointy glass shards. Beta releases will also steal your babies and rat you out to the IRS. Just be prepared. And please, make sure you check and post to redhat's bugzilla about any of the rest of these issue. I don't know if anyone can do anything about how applications interact with on-the-fly resolution resizing(during this beta phase at least)...but now that we have the resolution resizing ability, applications need to start thinking about how to deal with it....so file those bugs. I would imagine this is going to be an application by application kind of bug that has to be sent upstream to each of the projects themselves....but someone in the know about desktop development could give a short explanation on where in chain desktop resizing is suppose to be noticed. I doubt its the wm that is suppose to notice, so its either the desktop framework or each individual application. -jef"use a second partition or disk to install the beta if you can, and leave yer rhl9 install intact to play RTCW"spaleta
Attachment:
signature.asc
Description: This is a digitally signed message part