SuSE Linux 7.0
The partitions are set up, and we move to the installation of 341 packages. As the install progresses, you get a typical status screen displaying the package name being installed, a short description, and an overall progress update and percentage of disk space consumed. The installation I selected uses a little over 1GB of space.
At 242 packages, I am informed that the LILO boot sector has been set up, and I can restore the old one with the command:
lilo -u /dev/hda
Then the installer starts the new system, and a text screen tells me the base system has been successfully installed. The graphical YaST2 continues, asking for CD2, then resumes installing packages. Another pause at package 326, and I'm asked for CD3. Another pause at 331 for CD4.
Now we move on to X set up. I am asked for my monitor, a Mag MX17, and then the video card, which it correctly identifies as an ATI and sets for 1240x1168@16bpp. I try the test at this resolution, my color palette shifts to an unusual look and the system appears to lock up. I can't switch to a different VT, nor does CTL-ALT-Backspace or CTL-ALT-DEL have any effect, so I resort to the reset button. The system boots into SuSE and runs checks on the file systems since it wasn't shut down properly, then gets me back into YaST2 at the monitor configuration. This was nice. Even though I hit a major problem, the install recovered and resumed where I left off. This time I try a more conservative setting, 640x480@8bpp—and get a black screen and another lockup. Hmm. Seems the ATI driver has a problem with my card. There is no option to override with a generic SVGA card, so I opt for no X11 and move on. The install does tell me I can set X up later with SaX.
From here, YaST2 moves on to setting up the printers, sound, Internet and network. I do not have a modem on this machine, and YaST2 tells me it has not detected a modem or ISDN adapter. It does recognize my Creative sound card and my 3Com NIC. I go ahead and set up my IP address with the default gateway through my file server and a host name with DNS pointing to my ISP's name servers. The install checks to certify that I have entered valid IP addresses.
YaST2 tells me the NIC was configured correctly and networking is set up, which I verify by pinging the box from my file server. Looks good!
The sound card setup allows me to set the volume and test, and it plays a nice little orchestral piece—good again! Later on I look at the loaded modules, and it looks like sound is handled by ALSA.
For printing, I have an HP print server on the LAN with a NEC Silentwriter and an HP Deskjet 693C. The installer scanned the local LAN for hosts and failed to find anything, probably because I'm not running DNS on the server. Since I have a custom lpr script on the server that powers up my printers via an X10 control module when I need to print, I route the print jobs to the file server, using its IP address, and it takes care of the filtering too. One minor annoyance here is the first network printer is called “remote” with no opportunity to override that name except on the second printer. I would rather have preferred setting it to something more descriptive.
That was it on this screen, so I moved on to “Finish Installation”, and was told I could log in as “stew”. The manual reminds you to change your BIOS settings back to boot from hard drive and/or floppy.
I log in, do a ps -ax to see what is running—looks normal enough, httpd, lpd and several copies of nscd, which the man pages tell me is a name server caching dæmon—okay. lynx localhost gets me to some local SuSE pages—good. My server is on line, so I try lynx on some remote web pages, and they come up too. Looks like networking is working fine.
I take a quick visit to the SuSE web site and search their support database to see if I see anything on my X issues, but the info seems to refer only to SuSE6.4 and older versions, so I forge ahead on my own.
To see if I could pick up anything on my X issues I do an
rpm -q -a | grep mach
from the command line. I see the following:
xmach64-3.3.6-44This explains my problems since YaST2 was trying to use the XFree4.0 server. Doing a similar search on xf
rpm -q -a | grep xf86 xf86-4.0-55 xf86_3x-3.3.6-44It looks like sticking with XFree3.3.6 would be the wise thing to do. I log out and re-log in as root to finish setting things up.
I was able to run SaX from the command line and correctly configure XFree3.3.6 by manually choosing my ATI video card, an Xpression card. Then I was able to fine tune the settings and get it set up for 1024x768@16bpp. The card is an older card with only 2MB VRAM, so this is about as good as it gets. Running startx, I am in the KDE desktop. SaX uses XFree 3.3.6 vs. SaX2, which uses XFree4.0.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide