1: =============================================================================
     2:                 ----------------------------------------------
     3:                 ZyX LiveInstaller:: Frequently Asked Questions
     4:                 ----------------------------------------------
     5: =============================================================================
     6: 
     7: =============================================================================
     8: Q:
     9:     Why did you do this?
    10: 
    11: A:
    12:     I am very happy to say that I haven't 'really' used microsoft windows 
    13: in a very long time.  And I'm willing to grant that they do have smart 
    14: people working for them, and there did seem to be vast improvements 
    15: between 98 and XP.  But, niceties asside, the reason I chose a life path
    16: and niche career where I wouldn't have to 'really' use MS 'winblowz', is
    17: because of the nightmare user experience their OS provided for many years.
    18: I'm talking about reboot and reboot and reboot.  Install a driver, reboot 
    19: (perhaps several times).  Crash (on a daily basis), reboot.  Install
    20: software, reboot.  It just really bothered me as a computer engineer, to
    21: the point where whenever I would use any system, and have to reboot, I
    22: would hear a voice in my head question why the reboot was happening, and
    23: if better design and programming could have prevented the need to do it.
    24: So as soon as brain grok'd devicemapper enough to realize that this could
    25: be done, well...  it had to be done :)
    26: 
    27: Note, I must give credit to Bill Rugolsky Jr. in a discussion on
    28: fedora-livecd-list[1a] back in March'06, he first introduced me to the
    29: idea of using devicemapper to migrate data from a LiveCD to disk.  His idea
    30: however was to migrate the readonly squashfs filesystem to disk, so that it
    31: would be effectively 'cached'.  I then figured out the next logical step of
    32: migrating the ext3 part of the readonly squashfs *and* the readwrite
    33: overlay, to result in something effectively identical to a tradionally
    34: installed and running system (sans cold, or even kexec-warm reboot).
    35: 
    36: [1a] 
    37: https://www.redhat.com/archives/fedora-livecd-list/2006-March/msg00276.html
    38: 
    39: 
    40: =============================================================================
    41: Q: 
    42:     Does this require respinning or massive modification to the LiveOS?
    43: 
    44: A:
    45:     For the standard Fedora LiveOS releases, probably as far back as they
    46: go- No.  There was a version of this I posted to fedora-devel 2 years ago
    47: that required either respinning or some painful manual early boot commands.
    48: But very shortly after I released that, I figured out how to avoid that,
    49: and mentioned that on fedora-devel as well.  I'm not sure if they believed 
    50: me at the time, but not a single person expressed any interest in finding
    51: out.
    52: 
    53: =============================================================================
    54: Q: 
    55:     Will including this in my LiveOS spin be dangerous and have bad side-
    56: effects?
    57: 
    58: A:
    59:     The size of the .i386.rpm is <150kb.  The code should only run if and
    60: only if the user launches the installer from the SystemTools desktop menu.
    61: The priveledged execution configuration(pam/consolehelper) is a 100% copy 
    62: of that of the traditional fedora anaconda/liveinst installer.  But by all
    63: means, this is at the moment very alpha software, in need of good peer-
    64: review and critique.
    65: 
    66: =============================================================================
    67: Q: 
    68:     Doesn't SuSE already have a rebootless installer?
    69: 
    70: A:
    71:     In some sense yes.  But not in the sense that the user can be surfing
    72: the web with firefox, running from a LiveCD/DVD/USB, then if they decide,
    73: launch a process which will install the OS they are using to surf the web
    74: with to disk, and when done, be able to eject the install CD/USB, never
    75: having had to stop using their web browser (or any other application).
    76: Rather, what I believe SuSE achieves, is saving several seconds that was
    77: historically spent doing a 'cold' or 'warm' reboot involving BIOS
    78: reinitialization of hardware.  Otherwise, their users still witness every
    79: process running on the computer, come to a synchronous end, while the user
    80: watches every OS initialization program and script, run again.  To me, I
    81: call that a 'reboot experience'.  If they really want to call that 
    82: 'rebootless installation', well, more power to them.
    83: 
    84: =============================================================================
    85: Q: 
    86:     Were you the first person to write a rebootless OS installer?
    87: 
    88: A:
    89:     Perhaps, if you restrict the question to the sense of a fully usable
    90: LiveOS installer.  I suspect some things done 10+ years ago might fall
    91: under the terms, but those did not present you with a completely usable
    92: workstation prior to installation that remained unaffected through and 
    93: after installation.  Also, I am definitely the second person to have
    94: described the process online, though perhaps the first to have implemented
    95: it.  Only after I was well into my implementation did I discover that 
    96: Goswin Brederlow had outlined more or less the same implementation years
    97: earlier- 
    98: 
    99: http://www.mail-archive.com/debian-boot@lists.debian.org/msg28182.html
   100: 
   101: However I have never been able to find anything publically available
   102: that resulted from that discussion.
   103: 
   104: =============================================================================
   105: Q: 
   106:     What happens to my seperate LiveUSB /home data partition/file?
   107: 
   108: A:
   109:     For the moment, nothing.  If your LiveUSB /home is mounted from
   110: a seperate file or partition on the LiveUSB (i.e. during LiveUSB creation
   111: you allocated space for a seperate /home area), then it will remain 
   112: seperately mounted after installation.  In part, I am really awaiting
   113: feedback from serious users of such configurations to let me know how they
   114: think it should be handled.  This is because I have more than one thought
   115: on how to better address the situation, but don't necessarily want to 
   116: implement all the alternatives along with a selection mechanism.  Let me
   117: know what you think should happen by default in this situation.
   118: 
   119: =============================================================================
   120: Q: 
   121:     What is this issue with unionfs with future Fedora releases?
   122: 
   123: A:
   124:     At the inception of official Fedora LiveCDs (i.e. Fedora-6 if I recall
   125: correctly), Fedora(/DavidZ), partially inspired by a report I wrote[2] on 
   126: the Linux From Scratch LiveCD architecture, decided to utilize devicemapper
   127: snapshots to facilitate a LiveCD that supported a fully read-write root
   128: filesystem.  The more popular alternative at the time, and since, found in
   129: Knoppix and Ubuntu, was to use unionfs instead of devicemapper snapshots to
   130: provide the RW-rootfs capability.  I was such a non-ubuntu user at the time,
   131: that when I wrote that report, I actually did not know that ubuntu had already
   132: used devicemapper snapshots briefly, before switching out to unionfs, and that
   133: in all likelyhood, that is where LFS picked up on the technique.  The primary
   134: benefit of unionfs as a LiveOS architecture over devicemapper snapshots, might
   135: be the slightly more intuitive way that one can work with the overlay, as an
   136: easily accessible set of files, as opposed to a low level collection of
   137: modified disk blocks.  This also leads to easier recovery from storage
   138: exhaustion scenarios, as deleted files can trivially reclaim space in the
   139: overlay.  Wheras to as easily recover space in the dmsnapshot case, requires
   140: code currently theorized, but not yet written.  Because of this,
   141: LiveCD/USB/OSs, both unionfs and dmsnapshot based, but particularly dmsnapshot
   142: based, are not terribly well suited to long term use.  One thing to remember
   143: with the zyx-liveinstaller, is that once the installation completes, none of
   144: these complications matter any more, as the system is now effectively
   145: identical to a traditionally installed system... without rebooting even one
   146: time.  Now then, digressing a bit from background, going back to the original
   147: question- The reason that the zyx-liveinstaller will cease to work on stock
   148: Fedora, if they move to a unionfs based architecture, is because the
   149: devicemapper snapshot nature of the LiveOS, is key in facilitating rebootless
   150: installation.  With unionfs, you can try to do something similar, but if a
   151: filehandle is open (as many always are) on the installation media, there is
   152: no current way (that I know of) to seperate that media from the OS, without
   153: suffering stale broken filehandles, on system critical files.
   154: 
   155: So should Fedora switch to unionfs for the LiveOS rootfs, which it may do as
   156: early as F13, the zyx-liveinstaller, would THEN AND ONLY THEN, require a
   157: custom respin to work with Fedora.  Also, note that unionfs being available
   158: in Fedora, is not the same thing as switching to it for the LiveOS
   159: architecture.  Should unionfs be in the mainline kernel, and in Fedora, but
   160: not used for the LiveOS architecture, then the zyx-liveinstaller would
   161: continue working on completely stock Fedora LiveCD/DVD/USBs.
   162: 
   163: [2] In mid 2006, using the alias Jane Dogalt, I published my first 
   164: implementation outline[2a] of Rebootless LiveOS Installation, in response to
   165: discussion of SuSe style kexec bios-skipping-but-still-a-warm-reboot based
   166: installation.  Shortly thereafter, Fedora(/DavidZ), implemented the first
   167: official Fedora LiveCD, built with the pilgrim/mayflower toolset/scripts
   168: which provided the foundation for the current livecd-creator/tools.  In that
   169: first release's README.fedora[2b] file, davidz even referenced that post 
   170: (search for 'rebootless' in the linked page), and specifically, the
   171: facilitation of rebootless liveos installation.  Though he characterized it
   172: as 'bluesky', whatever that means.
   173: 
   174: 
   175: 2a: 
   176: http://www.redhat.com/archives/anaconda-devel-list/2006-August/msg00028.html
   177: 2b: 
   178: http://cgit.freedesktop.org/~david/pilgrim/commit/?h=bd9ff3dbce8ef5996be5ec23f999c7914fa7a656&id=31fb7988f302ea9ae98f6f77d4a158a774801eff
   179: 
   180: =============================================================================
   181: =============================================================================
   182: