I'd say that we should show: - Run or install ReactOS - Boot from hard disk - Advanced options
Nothing more should be needed and the first option should be clear that can either lead to a live environment or a setup. David Quintana (gigaherz) <gigah...@gmail.com> wrote on Tue, July 4th, 2017, 10:45 PM: > I feel like the boot menu is going to be far too busy for the end user. I'd > go with something closer to > > blah blah: > > - Install Now > - Try without installing > - Show advanced options... > > where: > > - Install now -- boots into the graphical installer (no desktop unless > you cancel or something) > - Try without installing -- boots into livecd desktop (backed by RAM, I > guess) > - Show advanced options... -- opens a second-level menu with > - Text-mode installer > - Live boot without Ramdisk > - etc. > > > > On 4 July 2017 at 21:45, Hermès BÉLUSCA-MAÏTO <hermes.belu...@sfr.fr> wrote: > > > Hello everyone, > > > > > > > > One of the long-term plan for ReactOS was to have a graphical user-mode > > interface for the 1st-stage setup, similar to e.g. what may be found in > > newer versions of Windows (Vista+), as an alternative to our current > > 1st-stage > > setup in text-mode > > > > (note that I say “alternative”, not “replacement”, because both of them > > can live together without fundamental changes to either ReactOS or our ISO > > images, both of them can share core functionality, and finally because some > > people may prefer the text-mode either for unattended installations or for > > low-memory conditions). > > > > > > > > You can find some information about the 1st-stage GUI setup here: > > https://reactos.org/wiki/First_Stage_GUI_Setup . In our source code, it > > can be found in base/setup/reactos/ . Currently only most of the screens > > have been implemented, while the core functionality is not present. However > > this functionality can somehow be taken by reusing the source code of > > USETUP (see my branch https://svn.reactos.org/svn/reactos/branches/setup_ > > improvements/base/setup/ ). > > > > > > > > > > > > Abstract (aka. TL;DR): I explain below the needed changes introduced > > experimentally in the “setup-improvements” branch, revision 75273, to > > generate an all-in-one ReactOS bootcd, that includes both the 1st-stage > > text-mode setup + 1st-stage GUI setup alternative + live-demo > > functionality. This is meant to replace our currently separated “bootcd” / > > “livecd” ISOs, where the latter currently do not offer the possibility to > > install ReactOS. Some currently known potential problems are evoked. > > > > > > > > Images: Proposed BootCD contents : http://i.imgur.com/EBA6JHd.png ; > > Proposed Boot Menu : http://i.imgur.com/14n5Ryi.png . > > > > > > > > > > > > Having a 1st-stage GUI setup also means that it’ll also use the > > already-existing functionality that we offer in our “Live-CD” ISOs. > > Currently, the “Live-CD” ISOs we provide only allow for demonstration > > purposes, while the ReactOS installation proper is found in our so-called > > “Boot-CD” ISOs (which currently only contain text-mode setup). Thus, the 1 > > st-stage GUI setup, as an alternative to the 1st-stage setup in > > text-mode, means that both ISOs can be merged all in one, and we won’t have > > to make a distinction between both: they will be able to offer both the 1 > > st-stage in text mode AND a graphical mode (à la “Live-CD”) where it is > > possible to choose whether to test ReactOS in demo mode, or to install it > > via the GUI setup. > > > > Such an all-in-one ISO capability was already present in the trunk under > > the name “hybridcd”, but was used only when we built ISO images for the > > public events where ReactOS participated (FOSDEM, CLT, …). But now, having > > the setup process both in text mode and in graphics mode, in addition to > > the Live-CD demonstration capability, really suggests just using the > > all-in-one ISO and stop doing the “Boot-CD” (aka. only setup) vs. “Live-CD” > > (aka. only demo) separation. We would just generate only one type of ISO > > that contains everything. > > > > > > > > With that in mind, I have committed in my branch “setup_improvements”, in > > revision 75273 : https://svn.reactos.org/svn/reactos?view=revision&; > > revision=75273 such changes to be able to only build an ISO that contains > > everything. These changes are minimal, in the sense that I haven’t > > purposelessly changed the names of the build targets just to be fancy. Such > > changes may be done later, but not now. > > > > > > > > The needed changes are the following: First, the build target that will > > generate the all-in-one CD is called “bootcd”, because this also was the > > main build target for ISOs before the change. Second, I completely remove > > the “hybridcd” build target, because its functionality are now absorbed by > > “bootcd”. Third, the build target “livecd” is reduced to its strict > > minimum. For the sake of building a RAMDISK boot drive (see comments > > after), I continue to generate an ISO for “livecd”. But I’ve changed the > > generated name to “liveimage.iso”, to emphasize the point that it has to be > > understood as a (virtual) disk image for RAMDISK purposes, not just as a > > ISO image. Note that I haven’t renamed the build target “livecd” to, say, > > “liveimage” to reduce my commit changes (such a renaming may be done > > later). The “livecd” target builds a list of files that need to be present > > in the image. The generated liveimage.iso is no-more a bootable ISO, I’ve > > removed inclusion of freeloader + El-Torito boot-sector + the > > USB-ISO-Hybrid functionality for it. > > > > The “bootcd” target has been slightly changed in order to include the > > liveimage.iso as a file (for RAMDISK), and to also add the contents of this > > image in a flattened tree within the bootcd iso: the two directories > > “Profiles” and “reactos”. > > > > The 1st-stage text-mode setup is kept, as said before, but its > > corresponding files + the installation CAB source + the 1st-stage GUI > > setup application proper goes into a (renamed) directory called “i386”, > > corresponding to installation files for an i386 installation (technically, > > 1 per architecture when we’ll have a ReactOS ported to other archs). These > > files cannot be present in the same “reactos” directory as the ones from > > the flattened LiveImage, because some of the files are different (smss.exe, > > registry, etc…) Our FreeLdr knows from where to boot the 1st-stage > > text-mode (from i386), as well as the Live-demo in graphics mode (from > > reactos). > > > > I need to adjust the code of few setup components for them to stop relying > > on hardcoded “reactos/” path, and instead use a more “dynamic” (determined > > at runtime) path. > > > > > > > > NOTE FOR DEVS/SYSADMINS: The “bootcdregtest” build target, generating the > > special ISO that is fed to our test bots, remains exactly the same, and the > > files contained in the generated ISO have not changed. > > > > > > > > NOTE about the RAMDISK feature: I enabled it so that a user can remove the > > demo media (CD, …) and reuse the drive for other purposes, while still > > being able to use ReactOS. Of course this requires a large amount of RAM > > available. And that’s also why I include the flattened liveimage files so > > that one can use the demo without the RAMDISK (when few memory is > > available). > > > > As is currently implemented, this makes the ReactOS all-in-one bootcd > > large (it gains a good 100 MB) due to duplicated space (the flattened > > files, plus the same inside “liveimage.iso”). I cannot do better (unless > > ditching either the RAMDISK, or keeping it but not include the flattened > > files) because ReactOS currently doesn’t have a way to boot from disk > > images **that are not meant to be a RAMDISK**. The day when this > > difficulty is removed, a single disk image could be used either as the > > RAMDISK or the (non-removable) installation. > > > > A second remark is that I don’t plan to have the 1st-stage GUI setup > > available when booting ReactOS in RAMDISK mode because, as a consequence of > > its current implementation, I would otherwise need to duplicate the > > installation CAB source in the RAMDISK image too, making it again larger. > > > > > > > > NOTE about the FreeLdr Boot Menu: Since ReactOS is not that stable > > currently, we like to boot it in debug mode, and redirect the output to a > > serial port (usually COM1). However some people don’t have serial ports on > > real hardware, so we propose to boot with debug output redirected to > > screen. However this may slow ReactOS down, so we also like to boot ReactOS > > with debug mode disabled. That’s why I proposed the declination of these > > boot modes for each ReactOS installation contained in the BootCD > > (Live+Setup, with or without RAMDISK, and with debug enabled or not). The > > problem is that it clutters a lot the boot menu. A remedy would be to > > implement in FreeLdr the functionality of editing **existing** boot > > entries to change their associated boot options, so that one could add by > > hand the options to enable (or disable) debugging. This is currently > > unimplemented. The only implemented feature is to set up a new boot entry > > on the fly to boot ReactOS afterwards. > > > > > > > > NOTE for regress-testers: Possible remark that I may hear: “I only care > > about installing ReactOS (perhaps just in unattended mode) and I don’t care > > at all about the GUI setup nor about the Live-demo thingie, and your new > > BootCD is too large. I want to be able to download & use the good-old > > bootcd for regress-testing.” . So what to do? Since we currently build and > > store the “bootcdregtest” ISOs, but are not publicly available through our > > www.reactos.org/getbuilds interface, I would suggest here to make them > > available to people, so that those who want to quickly DL and/or > > install/regress-test ReactOS could use these ISOs instead (which are really > > just the good old BootCDs, but with unattended installation enabled **and** > > with our test-suite included). They are not that much large, just a bit > > more than the old regular bootcd. > > > > > > > > Please let me know whether you have other > > remarks/comments/questions/suggestions/etc… > > to make the new BootCDs better. > > > > > > > > > > > > Best, > > > > > > > > Hermès > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev@reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
