... I think I've got it working now though. But it seems overall to have been a rather more painful experience than I had installing 7.1 on the same machines. Firstly, I installed it on my ageing Pico Consul laptop. That went off without a hitch, ironically enough. Then today I installed it on a new Athlon 1.33 / Via KT133A system. Now, although I had a fairly clean SuSE 7.1 system on there, I've got into the habit of always installing from scratch rather than performing upgrades. It's just my way, I don't trust upgrading, I've seen some pretty insane machines that are the result of that, and anyway it gives me a chance to spring-clean. So... The first problem is that Yast2 wouldn't recognise the mouse. It's a Logitech Pilot Wheel Mouse plugged in via USB. SuSE 7.1 not only worked with it, but installed right out of the box with it. However, with SuSE 7.2, it just wouldn't see it. I dug out the adapter to plug it into the PS/2 port instead, rebooted etc., but it still wouldn't see the mouse. So for a bit I tried to continue anyway with Yast2 using the keyboard. This progressed until I asked it I wanted to use the whole disk (as partitioned by SuSE 7.1). This as you know selects all the partitions on the disk for deletion. Only Yast2 insisted that these partitions were not contiguous and so refused to go any further. So I installed using Yast1. This more or less went off without a hitch, while nevertheless being a reminder of more primitive times :-). The most annoying thing here was that it asked me to configure gpm before having started the USB manager service, so of course it still wouldn't see my USB mouse. So, let it finish and do it then, no problems. sax2 configured X (with the USB mouse) no problems. This is in contrast to my laptop where I had no end of problems getting sax2 to run itself on my S3Virge-MX+. "sax2 -m 0=vga" did it in the end. I got some minor screen corruption on the framebuffer console with my Voodoo 3 card, but thought little of it. It seems to take a long time to switch VC from the console to X when framebuffer console is enabled. Minor gripes: Yast2 doesn't show package version numbers Yast1 doesn't any longer show package file lists. Why do SuSE have the X and KDE2 upgrades separate from the main updates directory? I'd love to just point YOU at it and go, but as it is, I have to use Yast1 and pick them out from all over. Further problems are nothing to do with SuSE: I was building my own kernel from vanilla-2.4.5 so I can have it built for Athlon rather than Pentium and cut out a lot of the irrelevant stuff This is all basically OK, I'm now used to the various things I need to make sure I'm doing to keep the SuSE scripts etc. happy (build this and that as a module, that sort of thing). My problems continued to be with the framebuffer console. Firstly, I compiled in the specific 3dfx/Voodoo3 fbdev support, but that didn't work at all - didn't crash, just didn't show anything until kdm started. Recompiled with that out, and just VESA fb support in, and it seemed at first to be fine, but then I started to see the same sort of display corruption I'd seen briefly on the SuSE kernel. (I may have been optimistic to tell it to use VESA mode 795 (1280x1024x24bit)) Then it got markedly worse and wouldn't even switch to X properly - basically I think the Voodoo3 card itself crashed - the machine was fine, I could log on and recover and reboot from the laptop. Rebuild the kernel again with no framebuffer console support at all, and put "vga=normal" in /etc/lilo.conf and sanity is restored. (Though I quite *like* having big consoles from time to time.) So I think there are some Issues regarding using Framebuffer Console on the Voodoo3 card. Conversely, this also works fine on my laptop, set rather more conservatively to VESA mode 773 (1024x768x8bit). In fact, as the laptop has a propensity to crash when in VGA text mode (never in X which leads me to suspect dodgy BIOS issues), I specifically wanted to try fb-console. I haven't been using it long enough like that yet to know if it works. -- Rachel