pmpatrick

I think it might be kernel related too. Check the output of: # lsmod and see if the ide-cd and cdrom modules are listed.

The error message is normal when you run hdparm on an optical drive. At least, I have the same error message on mine. Try switching dma off and see if you still have read problems on your dvd drive.

Is dma enabled on the drive in gentoo? # hdparm /dev/hdc should tell you if it is. You can try toggling dma on and off and see if it has an effect: # hdparm -d1 /dev/hdc to turn dma on and: # hdparm -d0 /dev/hdc to turn dma off on the drive. However, those error messages sure look like a dirty lens to me. The system accesses the drive but can't read the disk for some reason.

I think that hdlist.cz is a compressed file. Decompressing is a cpu intensive task. On a P1, you will probably peg the cpu usage at 100% doing any type of compression/decompression. Couple that with the slow hard drive I/O on a typical P1 and you probably have your explanation. By way of example, on my old 500MHz P3, creating a gziped tar archive of a few 100MB will completely peg the cpu for several minutes. It would probably take forever on a 166MHz P1.

Check your bios setup and see if the drive is being properly detected. If it's not, for sure you have a hardware problem, i.e. the drive is probably defective or the cabling shot. If the drive is being properly detected by the bios, before going out and buying a new drive you might want to try one of those drive lens cleaner things. You may just have a dirty lens. However, given how cheap dvd drives are these days, you may not want to bother.

This is marked as "solved" so I don't know if any further help is needed. However, the 307 error message probably refers to an inability to find the root filesystem on hda7. hda7 has a major number of 3 and a minor number of 7. When that occurs, it usually means the kernel was not compiled correctly to support the filesytem used in hda7. Try compiling support for the filesystem(ext3, reiserfs, etc) directly in the kernel instead of as a module.

Just to make sure the drive is being properly detected, open a console and run: $ su <enter root password> # fdisk -l and post the output here. That will list all the partitions recognized by your system, whether mounted or not. hdd5 should be shown in mandrake control center. If it's not, something may be wrong. The above output will show for sure. If hdd5 is properly detected, it's pretty easy to setup in fstab. In your konsole, run as root: # mkdir /mnt/hdd5 # kwrite /etc/fstab The first command creates your mount point; the second command opens up fstab in kwrite with root privileges so you can edit the file. Add this line to fstab: /dev/hdd5 /mnt/hdd5 ext3 defaults 1 2 Save the changes and that should be it. hdd5 should be mounted automatically every time you boot up at the mount point, /mnt/hdd5. To test to see if it mounts OK, run as root: # mount /dev/hdd5 If you don't get an error message, hdd5 should be mounted. If you navigate to /mnt/hdd5 you should see the contents of hdd5. If you want read/write access to the drive for all users, you will have to change the permissions on the drive mount point while it is mounted like so: # chmod -R 777 /mnt/hdd5 That should do it.

Depends what you mean by typical but you could probably get it down to 2.5 GB and still have a fairly decent install. I usually won't install it on a partition under 5 GB just to leave room for other things.

The X server loads right after ALSA; my guess is you have misconfigured your matrox graphics card and that is what is hanging up your boot. You also appear to need those boot parameters to get that far. To test the theory, we can try booting in nongraphical mode so the X server never tries to load. Pass the following boot parameters: linux noapic nolapic acpi=off nopinit 3 You are booting to run level 3 which is a nongraphical command line mode. If this works you will get to a command line login which will look like this: localhost login: type in root here and enter your root password when prompted. Then run: # XFdrake which is the mandriva graphics setup program. Check the entries for graphics card, monitor, etc. You navigate from the keyboard as there is no mouse support, just like a bios setup. Most importantly, after making any changes, you can test your new configuration from within XFdrake. Keep trying till you get something that tests out OK. When done, exit XFdrake and type this at the command prompt: # reboot Try rerunning with the same boot options but don't put in the "3" this time.

