[CentOS] Xen, Amazon, and /proc/cmdline
Amazon (or perhaps Amazon's configuration of Xen) forces a machine to come up at run level 4, regardless of what's in /etc/inittab. I've looked through /etc/rc.sysinit and /etc/rc.d/rc, to determine which (if any script) looks at /proc/cmdline and forces a particular run level, but to no avail. It seems that /sbin/init does the forcing. Can anyone confirm that /sbin/init reads /proc/cmdline to overwrite /etc/inittab? I can't seem to find any reference in man pages or searching the web. Thanks, Kurt ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The directory that I am trying to clean up is huge
What was your original find command? Robert Nichols wrote: Les Mikesell wrote: On 1/26/2010 11:42 AM, James B. Byrne wrote: On Mon, January 25, 2010 13:40, Les Mikesell wrote: . I'd say it is more likely that the command that resulted in an error wasn't exactly what was posted or there is a filesystem problem. I do not consider a file system issue, as in error or corruption, highly probable in this case. It might be, however, that something returned by the find caused rm itself to choke. Causing one instance of the per-file rm invocations to choke shouldn't bother the rest. And while file system corruption isn't likely, it is still a possible cause of generally-strange behavior. The most probable thing still seems like there was an unquoted * on the line that was actually typed when the error was reported. Indeed, upon closer examination, that message: -bash: /usr/bin/find: Argument list too long came from the login shell, not from 'find', and indicates that the shell got a failure return with errno==E2BIG when it tried to exec() /usr/bin/find. The 'find' command was never executed. -- Global DataGuard, Inc. Software Engineer Phone: (214) 980-1444 ext. 242 Cel: (214) 682-1978 Email: knew...@globaldataguard.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Xen, Amazon, and /proc/cmdline
Kwan Lowe wrote: Kurt Newman wrote: Amazon (or perhaps Amazon's configuration of Xen) forces a machine to come up at run level 4, regardless of what's in /etc/inittab. I've looked through /etc/rc.sysinit and /etc/rc.d/rc, to determine which (if any script) looks at /proc/cmdline and forces a particular run level, but to no avail. It seems that /sbin/init does the forcing. Can anyone confirm that /sbin/init reads /proc/cmdline to overwrite /etc/inittab? I can't seem to find any reference in man pages or searching the web. You *can* override the initdefault in inittab via the kernel option, but if you're not seeing it in /proc/cmdline it's likely some other rc script. I saw some references to this being controlled via xen: ... So it may be being passed through xen which might not show up in proc/cmdline (can't test right now). Perhaps I mis-stated what I was asking. I'm well aware that Amazon (aka Xen) is passing run level 4 to the kernel because the number '4' is in /proc/cmdline. I can't change that since I cannot configure Xen or even ask Amazon to. What I'm trying to figure out is at what point in the booting process is something looking at /proc/cmdline INSTEAD of /etc/inittab for the default run level. Is it /sbin/init? I can't seem to find any reference of that in any man pages. Essentially, I'm trying to short-circuit this boot process to execute a run level of my choosing, and not be forced to use 4. I've already looked at modifying /etc/rc.d/rc (since it's the one that uses /sbin/runlevel to execute various /etc/rcX.d scripts. I was hoping to have a more elegant way so that I don't have to maintain CentOS-specific bootstrap code. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Xen, Amazon, and /proc/cmdline
nate wrote: Kurt Newman wrote: Is it /sbin/init? I can't seem to find any reference of that in any man pages. Essentially, I'm trying to short-circuit this boot process to execute a run level of my choosing, and not be forced to use 4. it's probably the kernel itself calling the value defined in /proc/cmdline For example when I go to single user mode I often specify init=/bin/bash on the command line, which I'd expect would take /sbin/init completely out of the loop. I thought that as well, except that init is one of the kernel-defined boot parameters that it accepts (man bootparam, for more info), so the kernel can easily change what's called. After a bit more research using different terms in google, I stumbled upon this page: http://www.nongnu.org/lpi-manuals/lpi-102/lpi102.html#id281730 I'm not exactly sure how the kernel determines what to pass to /sbin/init (or perhaps what init ignores), but it does some how distinguish what's a kernel module parameter, and what's not. Regardless, /sbin/init does seem to be the culprit. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Xen, Amazon, and /proc/cmdline
Stephen Harris wrote: On Tue, Jan 26, 2010 at 03:48:45PM -0600, Kurt Newman wrote: What I'm trying to figure out is at what point in the booting process is something looking at /proc/cmdline INSTEAD of /etc/inittab for the default run level. Aren't these passed by the kernel to init as cmdline arguments and environment variables? Check out the kernel sources for init/main.c I've already looked at modifying /etc/rc.d/rc (since it's the one that uses /sbin/runlevel to execute various /etc/rcX.d scripts. I was hoping to have a more elegant way so that I don't have to maintain CentOS-specific bootstrap code. Well, it's not CentOS specific; it's Amazon specifc. I meant /etc/rc.d/rc being CentOS-specific (technically, RHEL-specific). But, anyway, what differences are there between rc3 and rc4 ? On my machine they're minimal: % diff -r rc3.d rc4.d Only in rc4.d: K95firstboot Only in rc3.d: S99firstboot If you build your rc files correctly so that they're chkconfig compatible then you just make your script get added to rc3 and rc4 eg # chkconfig: 2345 09 91 # description: my startup script Alternatively, how about this inittab entry: 4:4:once:/sbin/init 3 May work. I've never tested! The difference for a stock CentOS machine, is not much. However, I don't use a typical run-level system for my servers. I did try modifying /etc/inittab like you pointed out, so that it would use run level X start-up at run level Y, but when executing /sbin/runlevel, it still said '4'. Which, unfortunately, breaks my code (and there's a lot, so I don't want to change it). In any event, it appears the easiest bet for me is to simply patch /etc/rc.d/rc and simply have it call some custom bootstrap code to ensure that it's in the correct run level when starting. Sucks, but probably the easiest way for what I need. Thanks for the responses. Kurt ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Recommended approach for adding PATA_IT8213 support via RPM
My question is: Anyone know of a howto of some sort (or perhaps any instructions) for creating a kernel module to add support for a particular device. I need to get support for the PATA_IT8213 hardware. Supplementary information: I've read http://wiki.centos.org/HowTos/BuildingKernelModules and http://www.kerneldrivers.org/RedHatKernelModulePackages. However, it seems the underlying assumption for these two HOWTOs is that you have separate source code for the modules. Support for the PATA_IT8213 is already in the kernel. However, the stock rhel kernel does not support it, even as a module. I know I could simply rebuild the source RPM with modified kernel config files, but that feels less than satisfactory since I'm not forced to maintain my own kernel module if I decide to upgrade. Any suggestions? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Supermicro Adaptec AIC-9410 HostRAID controller
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 1) Has anyone been able to get their AIC-9410 controller recognized in CentOS 5.3? I'm working with a Supermicro X7DBR-3 motherboard. It has 2 ICH Raid Codebase options in the Bios (Intel and Adaptec); neither of which seem to change Linux's behavior. The interesting part though, choosing either Adaptec or Intel, then performing an 'lspci' always displays Intel Corp 631xESP/632xESP SATA RAID Controller (rev 09). I've seen several people post on a variety of mailing lists (typically using older CentOS revisions), but it doesn't appear many were successful. It seems most swap to software raid. 2) When using this internal host raid controller, shouldn't the raided devices appear as a single device like other traditional scsi controllers? Regardless of the raid options I choose, Linux still continues to see both drives (/dev/sda and /dev/sdb). Is this a function of being 'HostRAID'? 3) If you've been able to get it to work, which driver did you use? Thus far, I've tried 2 drivers. 1st driver: adpahci -- Unsuccessful I downloaded it from supermicro's website. ftp.supermicro.com/driver/SATA/Adaptec_ESB2/Linux/Redhat/adpahci.rhel5.i686.img After successfully loading the image and inserting the module using kickstart, nothing useful happens, other than several /sys entries added. (NOTE: I had to change the internal cpio archive pathing from `2.6.18-8.el5' to `2.6.18-128.el5'). 2nd driver: aic94xx -- Unsuccessful The driver is built-in via a patch to the Redhat stock kernel. Other than saying that it's loaded, it also does nothing useful outside of /sys entries. Several mailing lists and documents pointed to using the 'attach_HostRAID' option, however, it doesn't exist. Using this option with `insmod' (or modprobe) fails. 3rd driver: adp94xx -- In the works I downloaded this driver from Adaptec's website: http://www.adaptec.com/en-US/speed/sas/linux/adp94xx-1_0_8-12_src_tgz.htm So far, I'm not able to get it to compile because I'm trying to create a patch file so that it incorporates all of the contents of the tarball. Any ideas on where to go from here? I'd really like to avoid software raid. Thanks, Kurt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqVWbQACgkQ0rcig5YkL7E62gCgiMUdhlkzImPnt4y1dk/sMntO XFEAniweClsip2XohAfsGFlvPtKW44aH =LRX5 -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
