martouf

an answer to your query depends on your application.. are you the one and only user on the system? or are you setting up to serve the needs of many users? If the former, then a very simple disk allocation plan of 120MB /boot, 1x RAM for swap (max 1GB), and the rest of the disk to / -- will likely serve your needs well. If the latter, then splitting up / into /home and / (minus /home) is in your best interest of keeping what the users are doing (like filling up /home) from affecting the entire system.

might be the monitor can't quite manage that high a refresh rate. can you reset the upper bound of the refresh range for your monitor in the X Windows config file to 80 or 75 Hz ?

I would hazard a guess all of those kernel configuration elements have already been enabled and are included in the kernel you're now using. You may confirm this by checking for the specific CONFIG_xxxxx strings in the kernel config file used to build your kernel (you'll find it in the /boot dir).

the segmentation fault happened after the 37th of 227 things on the list of what YUM was doing.. perhaps caused by a communication channel error. Can you restart the YUM update? What you saw after the segmentation fault is a command shell prompt. The shell is waiting for you to type in a command (or you may type 'exit' to dismiss the shell window). The warning you received is because during the update, YUM found there already was a modified submit.cf file (modified as compared to the database YUM uses). Instead of blindly overwriting your existing submit.cf file (in case there's something unique and special about your setup), YUM has placed the new/updated version of submit.cf in the file submit.cf.rpmnew. You're now expected to compare submit.cf.rpmnew and submit.cf and reconcile the differences manually.

when you say "errors", what kind of errors do you mean? there are many kinds of errors and to be able to help I must know more specifically about the errors you are experiencing. can you jot down a few of the messages you're seeing?

check dmesg again after you've connected the camera (and turned the camera on), and you should find an indication of the raw device name.

I can't resist giving you a pat on the back for answering your own question. ..and I didn't even lift a finger. hey!

which kernel are you running? (please provide output from "uname -a")

jpc1258: "boot parameter" == passed to the kernel at boot time. compare the regular boot string with any 'safe mode' entry in your bootloader, just to see what different boot parameter lists look like...

sure, you'll find it in a bookstore.. Do you live near a Borders (borders.com), a Barnes & Noble (barnesandnoble.com)? or maybe you're farther north and live near an Indigo (indigo.ca)? (a list of my favorites - otherwise any well-stocked College bookstore will do)

that's really great! I'm hoping to hear some early testing results in, say, 4 to 6 weeks, then. To answer your question about 'make': yes, I'm quite certain there's an excellent book. (checking to see if it's still in print...) Oooh! 3rd Edition is due out in December. Here's the link for the 2nd Edition (Oct 1991). You might find a couple of LinuxDevCenter articles useful: intro and advanced.

not to be flip, but the answer to your question depends on what you mean by: "Red Hat Linux" with end-user or enterprise support or without support (other than community support)? If you're inquiring about the end-user product with no support which began with (what?) Red Hat 4.X (was there an earlier "named" version?) and ended with Red Hat 9.0, then [size:4]read this[/color] and then visit the [size:4]Fedora[/color] Project site. In other words, there are post-9.0 versions of Red Hat Linux. They're just not called "Red Hat X.X" any more.

guess I'm being as clear as the Savannah after a big rain storm.. Plan A needed your referring back to an earlier post.. the one with the Ensure init can find alsasound section in it.. no matter, though, I'll repeat it here: Ensure init can find alsasound To check to be sure all of the right file links have been made, do "find /etc/rc.d/rc* -name \*alsa\*". You should have pairs of files which look like "Sxxalsasound" and "Kxxalsasound" (where 'xx' are digits) in at least 'rc2.d', 'rc3.d' and 'rc5.d'. (the /etc/rc.d/rcX.d dirs correspond to init runlevels - see /etc/inittab for more info). If you need to create the links for init's benefit, then do: Quote: ln -sf /etc/init.d/alsasound /etc/rc2.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc2.d/K10alsasound ln -sf /etc/init.d/alsasound /etc/rc3.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc3.d/K10alsasound ln -sf /etc/init.d/alsasound /etc/rc5.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc5.d/K10alsasound YMMV: might need to use /etc/rc.d/rcX.d/ instead. check before you attempt this. In Other Words If you run the 'find' command above, and don't find pairs of files with names like "[sK][0-9][0-9]alsasound" (in regexp form) then you'll need to create them using the 'ln' commands listed above. After they've been created, and only then, will the alsasound script be called by init when your system changes run levels and automatically start/stop your sound system. Still with me on this? as for the stuff in the curly braces, the ">/dev/null 2>&1" is confusing you? all that means is to redirect stdout to /dev/null and combine stdout and stderr. IOW: send any output it might generate to /dev/null. make it silent. but still do something - just prevent it being able to complain if it can't.

this document at linuxiso.org should help.. It's entitled "How To Check MD5sums On A Linux Iso Image", and provides links for DOS and Windows versions of md5sum if you're not yet linux-enabled.

you might try to uncheck Red Hat->Preferences->Sound->Enable Sound Server Startup or instead killall esd ; killall artsd and see if your troubles are caused by your window manager's sound multiplexing daemon.

it's a real knee slapper, 'bash' is: bash == Bourne again shell you see, there once was only 'sh' (Bourne shell) and 'csh' (C shell) and the code for 'sh' was under copyright.... eeaaww, I guess you had to be there. 8)

gradually, the layers of the Vidalia are revealed.. I thought you were running FC2? not FC2+updates. ok, well, in that case choice #1 isn't available, exactly. Trying to get the job done with pre-packaged stuff and not build from source... You've compensated for me missing a vital cpio param, that's good, but my bad. You've copied the alsasound script to where it needs to be, that's good. You skipped the "Ensure init can find alsasound" part, not so good. ;( Plan A Rebooting won't do anything if init can't find the appropriate Sxxalsasound entry which will cause it to start up the sound system. 'S' is for 'S'tart and 'K' is for 'K'ill, and the 'xx' number is for sequencing. You can easily test just the alsasound script as root (here are examples): "/etc/init.d/alsasound start" "/etc/init.d/alsasound status" "/etc/init.d/alsasound stop" Double-clicking on a shell script file (hence the 'sh' abbr) won't necessarily do anything good. In this alsasound case, it's expecting a parameter. Make those entries for init, then (as root) "telinit 1". Once you've reached runlevel 1 (wait for it), then "telinit 5". If you want to save time waiting for X Windows to start, then "telinit 3". (how to test this stuff without rebooting) Plan B edit modprobe.conf, making changes only within the curly braces (the '{' and '}' chars). rip out the aumix stuff to put in the alsactl stuff in its place. ( don't forget to "cp /etc/modprobe.conf /etc/modprobe.conf.saved-just-in-case" before you start editing )

since the sound was working with the only difference being a kernel version, you might try the boot parameter "acpi=noirq". It makes the difference between a couple of things working versus not working for me with a 2.6 kernel. (one of which is sound)

TIMTOWTDI - there is more than one way to do it here's another way for when you know the system is still OK but you didn't arrive with boot/rescue disc in hand: 1. boot with parameter "init=/bin/bash" 2. the disks will be mounted read-only (ready for fsck), so remount the ones you need to write to as read-write. ( for me, it's: "mount -o remount,rw /dev/sda2 /" ) 3. change any account pwd you want: "passwd root" or "passwd user12" 4. "sync" ( for purists, it's: "sync;sync;sync" ) 5. CTRL-ALT-DEL done! 8)

after spending more time researching this, it seems the missing alsasound script in Fedora Core N is either a big packaging mistake or the result of a deliberate design change. what you're experiencing is probably better called "ALSA Adventures", and I don't have any problem with you using the words I've posted here, but you must be made aware that all of the words posted here are entirely "© 2002-2004 Philipp Esselbach - All Rights Reserved". so I'm not the final word on getting permission for re-use or re-publication. The Choices 1. Go With What Planet CCRMA Provides (assume it's a packaging mistake) 2. Go With The Flow (assume it's a design change) Pros and Cons If you choose #1, you get an ALSA update from 1.0.3a to 1.0.5a-1 plus the 'missing' alsasound script. If you choose #2, you keep your 1.0.3a, get to edit a couple files, add the alsasound script from the alsa-utils sources (or I can send you one) and then make the right file links so init does what's needs as you change run levels during boot and shutdown. In both cases, you'll need to make sure the right links are there for init. Choice #1 Based on the output of "uname -p" ('i586' or 'i686') grab the i586 or i686 flavor made by Planet CCRMA. Grab alsa-utils and alsa-lib and alsa-oss and alsa-lib-jack-plugin. If doing "rpm -Uhv alsa-*rpm" complains about something missing, then just pick what you need from here. Choice #1b Just grab alsa-driver. Either flavor, doesn't matter. It contains nothing executable you will use except the alsasound script. You don't actually update your ALSA drivers, though. You just fix the packaging mistake. as root from root's home directory (/root): Quote: [size:2]mkdir temp cp /whereever-you-have/saved/the/rpm/alsa-driver-*rpm temp cd temp rpm2cpio alsa-driver-*rpm > alsa-driver.cpio cpio --extract < alsa-driver.cpio cp alsasound /etc/init.d [/color] Choice #2 You'll be editing /etc/modules.conf and /etc/modprobe.conf.local. One or both of these files have the string 'snd-card' or something like 'audigy' in them. Check with "grep snd-card /etc/name-of-the-mod-file" and "grep udig /etc/same-as-just-a-moment-ago". These files will need stanza that look like this: Quote: [size:2]# Note: for use under 2.4, changes must also be made to modules.conf! alias snd-card-0 snd-audigyModuleName install snd-audigyModuleName /sbin/modprobe --first-time --ignore-install snd-audigyModuleName && { /usr/sbin/alsactl -F restore >/dev/null 2>&1 || :; } remove snd-audigyModuleName { /usr/sbin/alsactl store >/dev/null 2>&1 || :; } ; /sbin/modprobe -r --first-time --ignore-remove snd-audigyModuleName [/color] YMMV: need to find your existing 'snd-card' lines to figure out what the Audigy driver is named. Note: the stanza has only four lines - the 'install' and 'remove' lines are long. Ensure init can find alsasound To check to be sure all of the right file links have been made, do "find /etc/rc.d/rc* -name \*alsa\*". You should have pairs of files which look like "Sxxalsasound" and "Kxxalsasound" (where 'xx' are digits) in at least 'rc2.d', 'rc3.d' and 'rc5.d'. (the /etc/rc.d/rcX.d dirs correspond to init runlevels - see /etc/inittab for more info). If you need to create the links for init's benefit, then do: Quote: [size:2]ln -sf /etc/init.d/alsasound /etc/rc2.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc2.d/K10alsasound ln -sf /etc/init.d/alsasound /etc/rc3.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc3.d/K10alsasound ln -sf /etc/init.d/alsasound /etc/rc5.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc5.d/K10alsasound [/color] YMMV: might need to use /etc/rc.d/rcX.d/ instead. check before you attempt this.

it's too bad that waistlines, once expanded, never quite return to their original shape. actually, there are courses for this stuff. prep work for the RHCT certification would do. there's also a very fine "LPI Linux Certification" book from O'Reilly. getting back to the sound card: $ cat /proc/asound/cards 0 [Audigy ]: Audigy - Sound Blaster Audigy Sound Blaster Audigy (rev.3) at 0xdf80, irq 11 ^^ means only one sound card was detected during startup and a driver has been loaded for it. the initial '0' is the Card ID#, which isn't all that important now that it's proved there is but one card. If two had been detected, that could have caused the automagic config restore to fail. the difference between 'su' and 'su - root' is the former gives you the privilege of root but with the envars (PATH is one of them) set to a default, while the latter sets up the environment the same as logging in as root. (you get the environ and privilege with 'su - root', only the privilege with 'su') I went on a file hunt in the Fedora Core 2 mirrors, looking for the package which should have provided you the /etc/init.d script for saving and restoring your sound card setup. I looked at 'alsa-lib', 'alsa-utils', 'alsa-lib-devel' and 'initscripts'. No joy. ;( Would you tell me what you get when you run: "rpm -qf /etc/init.d/alsasound" anyone reading this: if you are running FC2, please see if you have an 'alsasound' (or 'sound' or 'soundcard') init script, run the rpm cmd using the full name of the script, and post results here. see, I'm wondering at this point, has a soundcard system config step gotten skipped? or has the installation of one of the FC2 packages gone wrong? I'd like to figure that out before creating a unique/custom solution applicable only to your system.

hmm.. strange. when it's behaving like that, is 'smbmount' still running? ( "ps ax | grep smb" ) you're using reasonable uid=,gid= values as options to 'smbmount'? (reasonable from the view of which uid+gid the ftp server runs as) (I'm trying out something similar to your setup on my system as I write this) hey, "mount --bind" does not include any possible submounts within a filesystem hierarchy. try "mount --rbind" to include all possible submounts. does that help?

ok, keeping in mind the source of this document, skip down to the end of Page 9. for competitive reasons, you'll rarely see any direct comparison between the Intel line of processors and the Motorola line. The chart shows an 'everyday' test (except for the fact the image file is a 300MB monster!). Take notice of the relative measure of the 1.7GHz Pentium M and the 1.33GHz G4. Both systems had 1GB RAM. My interpretation is the results show a dead heat. A small difference in disk I/O rates could well explain any difference. so by this simplified measure, a 1.25GHz G4 is about the same diff as a 1.6GHz Pentium M (by scaling linearly). if you take into account the relative cost of the add-on software you have in mind and the cost of any I/O interfaces you may need to add to suit your needs, then you'll have a better idea of the relative merits of one product over the other. CPU speed is rarely a sole criterion - unless you're image processing your way to a completed scientific paper.

if proFTPD is anything like the wuftpd I know, then it could very well be a permissions problem. if you specify a permissible directory, are you sure it also includes all of that directory's sub-directories? since proftpd probably runs as user 'nobody', do all of the dirs in the permitted filesystem tree all have world read+execute (chmod o+rx dirname) set? what does "ls -ld" look like for each of those dirs you named?

since you say "additional package" in the thread title, I'll guess you've already got a working Fedora system but are adding a few more packages. yes? [tt][size:3]Package files for install, upgrade and query operations may be specified as an _ftp_ or _http_ style URL: ftp://USER:PASSWORD@HOST:PORT/path/to/package.rpm If the :PASSWORD portion is omitted, the password will be prompted for (once per user/hostname pair). If both the user and password are omitted, anonymous ftp is used. In all cases, passive (PASV) ftp transfers are performed. [/color][/tt] example: rpm ftp://hostname.example.com/redhat/i386/packagename.rpm hope this helps.