Do you have an ide zip drive? Actually, instead of playing 20 questions on your hardware, boot up with your knoppix cd, open a konsole and run: $ su # lspci and post the output here. That will give a pretty good idea of your hardware configuration. Also post your /etc/lilo.conf file from mdv2007; at least we can see what boot parameters are on the append line. You could also try: linux noapic nolapic acpi=off nopinit if you haven't done that already. Another thing to check. Go into your bios setup and make sure Plug 'n Play is disabled. The good news is you can boot up with knoppix which indicates to me you don't have any severe linux hardware incompatabilities. This appears to be mandriva specific, either something in the mdv kernel or the parallel boot process or a combination/interaction may be causing the problem. Edit: AussieJohn, he appears to have done a standard, default mdv2007 install which apparently went OK but it fails to complete a bootup. He appears to be using a knoppix livecd to boot up and access the mdv root filesystem and mdv boot logs. The knoppix livecd appears to be booting up fine.

This isn't a boot loader problem IMHO; it's a booting problem. Changing from lilo to grub won't help here. You are getting to a boot prompt when you hit the Esc key so lilo is installed. Also if lilo wasn't installed to the mbr which is the default action with mdv2007, you wouldn't get a lilo boot selection screen. The traditional advice is hit the Esc key to get you to a boot prompt and type: linux noapic nolapic acpi=off and then hit Enter. You can also try: linux nopinit If either of the above help, we can later edit the lilo configuration file to automatically pass those parameters every time you boot. This assumes you have aready done a complete mdv2007 default install, you can't get the system to complete a boot and you are accessing the installed files on your hard drive by booting the install cd or a livecd which appears to be the case since you are accessing the boot logs through a mount point. I also assume you would know if you installed the boot loader to a floppy as you have to specifically direct the install program to do that and have to put a floppy in the drive. If you did this and failed to put the floppy in the drive, you wouldn't get as far as you do in the boot process. In fact, you wouldn't boot at all. If you want, you can boot up with the cd and post the lilo configuration file, /etc/lilo.conf. But as I said, I don't think that's where the problem lays. Also, if you have any usb storage devices connected, try booting with them disconnected. The haldaemon(HAL) specifically deals with this type of removable storage device and that's where you are hanging up.

PATH is the group of directories that will be automatically searched for an executable file. If an executable is in PATH, you don't need to give the entire path to the executable; you just type the executable name at the command prompt. To get a listing of all directories included in PATH, run: $ echo $PATH If whatever executable was installed by that rpm is not in a directory in PATH, you have a problem. To find out where w3c is installed run: $ rpm -ql <full name of rpm> which should list all the files installed by the package. From there you can get the location of w3c. If it's not in PATH, you can create a link to w3c in /usr/bin and that should fix it.

Yes, rc.local is an init script that runs with root privileges. The problem probablly has something to do with the nuances of launching a pyhton script from within an init script. I'm not sure exactly what's going on but here's another suggestion. Try making a simple bash script to launch the program. Create a text file called "dodenyhosts" and put the following text in it: #!/bin/bash /usr/bin/python /usr/bin/denyhosts.py --daemon --config=/usr/share/denyhosts/denyhosts.cfg Make dodenyhosts executable: # chmod a+x dodenyhosts and see if the script can launch denyhosts: # ./dodenyhosts I'm trying to explore whether there is some problem of launching this from a bash script which is essentially what you are trying to do. If it doesn't work, the error messages may give some indication why. If you can launch from this script, you need to get more info as to what is happenning when these commands attempt launch from within rc.local. Edit rc.local like you did before but add: /usr/bin/python /usr/bin/denyhosts.py --daemon --config=/usr/share/denyhosts/denyhosts.cfg &>/home/<username>/error.txt Note the formatting here doesn't permit this to go on one line but there should be a space between denyhosts.cfg and "&>/home/<username>/error.txt". The added text will cause any output or error messages that occur when the command runs to be outputted to a textfile, error.text, in your /home/<username> directory. This might give you some idea about what is going on.

Since no one has replied, I'll give you my best guess - some dependency needed by your script has not loaded at the time the system attempts to start the script. If it is a timing problem as I suspect, then try and run the script by editing /etc/rc.d/rc.local. Put whatever command you use to run the script at the end of rc.local and see if it works on reboot. The rc.local hack is commonly used to get around these timing problems since rc.local is the last init script to run.

