The 'fubarage' of this package is such that it should require an
affirmative effort to inflict it on users.
Please consider removing it from all install lists except "Everything" and
I concur. All you have to do to break it is to swap CDs without closing all gmc
windows, on a SCSI CD-ROM. Just try swapping in Fisher SRPM cd after Fisher i386
CD #1 (with making sure that gmc initially opens a directory on the CD #1).
Can you give more details about what goes wrong with gmc and SCSI
CD-ROMS? (I've seen a mention of dialog windows with "garbage"
in them in another bug report.)
[ We probably could swap things around, but I don't have any
workstations with SCSI CD-ROMS immediately to hand. ]
As for removing it from the "everything install", I think this
would remove useful functionality from most desktop users
for the sake of avoiding problems that 1% of the users (at
most) hit. The problems I'm aware of are:
- The kernel spews unnecessary stuff to the syslog at level
debug. (#6006) The default Red Hat syslog configuration doesn't
log these messages, but some users change their config
and sees them.
- A while ago, there were some reports of corruption when
magicdev opened a cd-rw device while a disk was being
written. I haven't seen any reports of this recently,
so it's possible its been fixed in the kernel.
- Some reports of magicdev keeping APM from powering down
- Some mentions of bad interactions with gmc and
SCSI with magicdev installed. (I think this has nothing to do
with magicdev, other than magicdev is telling MC
that a CD has been inserted and it should open a new
window.) I don't have enough information currently on
this to know what is going on exactly.
That's a fairly long list, but none of them will be
seen by a large proportion of users, and except for the
CD-RW one, they are more annoyances than fatal flaws.
Here is one thing that will be seen by everybody: Magicdev spews
1 Hertz junk into "dmesg" ... rendering any content of dmesg totally
useless. This will make it difficult if not impossible to support
users out there, because critically useful information is rapidly
I consider this specific issue to be a "fatal flaw."
On my system magicdev never unmounts a CD it mounted, even if it is not in use
and a manual umount works.
So unless I manually umount each CD before I eject it, I get VFS errors,
because a mounted volume was changed.
I have an ATAPI CDROM, but I don't think it's relevant.
From testers list Chris Runge
> SCSI appears to be fine. However, I noticed that I get a ton of messages in
> /var/log/messages and to the root console when I go into GNOME and the SCSI
> CD-ROM doesn't have a disc in it. These end when I exit GNOME. Any ideas?
- The 1hz (or, actually, 2hz) junk to dmesg (#6006) is very much
fixable by commenting out the message in the kernel, and we'll
put that or some other fix in.
- The problem with being able to eject mounted volumes has been
- The problem with (some?) SCSI devices generating excess spew (#26055)
needs further investigation, and seems to have to do with
devices not correctly reporting whether they have a disk in
On 8 Feb 2001, Owen Taylor wrote:
> Not at all to blame you for this - magicdev probably _isn't_
> something you need.
> [For the newbie] first
> confronted with Linux, the functions provided by magicdev -
> automounting, opening a file manager window, prompting for the autorun
> script, etc, really do make things significantly simpler.
And so, Owen, you concur in my case ... that the RFE is
correct; to remove it from the default Workstation install
state; and place it only in the "Everything" install (again a
'Newbie' mistake which "really does make things significantly
simpler" -- at the expense of security, conformance to the
principle of Least Surprise, system log chatter, and the
Packagers: Bugzilla assigned it to Owen, for he is the lead
package maintainer ... and if and when it is 'ready for prime
time,' it may return to being part of a Workstation default
install -- but for RH 7.1, just as the newbie friendly 'joe'
editor requires express selection in (since at least RH 5.0),
so also should magicdev.
The other issue is that most folks who want to use CD burners, switching to the
next disk becomes a pain -- if you can even get magicdev to let go of the
drive. Sun had a volume manager that you could at least manually tell "go check
the drive & mount it if possible", though they didn't really have a good
solution to the CD burner crowd (i.e., leave yer grubby paws off that device,
From terstes list
Subject: Re: scp slows to a crawl if magicdev is running
Sam Varshavchik <firstname.lastname@example.org> writes:
> On Sat, 24 Feb 2001, Marty Shannon, RHCE wrote:
> > open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = 9
> > ioctl(9, CDROM_DRIVE_STATUS, 0x7fffffff) = 2
> > close(9) = 0
> Oh, so THAT'S why this bleeping thing keeps filling my syslog with this:
> Feb 24 17:31:08 localhost kernel: Device not ready. Make sure there is a
> disc in the drive.
> Feb 24 17:31:40 localhost last message repeated 16 times
> Feb 24 17:32:41 localhost last message repeated 30 times
> Feb 24 17:33:43 localhost last message repeated 31 times
Date: Sun, 04 Mar 2001 14:26:47 -0500
From: Chris Runge <email@example.com>
Subject: Re: RC2: mouse slow when CD playing
R P Herrold wrote:
> On Sun, 4 Mar 2001, Chris Runge wrote:
>> Anyone notice this problem: On RC2 if I play a CD under X the mouse
>> jitters a lot (this is using the built-in GNOME CD player). If I play
>> the CD under cdp in a console session on another vt, however, I have no
>> such problems with the mouse under X.
> What does dmesg say?
I realize this isn't very scientific, but after doing the following the
problem doesn't occur:
(1) rpm -e magicdev
(2) recompile kernel, changing taq command queuing depth (i think that
is what it is) to 32 (from 253) for the new aic7xxx driver (and changing
(3) reboot using new kernel
dmesg says this:
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 3, lun 0
(scsi1:A:3): 40.000MB/s transfers (20.000MHz, offset 15, 16bit)
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
This is with it working, but I saw similar output before when the
problem was occurring.
Magicdev impairs cdrecord bug added:
Events have overtaken this bug -- closing