WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: How to guide : Eject dCore boot cd  (Read 140 times)

Offline Darren

  • WikiUser
  • *
  • Posts: 1
How to guide : Eject dCore boot cd
« on: September 14, 2017, 07:15:56 AM »
By default dCore jessie and maybe older versions contain a slightly bugged version of busybox that failed to eject the boot cd when the eject command is sent.

After talking to Jason W we have found a temporary work around until busybox is fixed and updated which is to use the Debian version of the eject command using the following commands.

sce-import eject
sce-load eject
eject /dev/sr0

also you may want to add alias eject="eject /dev/sr0" to your .ashrc file as by default the eject command will try to eject /dev/cdrom which does not exist by default (atleast from my testing)

Offline Jason W

  • Administrator
  • Hero Member
  • *****
  • Posts: 9307
Re: How to guide : Eject dCore boot cd
« Reply #1 on: September 16, 2017, 05:08:52 PM »
A new update to the x86 dCore ports now creates the /dev/cdrom and /dev/dvd symlinks.  Refer to the release candidate announcements thread.

This seems to fix the Busybox eject issue, works as expected on my box.  Please test and report any issues.
« Last Edit: September 16, 2017, 05:18:32 PM by Jason W »

Offline Jason W

  • Administrator
  • Hero Member
  • *****
  • Posts: 9307
Re: How to guide : Eject dCore boot cd
« Reply #2 on: September 16, 2017, 06:05:16 PM »
An observation, with the latest update to dCore, removing the /dev/cdrom symlink causes the same behavior with the Busybox in the dCore ports as the Busybox in Core 8.x when /dev/cdrom is deleted.  Removing the /dev/cdrom symlink in dCore and Core 8.x still allows the ejecting of the cd with the command "eject /dev/sr0" when only Busybox eject is available.  So it may not be a difference in the Busybox versions but the need for the udev rules just added in dCore. 

I will update Busybox in the near future, but not for the existing dCore ports as a stable release in dCore means keeping the same kernel and Busybox version for it's lifecycle.  dCore script updates are different as they are portable and easily tuned.  Perhaps soon in dCore-artful and forward I will use an updated Busybox since it still exists only in the release candidate phase.