Bug 25922 - RFE: Remove Magicdev from all except "Everything" install list
RFE: Remove Magicdev from all except "Everything" install list
Product: Red Hat Linux
Classification: Retired
Component: magicdev (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-02-03 18:09 EST by R P Herrold
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-03 15:11:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description R P Herrold 2001-02-03 18:09:27 EST
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
manual selection.
Comment 1 Sam Varshavchik 2001-02-03 19:39:10 EST
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).

Comment 2 Owen Taylor 2001-02-07 16:18:41 EST
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.

Comment 3 Edward Kuns 2001-02-08 02:33:05 EST
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."
Comment 4 David Balažic 2001-02-08 05:52:11 EST
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.
Comment 5 R P Herrold 2001-02-08 10:10:26 EST
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?
Comment 6 Owen Taylor 2001-02-08 11:53:32 EST
- 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
  fixed. (#13628)
- 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
  the drive.
Comment 7 R P Herrold 2001-02-09 16:48:15 EST
On 8 Feb 2001, Owen Taylor wrote:
> Not at all to blame you for this - magicdev probably _isn't_
> something you need.
>    <snip>
> [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.
Comment 8 Marty Shannon 2001-02-22 16:05:54 EST
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,

Comment 9 R P Herrold 2001-02-25 11:34:10 EST
From terstes list

Subject: Re: scp slows to a crawl if magicdev is running
Sam Varshavchik <mrsam@courier-mta.com> 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
Comment 10 R P Herrold 2001-03-04 16:21:21 EST
Date: Sun, 04 Mar 2001 14:26:47 -0500
From: Chris Runge <crunge@phoenixdsl.com>
Reply-To: testers-list@redhat.com
To: testers-list@redhat.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
/etc/modules.conf appropriately)
(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.
Comment 11 R P Herrold 2001-04-03 15:11:28 EDT
Magicdev impairs cdrecord bug added:
Comment 12 R P Herrold 2002-10-28 16:03:45 EST
Events have overtaken this bug -- closing

Note You need to log in before you can comment on or make changes to this bug.