Best of Technical Support
I have two CD-ROM drives, one recently installed. Before the installation of the second CD-ROM which is an HP 9200i CD_RW, everything mounted okay. Now, when I issue the mount command (mount /mnt/cdrom), I get the following:
CD-ROM I/O error: dev 0b:00,sector 64 isofs_read-super: bread failed,dev 0b:00 iso_blknum 16 block 32 mount: wrong fs type, bad option, bad superblock on /dev/cdrom or too many file systems
Both are SCSI drives. Please help if you can. —Tom Mcloughlin, email@example.com
There are two likely reasons for this problem. Either your “second” CD-ROM is seen as “first”, or the devices are configured to use the same SCSI ID, thus preventing any of them from functioning. Please check how SCSI identifiers have been assigned to the drivers and remember that the smaller ID is considered “first” drive (/dev/sr0) and the bigger ID is considered “second” (/dev/sr1). —Alessandro Rubini, firstname.lastname@example.org
/dev/cdrom is a symbolic link to a device like /dev/scd0 (the first SCSI CD-ROM). The second SCSI CD-ROM will be /dev/scd1. So, when wanting to mount the second CD-ROM, issue the command mount /dev/scd1 /mnt/cdrom, or create new links like /dev/cdrom0 to /dev/scd0 and /dev/cdrom1 to /dev/scd1. Don't forget to update the /etc/fstab, because mount /mnt/cdrom will read the fstab and mount the device allocated to this mounting point. —Paulo J V Wollny, email@example.com
I have the following operating systems installed on my PII Intel 440Bx system: NT4/Windows 98/Linux. While I can print absolutely fine from Windows 98 and NT4 on my HP 670C printer, I cannot do so from Linux. The error I get is “printer port is not recognised”. I have tried using the printtool to force the HP 670C on lp0, lp1 and lp2, respectively, but to no avail. What could be the problem? I have even tried changing the BIOS setting between ECP and EPP. —Sunil Dhaka, firstname.lastname@example.org
Are your printers parallel? If so, you might not have the parallel printer port driver configured correctly. Sometimes with Red Hat, the parallel port is not set up correctly after the installation. Add this line to the /etc/conf.modules file:
alias parport_lowlevel parport_pc
Reinitialize your machine, and your parallel port should now work fine. Configure everything with the printtool utility and send a test page to print. —Felipe E. Barousse, email@example.com
A local user I know, Scott Hettel, recently solved this problem on his own system. He found that Red Hat 6.1 does not support the IBM PC parallel printer port by default. The answer for this is on Red Hat's web site. See bug numbers 5698 and 5821 on their site for the resolution to this problem. You may also want to look at bug 8969, which discusses port compatibility. Please note that these issues affect only version 6.1 of Red Hat. —Chad Robinson, Chad.Robinson@brt.com
I'm trying to use mgetty with a serial port attached to a modem. The port is /dev/ttyS1. The line I put in /etc/inittab is:
S1:2345:respawn:/sbin/mgetty ttyS1Shortly after the system came up after reboot, I received this message continuously at about five-minute intervals:
INIT: Id "S1" respawning too fast: disabled for 5 minutes.Any ideas as to what I'm doing wrong? I'm running Red Hat 6.0. —Chris Yeats, CYeats@limbach.com
The message you get means that Linux starts the mgetty process and for some reason it dies, gets restarted and dies again. The most probable cause is that your modem cable does not have the correct pin wiring to work. Check www.linuxdoc.org/HOWTO/Text-Terminal-HOWTO-17.html#fast_respawn to find out a bit more about the problem. To override the cable problem (but losing modem control features), use the -r option for mgetty, which makes mgetty not monitor and detect the missing pin signals on your cable. I would still buy a good modem cable, though. —Felipe E. Barousse, firstname.lastname@example.org
Your mgetty ttyS1 command exits immediately and init disables its further invocation. You should first make the command work from the command line, where you can check what its error messages are and whether it works as expected. You should put the command in inittab only after your problems (misconfiguration, I suppose) are fixed. —Alessandro Rubini, email@example.com
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!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Returning Values from Bash Functions
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