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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development