Just saw this article today mentioning a couple open source file recovery tools you might want to try, TestDisk and PhotoRec: http://www.serverwatch.com/tutorials/article.php/3645886 Apparently their included in knoppix. You may want to give them a try.

Post the output of: $ rpm -qa | grep gcc Here's what I get on LE2005: $ rpm -qa | grep gcc gcc-c++-3.4.3-7mdk gcc-cpp-3.4.3-7mdk gcc-3.4.3-7mdk libgcc1-3.4.3-7mdk Also, have you configured your urpmi sources to include the plf-free and the plf-nonfree repos(see above easy-urpmi link)? They have most of the dvd authoring/video stuff so you may not need to compile from source. It's one of the nicer things about mandriva.

I think you are better off using windows tools to try and repair a corrupted FAT16 partition or recover your data. Did you try running chkdsk on the partition: http://en.wikipedia.org/wiki/CHKDSK Here are two free file recovery programs: http://www.pcinspector.de/download.asp?lan...1#file_recovery http://www.recovermyfiles.com/ I've used PC Inspector in the past with some success.

How big is the partition? If you have the room on your hard drive you can use the dd command to create an image file of the partition in linux: # dd if=/dev/hd** of=fat16.img where "hd**" corresponds to the device file for the relevant partition. This will create a file in your current directory called "fat16.img" that is the image of your damaged fat16 partition. dd works at a very low level and will give a sector by sector copy of the partition even if the filesystem is corrupted. You can then try and mount fat16.img using the loop device method: # mkdir /mnt/test # mount -o loop fat16.img /mnt/test See if the command goes without error(unlikely). If it does, you should be able to read the contents of the image file at the mount point, /mnt/test. If not, you have a good backup of your original partition and can be a little freer in trying to recover your data.

That would only work if you were in your firefox plugin directory when you ran the command. The easier way to do that if you're using kde is to open konqueror and navigate to your firefox plugin directory. Then open another konqueror instance and navigate to the jre plugin directory where libjavaplugin_oji.so is located and drag the file to the firefox plugin directory. Select the create link option from the drop down menu. You don't need to be root to create that link using kde IIRC.

Firefox's ram usage is on the high side but not totally out of line. However, there is no way that firefox should have a 99% cpu usage. With 2 gigs of ram, I assume you are not running a PIII. Please post what cpu you are using. When any process takes up 99% cpu, your system will start to crawl. I don't know what accounts for this but the first thing I'd try is uninstalling your extensions one by one and see if the cpu usage drops.

Check with: # lsmod to make sure your ntfs and sata modules are loaded. The above should list all loaded modules. If not, run: # modprobe <module name> to load the module that's missing. You can run lsmod on the good kernel and compare the output you get on the non-functioning kernel to get some idea of what's going on. From the error messages, I'm guessing it's a problem with the sata driver. You also need to have the scsi support compiled in the kernel and the scsi modules loaded(scsi-mod, sd_mod) for the sata driver(libata and the specific sata chipset driver) to load since sata uses the scsi protocol. Also post what sata chipstet you have on your sata controller. I've seen reports of problems with SiS based sata controllers and some newer kernels.

You don't need windows assuming you are running Dreamweaver with wine/Crossover. Wine/Crossover creates a simulated C drive within linux. That's what Aerogate's post is referring to.

Check out this howto: https://mandrivausers.org/index.php?showtopic=4567 It's a little dated but the procedure is basically the same.

Thanks for the tip ian. I thought the problem might go further than openssh. It's bugs like this that keep using good old reliable LE2005. It will probably be another six months bvefore mdv2007 is stable enough for me.

This appears to be a bug in the mandrake control center(mcc), at least in mdv2007 if not mdv2006 as well. Even after updating all repos, you will not find openssh-sever 4.5 listed in the Software Management section of mcc; it's simply not there anywhere. Only the older openssh-server 4.3 is listed. As a result, there is no way to install openssh-server 4.5 from within mcc. However if you go: # urpmi openssh-server openssh-server 4.5 is downloaded and installed from the update repo. Apparently, the software database is not being properly updated from within mcc.