Hi!
I'm putting together a maintenance/rescue CD. It's bootable with
RH6.2 (2.2.16) "installed" - ie the root fs is on the CD itself, no
harddrives involved. I've run across a slight inconvenience:
when I shutdown the CD is still locked in the drive. I have to power-off
then power-on again to get the CD out of the drive. Is there any way
I can get the kernel to unlock the CD and even possibly eject it
on shutdown? If kernel-hacking is required could somebody please
point to where it should be done? (I'm not very familiar with the
kernel-layout).
TIA,
Per Erik Stendahl
Hello Per , Has anyone gotten back to you on this subject ?
I as well am very interested in any information about releiving
this difficulty . Tia , JimL
On Wed, 21 Feb 2001, Per Erik Stendahl wrote:
> Hi!
> I'm putting together a maintenance/rescue CD. It's bootable with
> RH6.2 (2.2.16) "installed" - ie the root fs is on the CD itself, no
> harddrives involved. I've run across a slight inconvenience:
> when I shutdown the CD is still locked in the drive. I have to power-off
> then power-on again to get the CD out of the drive. Is there any way
> I can get the kernel to unlock the CD and even possibly eject it
> on shutdown? If kernel-hacking is required could somebody please
> point to where it should be done? (I'm not very familiar with the
> kernel-layout).
> TIA,
> Per Erik Stendahl
+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+
On Wed, 28 Feb 2001, Mr. James W. Laferriere wrote:
>
> Hello Per , Has anyone gotten back to you on this subject ?
> I as well am very interested in any information about releiving
> this difficulty . Tia , JimL
Such a CD would be very nice; one or two people do have this already,
though. Have you tried using a ramdisk for root, and mounting the CD as
/usr?
James.
Hello James , Yup that works alright . But the difficulty
Per & I were talking about is after the system (such as
slackware's live-fs) is -shutdown- the CD drive bay is still
locked , One has to hard-reset (or even power off for some)
before the bay will open . I am well aware why the bay does
not open while the live-fs has it mounted . But am quite
baffled as to why the darn thing remains locked after system
shutdown . Again I am quite sure I know why that is happening
as well . The live-fs is hard read-only and the umount of the
live-fs can not complete , so the CD drive never receives an
unlock . Sound about right ? Twyl , JimL
On Wed, 28 Feb 2001, James A. Sutherland wrote:
> On Wed, 28 Feb 2001, Mr. James W. Laferriere wrote:
>
> >
> > Hello Per , Has anyone gotten back to you on this subject ?
> > I as well am very interested in any information about releiving
> > this difficulty . Tia , JimL
>
> Such a CD would be very nice; one or two people do have this already,
> though. Have you tried using a ramdisk for root, and mounting the CD as
> /usr?
>
>
> James.
>
+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+
Oops, I almost missed this one. High-volume mailinglists... :-)
> > Hello Per , Has anyone gotten back to you on this subject ?
> > I as well am very interested in any information about releiving
> > this difficulty . Tia , JimL
> >
> Such a CD would be very nice; one or two people do have this already,
> though. Have you tried using a ramdisk for root, and mounting
> the CD as
> /usr?
Well, doing this on your own certainly will teach you a lot about
Linux I tell you. :-)
I still dont know how to make the kernel unlock and eject the CD on
shutdown. I haven't been able to pinpoint the shutdown sequence in
the kernel sources yet. :-)
What I do know now is how to make the kernel not lock the CD in the
first place. Simply ioctl(/dev/cdrom, CDROM_CLEAR_OPTIONS, CDO_LOCK)
from /linuxrc in the initrd. This way I can remove the CD anytime
I please which is enough for me. And I dont have to patch the kernel.
Mounting a ramdisk for / is doable (I think) but kludgy since you have
to symlink or mount so many subdirectories. Right now I only have /var
in a ramdisk (and why _WHY_ is /etc/mtab located in /etc and not
in /var??).
Anyways the CD works - and yes, being able to boot Linux w/o touching
the harddrives or the network is nice! :-) I might even put it on the
web once I get it cleaned up. Though the ISO is ~200 Mb.
Cheers
/Per Erik Stendahl
Hello Per , Yah I can understand high volume lists ;-)
But combined with the dropping of a copy of the iso-image
you create , A Howto ??? Please . Tia , JimL
On Wed, 28 Feb 2001, Per Erik Stendahl wrote:
> Oops, I almost missed this one. High-volume mailinglists... :-)
> > > Hello Per , Has anyone gotten back to you on this subject ?
> > > I as well am very interested in any information about releiving
> > > this difficulty . Tia , JimL
> > Such a CD would be very nice; one or two people do have this already,
> > though. Have you tried using a ramdisk for root, and mounting
> > the CD as
> > /usr?
> Well, doing this on your own certainly will teach you a lot about
> Linux I tell you. :-)
> I still dont know how to make the kernel unlock and eject the CD on
> shutdown. I haven't been able to pinpoint the shutdown sequence in
> the kernel sources yet. :-)
> What I do know now is how to make the kernel not lock the CD in the
> first place. Simply ioctl(/dev/cdrom, CDROM_CLEAR_OPTIONS, CDO_LOCK)
> from /linuxrc in the initrd. This way I can remove the CD anytime
> I please which is enough for me. And I dont have to patch the kernel.
> Mounting a ramdisk for / is doable (I think) but kludgy since you have
> to symlink or mount so many subdirectories. Right now I only have /var
> in a ramdisk (and why _WHY_ is /etc/mtab located in /etc and not
> in /var??).
> Anyways the CD works - and yes, being able to boot Linux w/o touching
> the harddrives or the network is nice! :-) I might even put it on the
> web once I get it cleaned up. Though the ISO is ~200 Mb.
> Cheers
> /Per Erik Stendahl
+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+
In article <[email protected]>,
Per Erik Stendahl <[email protected]> wrote:
>Mounting a ramdisk for / is doable (I think) but kludgy since you have
>to symlink or mount so many subdirectories. Right now I only have /var
>in a ramdisk (and why _WHY_ is /etc/mtab located in /etc and not
>in /var??).
If /var is on a seperate partition, how are you going to access it
if /var hasn't been mounted yet ?
Mike.
--
I live the way I type; fast, with a lot of mistakes.
On Wed, 28 Feb 2001, Mr. James W. Laferriere wrote:
>
> Hello James , Yup that works alright . But the difficulty
> Per & I were talking about is after the system (such as
> slackware's live-fs) is -shutdown- the CD drive bay is still
> locked , One has to hard-reset (or even power off for some)
> before the bay will open . I am well aware why the bay does
> not open while the live-fs has it mounted . But am quite
> baffled as to why the darn thing remains locked after system
> shutdown . Again I am quite sure I know why that is happening
> as well . The live-fs is hard read-only and the umount of the
> live-fs can not complete , so the CD drive never receives an
> unlock . Sound about right ? Twyl , JimL
The point is, if you mount the CD as /usr, you should then be able to
unmount it properly on shutdown...
James.
Per Erik Stendahl wrote :
> What I do know now is how to make the kernel not lock the CD in the
> first place. Simply ioctl(/dev/cdrom, CDROM_CLEAR_OPTIONS, CDO_LOCK)
> from /linuxrc in the initrd. This way I can remove the CD anytime
> I please which is enough for me. And I dont have to patch the kernel.
Or : echo 0 > /proc/sys/dev/cdrom/lock
( I am not sure if this is the right filename )
Or run magicdev ;-)
--
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
David Balazic wrote:
Per Erik Stendahl wrote :
> What I do know now is how to make the kernel not lock the CD in the
> first place. Simply ioctl(/dev/cdrom, CDROM_CLEAR_OPTIONS, CDO_LOCK)
> from /linuxrc in the initrd. This way I can remove the CD anytime
> I please which is enough for me. And I dont have to patch the
kernel.
Or : echo 0 > /proc/sys/dev/cdrom/lock
( I am not sure if this is the right filename )
Or run magicdev ;-)
This might save everyone some pain:
from hdparm(8) man page (mine has some format
bugs, but you get the picture)
-L Set the drive's doorlock flag. Setting this to
will lock the door mechanism of some removeable
hard drives (eg. Syquest, ZIP, Jazz..), and setting
it to maintains the door locking mechanism automat?
ically, depending on drive usage (locked whenever a
filesystem is mounted). But on system shutdown,
this can be a nuisance if the root partition is on
a removeable disk, since the root partition is left
mounted (read-only) after shutdown. So, by using
this command to unlock the door -b after the root
filesystem is remounted read-only, one can then
remove the cartridge from the drive after shutdown.
you seem to be into reading the source (tm) so hdparm's
might be a good place to look (if it doesn't just work like it
says above)
> > What I do know now is how to make the kernel not lock the
> CD in the
> > first place. Simply ioctl(/dev/cdrom,
> CDROM_CLEAR_OPTIONS, CDO_LOCK)
>
> > from /linuxrc in the initrd. This way I can remove the CD anytime
> > I please which is enough for me. And I dont have to patch the
> kernel.
>
> Or : echo 0 > /proc/sys/dev/cdrom/lock
> ( I am not sure if this is the right filename )
Nah, that looks too easy! ;-)
> This might save everyone some pain:
> from hdparm(8) man page (mine has some format
> bugs, but you get the picture)
>
> -L Set the drive's doorlock flag. Setting this to
> will lock the door mechanism of some removeable
> hard drives (eg. Syquest, ZIP, Jazz..), and setting
> it to maintains the door locking mechanism automat?
> ically, depending on drive usage (locked whenever a
> filesystem is mounted). But on system shutdown,
> this can be a nuisance if the root partition is on
> a removeable disk, since the root partition is left
> mounted (read-only) after shutdown. So, by using
> this command to unlock the door -b after the root
> filesystem is remounted read-only, one can then
> remove the cartridge from the drive after shutdown.
Is it true that the root fs is left mounted read-only? What is the
rationale behind this? It seems to me that it would be better to
completely unmount it and do whatever cleaning up is required (like
cdrom_release()?). But I've been known to miss important issues before!
:-)
BTW, what would be the best way to determine which devices are cdrom
devices? Looks like /proc/sys/dev/cdrom/info could be of use but what
happens on a computer with more than one cdrom device?
Cheers
/Per Erik Stendahl
Per Erik Stendahl wrote:
>
> Nah, that looks too easy! ;-)
>
> > This might save everyone some pain:
> > from hdparm(8) man page (mine has some format
> > bugs, but you get the picture)
> >
> Is it true that the root fs is left mounted read-only? What is the
> rationale behind this? It seems to me that it would be better to
> completely unmount it and do whatever cleaning up is required (like
> cdrom_release()?). But I've been known to miss important issues before!
> :-)
>
> BTW, what would be the best way to determine which devices are cdrom
> devices? Looks like /proc/sys/dev/cdrom/info could be of use but what
> happens on a computer with more than one cdrom device?
>
Read about devfs option in 2.4 kernel. it puts only devices that exist
into /dev/cdroms/cdrom0, dev/cdroms/cdrom1, etc.
and if hdparm works (and it must since redhat's installer ejects it's
cd when rebooting) and you still are looking for a solution, well
no comment.