About the bootcd and livecd, and the 1st-stage GUI setup

[Hermès BÉLUSCA-MAÏTO]

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
1st-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 1st-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
https://svn.reactos.org/svn/reactos?view=revision&revision=75273
&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

[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 [e-mail] 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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[David Quintana (gigaherz)]

Oh the "Cancel and boot from hard disk" could be on the main menu I suppose!

On 4 July 2017 at 22:45, David Quintana (gigaherz) [e-mail]
wrote:
> 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 [e-mail]
> 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/re
> > actos/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/re
> > actos?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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev

[Riccardo Paolo Bestetti]

IT guy says +1!

Best regards,
Riccardo Paolo Bestetti

From: Ros-dev [mailto:[e-mail]] On Behalf Of David Quintana (gigaherz)
Sent: martedì 4 luglio 2017 22:47
To: ReactOS Development List [e-mail]
Subject: Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI setup

Oh the "Cancel and boot from hard disk" could be on the main menu I suppose!

On 4 July 2017 at 22:45, David Quintana (gigaherz) <[e-mail]:[e-mail]> wrote:
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 <[e-mail]:[e-mail]> 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 1st-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 1st-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/getbuildshttp://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
[e-mail]:[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev