Also, booting on real hardware a live cd without toram, on reboot, the media is ejected as it should.
On installed system, eject works fine.

I verified that antiX-15-beta1 fails if you boot to X and tell toram-eject to eject.

One trick I've found is that the programs under /live/bin/ still work. So I set"PATH=/live/bin" after the system got borked and I could still run dmesg and tail. I've attached a screen shot of the some of the error messages in dmesg. The rest are similar.

More info:

Boot liveusb with toram option.
Insert a video dvd at desktop
Open a terminal and type mplayer /dev/sr0 - dvd plays.
Stop dvd and in teminal type eject, dvd ejects and no issues rebooting or opening other apps.

I Googled the first error message"vfs busy inodes on changed media or resized disk" and
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://thebigbyte.blogspot.com/2010/02/vfs-busy-inodes-on-changed-media-or.html"
linktext was:"the first hit"
====================================
says:

It means your cdrom drive has been ejected without unmounting.

We've been using lazy umount (-l) in the initrd to umount /live/boot-dev if it no longer needs to be mounted. I've always disliked doing this.

I can try disabling the umount in the live initrd and see if I can umount and eject successfully from the command line after we have booted.

BTW - MX-14.4 doesn't work either with toram and eject once at desktop

antiX-13.2 does work correctly. (64bit no CONFIG_APM in the kernel)

Apologies for cluttering the thread. Topic moved to RC1.1.

samk, you got the wrong thread. can you move your post to the rc1.1 feedback thread?

I've solved the problem. I plan to make a new initd.gz for rc1.1 available later today.

BitJam wrote:I've solved the problem. I plan to make a new initd.gz for rc1.1 available later today.

what was it?, if you don't mind me asking.

I will explain later. I've got a bunch of stuff to do and my English-language module hasn't really kicked in yet today.

BitJam wrote:I will explain later. I've got a bunch of stuff to do and my English-language module hasn't really kicked in yet today.

cool beans.

There was a toram bug fix about a year ago that caused this new bug. The problem is that I needed to mount /live/boot-dev/antiX/linuxfs *before* running the"toram" code. This is what kept making it impossible to fully umount the boot device. There is no way to order everything to get rid of all the bugs.

I fixed it this time by unmounting /live/boot-dev/antiX/linuxfs after a successful toram copy and then mounting /live/to-ram/linuxfs. This fixed the problem and should prevent me from re-creating old bugs had I moved the to-ram code to a place earlier in the boot process.

I also removed the dastardly"umount -l" (lazy umount) which had been masking this problem. I replaced it with a loop that tries to do a normal umount for 2.5 seconds before giving up. I needed to do a similar thing in the build-iso script a few years ago.

The problem should be fixed. If it is not fixed (perhaps in some use cases) then an error will be reported and the boot device will not be unmounted so the toram-eject script will not run.

BTW: the new initrd will run toram-eject in CLI mode if we've done a successful toram and the boot device is a LiveCD/DVD and we are in runlevel 3. I don't know if this will disable running toram-eject in GUI mode (but if not then this will be easy to fix). I start X from runlevel 3 with the command (as root):

I uploaded an updated rc1.1 initrd.gz on
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://www.dropbox.com/sh/4o0rfipwoi3usqb/AAD_9EXCnwJ4I284Ijg4UKwba?dl=0"
linktext was:"dropbox"
====================================
.

BTW, there is a minor bug in the toram-eject script which causes it to print the title twice in CLI mode. This bug is fixed elsewhere so you will still see it if you use"toram" combined with runlevel 3.