In Virtual Box (version 4.3.28.100309 on Gentoo) any successful use of the"eject" command makes important parts of the system unusable. An easy test is to boot to runlevel 3 with the"toram" option. Then login to a virtual console and run the commands:I've attached a screenshot of what happens here.

I'm hoping this is just an artifact due to Virtual Box or the particular version of Virtual Box I'm using, or my Virtual Box configuration.

Can anyone else replicate this problem in Virtual Box?

More importantly: can anyone replicated this problem on real hardware? I don't know if you need to boot from a LiveCD in order to cause the error. You could certainly try to reproduce the error booting from a LiveUSB and running eject and then poweroff.

Recipe:

1. Boot using"toram" and"3" (in Virtual Box or with a LiveCD)
2. Log in as root in a virtual console
3. Run the commands:

   Code: Select all

   eject -v /dev/sr0
   poweroff

If the problem only exists in Virtual Box (or in certain versions of Virtual Box) then I can easily work-around it by disabling automatic toram-eject if we detect the system is running on Virtual Box.

PS: I could not replicate the problem with MX-14.4.

Using an USB key, the poweroff command worked on real hardware.
Henry

Thanks Henry! That's encouraging.

I'm duplicating your error on real hardware (the HP in my sig) running off a 4gb usb stick. No persistence.

also, after ejecting the usb stick, I could no longer open a terminal window or logout/powerdown from the icewm menu. I resorted to the cli and running sudo poweroff, resulting in the identical input/output error you received.

I'm getting the poweroff error in Virtualbox (using M11). The same error message for the reboot command.
Henry

Thanks D.O.! This is a serious issue IMO since running"eject" borks the system.

Is anyone able to test and see if the same problem exists on an installed system?

Also, please check the output of the dmesg command (if your system is not wedged). Something like:should suffice.

I see nothing in dmesg right after running eject and then I wedged the machine with"poweroff".

@D.O. Does your HP use apm? An easy way to test this is to try to power-off from inside the bootloader using F10 --> poweroff. The reboot works on all/most systems but poweroff only works on older apm systems.

If it is apm related, I could disable toram-eject on systems that use apm and we could list this as a very big known bug.

I've followed up on the apm angle and I saw that CONFIG_APM is not set in our rc1.1 kernel but it is set in the MX-14.4 kernel which does not have this problem. BUT, I can't even load the apm module inside of Virtual Box (using MX-14.4) so it seems unlikely that the lack of this module is causing the problem.

ATM the only way I know how to detect apm is to try F10 --> shutdown in the Live bootloader.

Bad news.

Running on real hardware via cd F4 toram option. Same as d_o

Does F10 --> shutdown in the bootloader work?

BitJam wrote:Does F10 --> shutdown in the bootloader work?

not on the HP.

More info:

I'm having a lot of trouble running apps whenever toram is used and the media is ejected. So far, apps that I've launched prior to ejecting the media still launch, but other apps do not.


also tried with acpi=off, and while"halt" worked some of the time with the media ejected, and all the time with the media in place, my machine did not actually poweroff.

edit ***still more info***

playing around a little more, and after eject, for instance, I've have never run geany, and if I run geany from the terminal after the media eject, I get the same input/output error BitJam sees for shutdown in his test in the original post. However, apps that I ran before eject (terminal, rox, spacefm, and leafpad) still worked.

So I'm thinking this is not related to kernel modules (except aufs I guess) but rather in the mechansim be which the linux file system put into ram.

FWIW, all tests I did were nosavestate, toram, no persistence selected.

Some Questions

• Does the problem exist on installed systems?
• Does it exist on systems booted via LiveUSB (when you eject the cd/dvd drive)?
• When did the problem start (kernel, antiX version)?

I just tested antiX-14-a3-RV_x64-full with kernel 3.17.0 in Virtual Box and it did not have the problem. Nor did I see the problem in antiX-15-beta1 with the 3.19.1 kernel.

Strange - antiX-14-a3-RV_x64-full doesn't work on my box. but antiX-15-beta1 did.

antiX-15-beta1 worked but antiX-15-beta2 did not. They both have the same 3.19.1 kernel with identical configurations. This points to a change in the userland tools. Maybe we will get very very lucky and be able to fix this by pinning some packages to older versions.

antiX-15-beta1 only works when booting to init 3 with toram, login as root, eject -v /dev/sr0, halt

If I boot to desktop with toram, and choose yes at both eject cd prompts, then try to logout from the menu, it fails

BitJam wrote:Some Questions

• Does the problem exist on installed systems?
• Does it exist on systems booted via LiveUSB (when you eject the cd/dvd drive)?
• When did the problem start (kernel, antiX version)?

I just tested antiX-14-a3-RV_x64-full with kernel 3.17.0 in Virtual Box and it did not have the problem. Nor did I see the problem in antiX-15-beta1 with the 3.19.1 kernel.

Does the problem exist on installed systems?

No, at least not on mine.

Does it exist on systems booted via LiveUSB (when you eject the cd/dvd drive)?

not so far as I can tell. I ejected a disk in the drive with the liveusb running, didn't encounter any problems.

From what I can see, is the stick even still mounted after the linuxfs is loaded to the toram? I see a boot message for"Late umount ...sdb1".

I can't see where my stick is mounted (/media/sdb1 is not mounted, nor is there a /live/boot-dev

assuming the stick isn't mounted in the first place, then just pulling the stick is enough to cause the behavior (no eject statement).