I got some problems (disk access denied, bus errors,...) that led me to
go into single user mode and fsck my partitions. I noticed then that
there were some directories created in the tmp directory, called "dev"
and "etc", and one file in the / directory called "success" with 0
length. At reboot, these files disapeared. Does anybody know if this
could be a sign of a hacked computer ? I mean could someone have
installed a rootkit or some such ?
I'm not paranoid but this indeed seems strange.
| Damir Buskulic | Universite de Savoie/LAPP |
| | Chemin de Bellevue, B.P. 110 |
| Tel : +33 (0)450091600 | F-74941 Annecy-le-Vieux Cedex |
| e-mail: buskulic(a)lapp.in2p3.fr | FRANCE |
I've just installed SLES9 on a IBM 7025 F50 with 2 processors. In
contrast to SLES8 there was no problem during the installation process.
The only problem is that YaST installed default kernel (non SMP). I've
installed the SMP kernel that ships with the distribution, ran mk_initrd
and made the relevant changes to yaboot. However this kernel won't boot
the machine, in fact the boot process aborts before the kernel is loaded
Is there anybody using SLES9 on a F50 with multi processor support?
Is SLES8 supported on Power5 hardware? If not, is
this because it just won't work, or it works but is
not officially supported?
Do you Yahoo!?
Declare Yourself - Register online to vote today!
I would like to install SLES on a G5, but I'm thwarted by a Kernel
panic that happens before I even get to the installer.
I was attempting to load Suse Linux Enterprise Server 9, RC5, on an
Apple Xserve 64. It started to load the kernel, but then panicked
loading PCI drivers. It happens pretty quickly, before the installer
has had a chance to come up, and I never see any boot options.
This is a standard Apple Xserve 64, except that is has a
'non-standard' video card, the MPDDpro
(http://www.villagetronic.com/mpdd/mpddpro_appl.html) This card is
compatible with MacOSX, and works fine with SLES 9 (I can read the
error messages on the monitor), my only reason for thinking it's the
problem is that the stack trace from the kernel panic originated in the
PCI driver loader.