I'm with David too El 05/07/2017 15:26, "Hermès BÉLUSCA-MAÏTO" <hermes.belu...@sfr.fr> escribió:
> Thank you guys for your brainstorming about the boot menu. > This will require few adjustments to freeldr before being able to have the > submenus, since we currently don't support them "dynamically" (aka. > specified from within freeldr.ini), but only in hardcoded manner (like the > F8 advanced options) up to now. > > Hermès;. > > -----Message d'origine----- > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Ged Murphy > Envoyé : mercredi 5 juillet 2017 15:20 > À : 'ReactOS Development List' > Objet : Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI > setup > > Run or install? > I think I prefer David's version. > > - Install > - Try without installing > - Cancel and boot from disk > - Advanced options ... > > > -----Original Message----- > From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Giannis > Adamopoulos > Sent: 05 July 2017 14:03 > To: ReactOS Development List <ros-dev@reactos.org> > Subject: Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI > setup > > 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 > > > _______________________________________________ > 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
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
