Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI setup

[David Quintana (gigaherz)]

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.belusca(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>