- WLUG - wlug.mailman3.com

Re: [Wlug] It boots. Now what?

by sageman＠WPI.EDU

> Message: 1 > Date: Tue, 22 May 2007 09:16:18 -0400 > From: ken jones <kjones(a)ziplink.net> > Subject: [Wlug] It boots. Now what? > To: WLUG <wlug(a)mail.wlug.org> > Message-ID: <4652ED22.5090802(a)ziplink.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I would like to get X11 services. I did an "emerge xterm". Here's what > happened. > ------------start snip------------- > (chroot) livecd proc # emerge xterm > Calculating dependencies | > !!! All ebuilds that could satisfy ">=x11-proto/xproto-7.0.6" have been > masked. > !!! One of the following masked packages is required to complete your > request: > - x11-proto/xproto-7.0.7 (masked by: ~sparc keyword) > - x11-proto/xproto-7.0.10 (masked by: ~sparc keyword) > - x11-proto/xproto-7.0.9 (masked by: ~sparc keyword) > > For more information, see MASKED PACKAGES section in the emerge man page > or > refer to the Gentoo Handbook. > (dependency required by "x11-libs/libX11-1.1.1-r1" [ebuild]) > --------------end snip---------- > > What do I make of this? > > Another problem. My livecd prompt and my chroot prompt both see my > ethernet card, eth0. However my new boot does not see the card. Ideas? > > Ken Jones Ken, Pulling in xterm, it needs libX11, which, in turn, is pulling in xproto. For the sparc, a masked version of xproto seems to be required. This masking with the "~" is just saying it's in the "testing" set of packages, but it's not hardmasked (it would mention it if it was), meaning it *should* be stable. Regardless, you need the "unstable" version in order to get xterm. There's a number of ways to deal with this, but the suggested way is to add the necessary files, one by one, to /etc/portage/package.unmask. You can do this by adding a line with "x11-proto/xproto ~sparc", or, even better, using the flagedit utility (which you must first "emerge flagedit" to get), and just do: "flagedit x11-proto/xproto +~sparc". [http://damz.net/flagedit/] More info on masking: http://gentoo-wiki.com/Masked

May 22, 2007

Re: [Wlug] [Fwd: Re: Multiple RS232 Com Ports...]

by John Stoffel

Stephen> Lots of good info... I hadn't stopped to think about a Stephen> terminal server! They're a great way to get a bunch of serial ports, especially since they can be on the network and near the equipment to manage, but not near the server room, etc. Stephen> OK, lets see about answering some of the questions... Stephen> - - - - - - Stephen> Yes, cabling will be fun. The sondes are used for sampling Stephen> water... The sondes we use are cylinders approximately 2.5 Stephen> feet in length and about 3 inches in diameter (one, called Stephen> "big Bertha", is about six inches in diameter) . One end has Stephen> a data connection that uses a round, screw-on, water tight Stephen> serial connector, and the business end has several sensors Stephen> sticking out (optical, chemical, conductivity, a little Stephen> propeller for mixing water to be sampled, etc., etc.), all Stephen> within a screw-on cage that protects the sensors from stuff Stephen> like rocks passing by in the current (fast currents equate to Stephen> rather large rocks). Not a problem. If you already have the DB9 -> screw on connectors, you should be all set. Stephen> The idea is to have a tank of water (fish tank, cooler, Stephen> whatever) fitted with Plexiglas that has multiple holes Stephen> through which the several sondes are positioned upright, data Stephen> end pointing up, with a bunch of cables hanging in-place Stephen> above each sonde - think of the device that sets the bowling Stephen> pins in place at the end of the alley... Sounds like a good plan. Stephen> Anyway, you place a bunch of sondes into the tank (that has Stephen> circulating water being maintained at a precise temp, % Stephen> dissolved Oxygen, and so on), plug each sonde into the cable Stephen> available directly above it, and then go to the *insert Linux Stephen> solution here* and initiate communication, data upload, and Stephen> calibration routines. (By the way, the tank is just about Stephen> done - its is being debugged as we speak.) This is the key part here, and the one which I think is quite easy to do. As you mentioned before, the sondes have their own built-in menu structure, so they must provide some basic serial support. So I think that you'll be able to easily talk to them. Esp if you only need to use 'hyperterm' on Windows to talk to them. Heck, I bet you probably don't even need all the serial pins to talk to them, but getting hold of the documentation from the vendor is the key thing obviously. Stephen> After upload and calibration (using the water in the tank), Stephen> configure each sonde for the next deployment (how often to Stephen> sample, etc.), turn them off, unscrew the cables and screw on Stephen> a waterproof cover, remove them from the tank, and place the Stephen> entire sonde into another protective chamber (6" PVC pipe Stephen> with holes drilled in a specific pattern and capped on both Stephen> ends) for another few weeks in some river/lake/coastal Stephen> location. I'd seperate the calibration and the configuration steps, probably into seperate scripts. This way you can just say: calibrate 12 And the calibrate script knows how to go and find serial line 12, which is hanging over slot 12 and drive a sonde. Then you just have: config 12 -i <interval> ... Which again, knows how to talk to cable 12 to configure your settings. You can even have the script just prompt for all the settings and then it goes off and does the work. You hide all the knowledge of how you actually get to serial port 12 in either a library shared between the scripts, or in a configuration file. Something like: 1 /dev/ttyS1 2 /dev/ttyC0 12 termserver1:7001 13 termserver1:7002 This tells the script which port to access. The nice thing about a terminal server is that they're actually quite easy to drive over the network. Esp if the serial port doesn't need a ton of hand holding. And in this case, once you've got the configuration setup properly, you can just set *all* the ports to that setup and forget about it. Stephen> Yes, I may be confusing myself regarding "I/O device driver" Stephen> versus "driver" for the sonde... However, I'm pretty sure Stephen> that all I need is a vanilla "RS232 device driver" that will Stephen> "just work" for any number of "com" ports by allowing some Stephen> vanilla terminal emulation package (preferably one that has Stephen> scripting capabilities) to talk to multiple RS232 ports. Exactly. You just want some way to talk to a bunch of ports in a simple manner. Heck, I'd even look into using 'expect' to drive the 'c-kermit' program to do the serial port connections. I even found an article on the web which talks about using c-kermit as the scripting language itself. Also, there's an expect script which will follow along with you as you do a sample session, and then let you play back the session again and again. The script is called 'autoexpect' and can be found with a bit of poking... on my Debian box it's in /usr/share/doc/expect-dev/examples/autoexpect* which is a pain since you have to install the development package to get it. Oh well... Stephen> I could be wrong about this, in which case I may need to Stephen> write some code, or perhaps the manufacturer might be Stephen> thinking of supporting Linux. I don't think you'll need to get the manufacturer involved at all, beyond figure out exactly what the serial connection settings are, and the command language. But you will need to script out some stuff using something like 'expect' or 'c-kermit' to do the work. This shouldn't be too hard, esp if they calibration part is very mechanical and doesn't change. Stephen> I don't do the day-to-day instrumentation work, but I am Stephen> supposed to worry about it none the less. In terms of the Stephen> "sondes going to sleep", this is based on concerns expressed Stephen> by the lab along the lines of "if you hook-up the sonde and Stephen> let it sit too long, you have to start over because it will Stephen> turn itself off." Oh, this shouldn't be a problem, unless you have to do something funky to bring it back to life. I assume that the scientists hook up a sonde, run (walk, saunter...) back to the PC and start they're interaction over the serial line to configure sutff? And if they walk away for a coffee and the Sonde waits at a prompt too long, it shuts down? In that case, expect will do just great, since you'll be automating all the boring parts of talking to these things. Stephen> Also, I use the term "vanilla" a lot because the staff aren't Stephen> computer types - this has to "just work" like any other tool Stephen> in the lab. Dear lord - we are talking about biology types Stephen> after all! ;-) (Unlike engineering/geoscience types!!) Hey, Biologists are scientists too! They just like squishy living stuff more than the cold hard electrical stuff we like. :] Stephen> So, the other question was about the necessity of having Stephen> certain signals present. Again, I'm told that the sonde Stephen> needs all the signals present in a DB-9. I'm guessing this Stephen> may have more to do with not really knowing for sure and Stephen> erring on the side of caution, but since there is hardware Stephen> available that will do this and I can't spend all of my time Stephen> chasing this down, I'll assume the information I'm getting on Stephen> this topic is correct. (Biologists not withstanding.) Just do a quick test with a standard calbe and you'll know more. Stephen> I think this is where the multiport boards or a terminal Stephen> server would come in... One of the replies mentioned writing Stephen> a script, and that is what I was thinking about... Stephen> Specifically, I was wondering if it could be as simple as a Stephen> script sending the proper bit patterns to get the sonde to do Stephen> the right things, pipe the serial data through the script and Stephen> append the data to a file, and s on... (Was that you, John?) Yup, that was me. And don't get too low level here, you won't be sending bit patterns, not unless these things are more cryptic than has been made out to be. Could you fire up a copy of hyperterm and take a log of some sample interaction with these devices? THat would answer alot of questions. Stephen> Anyway, I'll have to take a look at the product references Stephen> mentioned and contemplate what I might need to do in the Stephen> world of scripting... I haven't heard back from the Stephen> manufacturer yet, but I'm hoping this will turn out to be a Stephen> simple project when all is said and done!! Also, I haven't Stephen> used a terminal server before, so that should be interesting Stephen> as well. Just hook one Sonde upto a linux box using serial port /dev/ttyS1 and fire up kermit like this: > kermit -l /dev/ttyS1 c-kermit> set speed 9600 c-kermit> c <hit return> a couple of times and see what happens. You can escape back to the c-kermit mode with Control-\ I think, It will tell you. Thne you can try other speeds. You might have to do: c-kermit> set carrier-watch off if it whines at you about that. Or change the speeds, etc. Just find out what settings they use in hyperterm and you'll be all set. Really, this isn't going to be that hard at all. And just automating this process will make you alot of friends down there in the lab. Cheers, John

May 22, 2007

Re: [Wlug] Setting up PXE/TFTBoot

by Mike Leo

no, but i bet these guys have some doc's for you http://www.ltsp.org/ ----- Original Message ---- From: Tal Cohen <wlug(a)cohen123.com> To: wlug(a)mail.wlug.org Sent: Tuesday, May 22, 2007 9:34:32 AM Subject: [Wlug] Setting up PXE/TFTBoot  I know that this is not new technology….but I am having quite a time figuring this out. I was hoping that you guys could give me a hand. In my office, I want to setup a system that will provide a boot image over the network so that I can remotely setup and configure new servers. I am running Crux2.3. Does anyone have experience setting up remote booting systems? Thanks, Tal _______________________________________________ Wlug mailing list Wlug(a)mail.wlug.org http://mail.wlug.org/mailman/listinfo/wlug

May 22, 2007

Re: [Wlug] Setting up PXE/TFTBoot

by Adam Keck

Hello Tal, I use PXE frequently at work. Can you explain your process and where you run into trouble? -Adam On 5/22/07, Tal Cohen <wlug(a)cohen123.com> wrote: > > I know that this is not new technology….but I am having quite a time > figuring this out. I was hoping that you guys could give me a hand. > > > > In my office, I want to setup a system that will provide a boot image over > the network so that I can remotely setup and configure new servers. > > > > I am running Crux2.3. > > > > Does anyone have experience setting up remote booting systems? > > > > Thanks, > Tal > > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug > >

May 22, 2007

Re: [Wlug] It boots. Now what?

by John Stoffel

ken> I would like to get X11 services. I did an "emerge xterm". Here's what ken> happened. ken> ------------start snip------------- ken> (chroot) livecd proc # emerge xterm ken> Calculating dependencies | ken> !!! All ebuilds that could satisfy ">=x11-proto/xproto-7.0.6" have been ken> masked. ken> !!! One of the following masked packages is required to complete your ken> request: ken> - x11-proto/xproto-7.0.7 (masked by: ~sparc keyword) ken> - x11-proto/xproto-7.0.10 (masked by: ~sparc keyword) ken> - x11-proto/xproto-7.0.9 (masked by: ~sparc keyword) ken> For more information, see MASKED PACKAGES section in the emerge man page or ken> refer to the Gentoo Handbook. ken> (dependency required by "x11-libs/libX11-1.1.1-r1" [ebuild]) ken> --------------end snip---------- ken> What do I make of this? It looks to me like you've turned off X11 support into your Gentoo config file(s) somewhere. I haven't used Gentoo in years and years, but I remember there was some place to set up defaults. In this case, you could also just try doing: emerge x11-libs and see what happens. Hmmm... google is your friend here. Look at /etc/portage/packages* and add or remove the lines which are blocking the X11 install. ken> Another problem. My livecd prompt and my chroot prompt both see ken> my ethernet card, eth0. However my new boot does not see the ken> card. Ideas? Send the output of dmesg after boot from both a working and non-working setup. Sounds to me like you haven't compiled the proper driver in your kernel for the hardware. John

May 22, 2007

Setting up PXE/TFTBoot

by Tal Cohen

I know that this is not new technology..but I am having quite a time figuring this out. I was hoping that you guys could give me a hand. In my office, I want to setup a system that will provide a boot image over the network so that I can remotely setup and configure new servers. I am running Crux2.3. Does anyone have experience setting up remote booting systems? Thanks, Tal

May 22, 2007

It boots. Now what?

by ken jones

I would like to get X11 services. I did an "emerge xterm". Here's what happened. ------------start snip------------- (chroot) livecd proc # emerge xterm Calculating dependencies | !!! All ebuilds that could satisfy ">=x11-proto/xproto-7.0.6" have been masked. !!! One of the following masked packages is required to complete your request: - x11-proto/xproto-7.0.7 (masked by: ~sparc keyword) - x11-proto/xproto-7.0.10 (masked by: ~sparc keyword) - x11-proto/xproto-7.0.9 (masked by: ~sparc keyword) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "x11-libs/libX11-1.1.1-r1" [ebuild]) --------------end snip---------- What do I make of this? Another problem. My livecd prompt and my chroot prompt both see my ethernet card, eth0. However my new boot does not see the card. Ideas? Ken Jones

May 22, 2007

Re: [Wlug] [Fwd: Re: Multiple RS232 Com Ports...]

by Stephen Daukas

Hi all! Lots of good info... I hadn't stopped to think about a terminal server! OK, lets see about answering some of the questions... - - - - - - Yes, cabling will be fun. The sondes are used for sampling water... The sondes we use are cylinders approximately 2.5 feet in length and about 3 inches in diameter (one, called "big Bertha", is about six inches in diameter) . One end has a data connection that uses a round, screw-on, water tight serial connector, and the business end has several sensors sticking out (optical, chemical, conductivity, a little propeller for mixing water to be sampled, etc., etc.), all within a screw-on cage that protects the sensors from stuff like rocks passing by in the current (fast currents equate to rather large rocks). The idea is to have a tank of water (fish tank, cooler, whatever) fitted with Plexiglas that has multiple holes through which the several sondes are positioned upright, data end pointing up, with a bunch of cables hanging in-place above each sonde - think of the device that sets the bowling pins in place at the end of the alley... Anyway, you place a bunch of sondes into the tank (that has circulating water being maintained at a precise temp, % dissolved Oxygen, and so on), plug each sonde into the cable available directly above it, and then go to the *insert Linux solution here* and initiate communication, data upload, and calibration routines. (By the way, the tank is just about done - its is being debugged as we speak.) After upload and calibration (using the water in the tank), configure each sonde for the next deployment (how often to sample, etc.), turn them off, unscrew the cables and screw on a waterproof cover, remove them from the tank, and place the entire sonde into another protective chamber (6" PVC pipe with holes drilled in a specific pattern and capped on both ends) for another few weeks in some river/lake/coastal location. - - - - - - Yes, I may be confusing myself regarding "I/O device driver" versus "driver" for the sonde... However, I'm pretty sure that all I need is a vanilla "RS232 device driver" that will "just work" for any number of "com" ports by allowing some vanilla terminal emulation package (preferably one that has scripting capabilities) to talk to multiple RS232 ports. I could be wrong about this, in which case I may need to write some code, or perhaps the manufacturer might be thinking of supporting Linux. I don't do the day-to-day instrumentation work, but I am supposed to worry about it none the less. In terms of the "sondes going to sleep", this is based on concerns expressed by the lab along the lines of "if you hook-up the sonde and let it sit too long, you have to start over because it will turn itself off." Also, I use the term "vanilla" a lot because the staff aren't computer types - this has to "just work" like any other tool in the lab. Dear lord - we are talking about biology types after all! ;-) (Unlike engineering/geoscience types!!) - - - - - - So, the other question was about the necessity of having certain signals present. Again, I'm told that the sonde needs all the signals present in a DB-9. I'm guessing this may have more to do with not really knowing for sure and erring on the side of caution, but since there is hardware available that will do this and I can't spend all of my time chasing this down, I'll assume the information I'm getting on this topic is correct. (Biologists not withstanding.) I think this is where the multiport boards or a terminal server would come in... One of the replies mentioned writing a script, and that is what I was thinking about... Specifically, I was wondering if it could be as simple as a script sending the proper bit patterns to get the sonde to do the right things, pipe the serial data through the script and append the data to a file, and s on... (Was that you, John?) - - - - - - - Anyway, I'll have to take a look at the product references mentioned and contemplate what I might need to do in the world of scripting... I haven't heard back from the manufacturer yet, but I'm hoping this will turn out to be a simple project when all is said and done!! Also, I haven't used a terminal server before, so that should be interesting as well. Thanks! If you have any more thoughts, please let me know!! Steve On 5/21/07, Stephen C. Daukas <scd(a)daukas.com> wrote: > > > > -------- Original Message -------- Subject: Re: [Wlug] Multiple RS232 > Com Ports... Date: Mon, 21 May 2007 15:44:09 -0400 From: John Stoffel > <john(a)stoffel.org> <john(a)stoffel.org> Reply-To: Worcester Linux Users > Group <wlug(a)mail.wlug.org> <wlug(a)mail.wlug.org> To: Worcester Linux Users > Group <wlug(a)mail.wlug.org> <wlug(a)mail.wlug.org> References: > <4650752A.1020203(a)daukas.com> <4650752A.1020203(a)daukas.com> > <18001.54171.525952.976484(a)stoffel.org><18001.54171.525952.976484(a)stoffel.org> > <20070521181244.GH4900(a)angus.ind.WPI.EDU><20070521181244.GH4900(a)angus.ind.WPI.EDU> > > Chuck> On Mon, May 21, 2007 at 01:15:07PM -0400, John Stoffel wrote: > >> darn good things about the Cyclades stuff as well. Stay away from the > >> Legacy Avocent (who bought Cyclades...) serial port stuff, it's crap. > > Chuck> Hmm I have to disagree here. We have the Avocent/Cyclades ACS line > Chuck> and are very happy with them. They run Linux inside and support many > Chuck> connection protocols, like Telnet, SSH, Reverse Telnet, Bidirectional, > Chuck> etc. Full RTS/CTS control lines including DTR are available. They > Chuck> support console logging to RAM, PCMCIA flash card, or remote syslog. > > Chuck> Perhaps you are referring to their older Cyclades TS line. > > I'm talking about the old Avocent designed CPS line of crap. You're > talking about the Cyclades designed stuff, including the TS and the > ACS. > > I've got an ancient Cyclom-Y ISA 8-port serial card in my main home > computer and it's been working great for for years. Wish I could > afford the newer stuff. > > John > > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug > >

May 22, 2007

Re: [Wlug] Multiple RS232 Com Ports...

by John Stoffel

Chuck> On Mon, May 21, 2007 at 01:15:07PM -0400, John Stoffel wrote: >> darn good things about the Cyclades stuff as well. Stay away from the >> Legacy Avocent (who bought Cyclades...) serial port stuff, it's crap. Chuck> Hmm I have to disagree here. We have the Avocent/Cyclades ACS line Chuck> and are very happy with them. They run Linux inside and support many Chuck> connection protocols, like Telnet, SSH, Reverse Telnet, Bidirectional, Chuck> etc. Full RTS/CTS control lines including DTR are available. They Chuck> support console logging to RAM, PCMCIA flash card, or remote syslog. Chuck> Perhaps you are referring to their older Cyclades TS line. I'm talking about the old Avocent designed CPS line of crap. You're talking about the Cyclades designed stuff, including the TS and the ACS. I've got an ancient Cyclom-Y ISA 8-port serial card in my main home computer and it's been working great for for years. Wish I could afford the newer stuff. John

May 21, 2007

Re: [Wlug] Multiple RS232 Com Ports...

by Mike Frysinger

On 5/21/07, Stephen Daukas <scd(a)daukas.com> wrote: > The *how* is the heart of my question... If you mean how physically, that's > a matter of cable and such. what sort of magic cable ... ive seen implementations where it's a pci card that hooks up in the back to some octopus monstrosity which is where the rs232 comes in ... > The driver question is, again, what I was looking into. If Linux has > support for multiple RS232s built in > to one or more generic drivers in a given distro, then we are talking about > terminal emulation - a.k.a. > VT100 or ANSI or whatever. you're confusing things i think ... the kernel has drivers for different devices and that driver exports the multiple device nodes in /dev/ for userspace to utilize the important part is making sure a driver exists for your hardware in terms of other serial devices, there are no real limits in the tty layer > How do the RS232 FIFO/Interrupts get managed via USB? In other words, each > of the RS232s will need to have its "pin-outs" (DB-9) active so the sondes > believe they are connected in order to avoid their "turning off". the driver worries about it ? userspace just sees a serial device in /dev/ for it to open/configure/write ... if you're interested in looking at the actual implementation, you should just read the device driver in the kernel source -mike

May 21, 2007