-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RAM DRIVE #1
Comments
Thank you very much for the information! Can you also report this directly to the ReacOS-Team? |
Actually, ReactOS has a separate tracker they use officially: But in this case ReactOS already has a built-in RamDisk driver that supports LiveCD mode natively, but it is not a default option and must be configured as an advanced boot option. Mentioning installing and using third-party ram disk drivers inside of ReactOS won't be addressed as a related issue, unless you are talking about somehow integrating them as alternative ram disk drivers for the project. Here is a quote from one of the ReactOS devs:
|
Maybe I'm naive, but my idea was to 'copy' the Live-ISO into a VM of VitrualBox, install all the software, try to 'convert' the VM again into an ISO, and look, if it's works... ^^ |
Creating a VM we can share as an open development environment actually isn't a bad idea. But rather than "converting" anything, it would just be a model for the the LiveCD mode. In other words, we can develop things and demo them in the VM, and then we can reproduce on the LiveCD. The LiveCD and installation into a VM are two fundamentally different environments and must be done separately. And the final product we are shooting for is a LiveCD format, so developing and demoing only within an installation in a VM wouldn't actually be helping us get to our final product goal and would leave the ram disk environment completely untested. |
Guess there isn't any solution to boot directly into a (write-protected) VM (like KVM), yet... |
You wouldn't need to, all VM software comes with the ability to boot a disk image. But constantly tweaking the image and booting and tweaking and booting would be quite annoying and drag out development. What I am talking about as far as using a VM is that we could install ReactOS into a VM, test tools there to cover certain aspects within that environment, and then integrate them into the disk image after they are working in the VM and we have all the bugs worked out there. That way by the time we integrate them into the image, a lot of the ReactOS-specific compatibility issues have already been worked out and we are just dealing with LiveCD issues only. |
I understand! I set it on the To-Dos-List... |
But my 'dream' seems not to be so unrealistic... ^^ |
Are am I wrong, or does he exactly what I was talking about: |
You are correct, sir, but it is not related to this project. ReactOS built their own clone of ntldr called FreeLdr, which cannot coexist in the MBR with GRUB. You can hook one with the other, but they cannot both boot at the same time. If we are trying to get ReactOS dev support, we should stay away from third-party elements that are not supported. It mimics the NT boot manager. I think it is clear step 1 for this team is compiling a list of resource links for key aspects to understand ReactOS better. ReactOS is NOT Windows, NOT Linux, NOT BSD. ReactOS is an entirely different OS from the ground up. Just explore their wiki in general: ReactOS is still in early development, so if step 1 of this project is to make tutorials and documentation even just for ourselves to understand it better, we have time to do that. |
Some links for the ram disk. The wiki link is out of date and focuses on TFTP booting over a network, but you can ignore those parts and focus on the "ramdisk" portions https://doxygen.reactos.org/dc/d38/boot_2freeldr_2freeldr_2disk_2ramdisk_8c.html |
Hi again.
The way I tested it was following:
|
Hi @skydecboot2018! Yes, we talk about number 2! I googled a bit about 'ReactOS ramdrive' (ramdisc) and saw the other meaning, too. @ScriptTiger: I can't find a page that explain how it should go... Can you go deeper into it to maybe find one? If we don't find a ReactOS-included solution, we should test third-party software, fill bugs in the ReactOS-Project and monitor them... But even when we have no RAMDrive-Solution yet, we can anyway test the other software (because on HDD and in VM we have write-access and Temp-Folder) and fill bugs and monitor them... Here is the solution I figured out to create e.g. a VM to test: And maybe you want to discuss further development of UWBCD with us here: Greets, Tobias. |
@Tobias-B-Besemer, I agree totally with everything you have said. We should get what we can to work the way we know how and monitor ReactOS progress while pushing ahead in our other models, such as WinPE, VM, etc., and kind of trickle transition what we can into ReactOS from the other models as ReactOS becomes compatible. This way ReactOS isn't completely limiting development. So far feedback from the ReactOS forums from developers has been huge, such as the VGal builds, so we should also remember to be active in the forums with those guys, as well, while waiting for bug fixes, issue tickets, etc. |
I asked for more information in the forum: |
Tested on 0.4.8. live and install
Free ram drive programs that other bootcds use are ERAM-master and ImDisk
Tried installing both on reactos, their icon is in control panel, GUI works but no drives are created. Looks like their services are not started and ImDisk in cmd reports that its driver isn't loaded into kernel.
The text was updated successfully, but these errors were encountered: