Anaconda-devel February 2011

anaconda-devel@lists.stg.fedoraproject.org

21 participants
82 discussions

Network: port of rhel patches to master
by Radek Vykydal 01 Mar '11

01 Mar '11

This is port of what have been done in rhel 6.1. I am sending it for review because changes in kickstart made the port not so straightforward, and also to sum up the changes of networking on master. It is all tested with F15 Alpha TC2, It would be nice to have the changes already in F15 but there is no haste I guess. I think I need to wait for F16 classes in pykickstart to adapt its part of patches before pushing, right Chris? The major changes on master are: * kickstart network --activate option was added (activates devices, also additional, in loader) * reactivation of device in kickstart was restored (as in rhel, in master it was removed probably with commit 1980e9d377aa6089ae96740cd85593ec18d5344d) * network is not activated automatically if in case of non-network install (as in rhel, in master changed with commit 9767cb5fce174e8fcf28d06ad6f48384129a7cd4) Now --activate option can be used conveniently to activate the device in non-network installs. Details are here: http://fedoraproject.org/wiki/Anaconda/Network#kickstart As for documentation, I suppose the wiki should reflect last release (not rawhide), right? I want to update it soon. Also to look at Fedora Installation Guide (I've already sent update to RHEL Installation Guide https://bugzilla.redhat.com/show_bug.cgi?id=679104) Radek

2 20

UEFI is here (on Sandy Bridge) and the boot order is wrong
by Andrew Lutomirski 28 Feb '11

28 Feb '11

UEFI is here for real, and (at least as F14) we're not really ready for it. (You can buy >2TB disks, and AFAICT basically all Cougar Point motherboards support UEFI.) I have a new DH67GD board (one of Intel's Sandy Bridge / Cougar Point boards), and in a fit of masochism I decided to install Fedora 14 in EFI mode. I had two problems, both related to anaconda. I'll deal with the more straightforward issue first. When installing to an EFI system (i.e. disk is GPT and the installer was booted in EFI mode), anaconda installs grub to /boot/efi/EFI/redhat/grub.efi and sets up an entry in efibootmgr to point to it. This interacts rather badly with my motherboard. As far as I can tell (note: this is deduced from limited experimentation), when UEFI is enabled in my firmware, the actual boot order is: 1. Boot from *devices* in the order specified in firmware config. (This has nothing at all to do with efibootmgr AFAICT.) I'll get to what "booting from a device" means below. 2. Boot from *disabled* devices in some order (I haven't tried to figure out what order). 3. Boot from efibootmgr entries (presumably in order specified in efibootmgr). Asking for the boot menu on startup overrides this order. When booting from a device, my firmware seems to behave quite differently depending on whether the device is removable. For a hard disk, the firmware will try to load /EFI/BOOT/BOOTX64.efi. If that fails, the firmware will try to boot from the MBR. For a CD-ROM or USB stick, the firmware will consider EFI boot and old-style BIOS boot to be two different devices (and they will show separately in the boot menu if the boot menu is shown). The problem is that anaconda does not create /EFI/BOOT/BOOTX64.efi. This means that EFI boot *from the hard disk* fails and the firmware will fall back to all kinds of absurd options. If there's an MBR boot record (and there is one on my disk that doesn't actually boot anything), then that gets loaded and the boot fails. If there's a CD-ROM in the drive that's bootable, the firmware will boot from it *even if "boot from CD-ROM" is explicitly disabled*. Finally, if none of those appear bootable, then the firmware will fall back to the efibootmgr-recorded option and boot successfully. I've fixed it locally by copying grub.efi to /EFI/BOOT/BOOTX64, which means that my system reliably boots from the EFI grub on my disk. Should anaconda create that file? -------------------- Second issue: If I booted the installer in BIOS (i.e. not EFI) mode or if my hard disk is not GPT, how do I install in EFI mode? Clearly EFI should not be the default if I booted in BIOS mode, but what if I want to override that (or change the disk over to GPT)? In my case I booted the installer in BIOS mode because my firmware interacted poorly with F14's EFI live CD. (F15 TC1 worked, but the installer was so broken that I just gave up.) I'd be happy to do some limited experimentation here to help out. Unfortunately, this is a system I use with only one hard disk, and I testing in KVM isn't helpful. I don't really want to do a bunch of fresh installs if I can avoid it. I would, however, be happy to experiment with efibootmgr, weird files in /boot/efi, and other such lightweight experiments. Thanks, Andy

2 2

[rhel5-branch] Use DISPATCH_NOOP if we go back to the doReIPL step (#654685)
by Martin Gracik 28 Feb '11

28 Feb '11

On s390 and s390x architectures the doReIPL function should return DISPATCH_NOOP if we go back, otherwise we can't get from the network step back to the bootloader. --- packages.py | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/packages.py b/packages.py index a1a6e56..3a9fd88 100644 --- a/packages.py +++ b/packages.py @@ -411,7 +411,8 @@ def selectLanguageSupportGroups(grpset, instLanguage): grpset.groups["language-support"].select() def doReIPL(anaconda): - if not rhpl.getArch() in ['s390', 's390x']: + if (not rhpl.getArch() in ['s390', 's390x'] or + anaconda.dir == DISPATCH_BACK): return DISPATCH_NOOP messageInfo = iutil.reIPL(anaconda, os.getppid()) -- 1.7.3.2

2 1

[PATCH] Fix SELinuxFS.mountable so /selinux gets mounted
by David Lehman 28 Feb '11

28 Feb '11

This is for rawhide and has been proposed as NTH for F15Beta.

2 2

[lorax] Split compression into separate methods; use xz to compress initrd
by Will Woods 26 Feb '11

26 Feb '11

xz compression makes the initrd 33% smaller (136M -> 90M). The extra memory overhead at decompression time is negligible: testing showed that any system with enough RAM to use the gzip-compressed initrd was also able to load the xz-compressed initrd with no trouble. Note that '--check=crc32' is needed because the kernel doesn't know how to perform the default xz integrity check (crc64). --- src/pylorax/constants.py | 2 ++ src/pylorax/installtree.py | 24 ++++++++++++------------ 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/src/pylorax/constants.py b/src/pylorax/constants.py index 547a938..4967450 100644 --- a/src/pylorax/constants.py +++ b/src/pylorax/constants.py @@ -41,6 +41,7 @@ class LoraxRequiredCommands(dict): self["DMSETUP"] = "dmsetup" self["FIND"] = "find" self["GCONFTOOL"] = "gconftool-2" + self["GZIP"] = "gzip" self["IMPLANTISOMD5"] = "implantisomd5" self["ISOHYBRID"] = "isohybrid" self["LDCONFIG"] = "ldconfig" @@ -52,6 +53,7 @@ class LoraxRequiredCommands(dict): self["MOUNT"] = "mount" self["PARTED"] = "parted" self["UMOUNT"] = "umount" + self["XZ"] = "xz" def __getattr__(self, attr): return self[attr] diff --git a/src/pylorax/installtree.py b/src/pylorax/installtree.py index 9883bba..e1a0bdb 100644 --- a/src/pylorax/installtree.py +++ b/src/pylorax/installtree.py @@ -25,7 +25,6 @@ logger = logging.getLogger("pylorax.installtree") import sys import os import shutil -import gzip import re import glob import time @@ -49,6 +48,14 @@ class LoraxInstallTree(BaseLoraxClass): self.lcmds = constants.LoraxRequiredCommands() + def compress_initrd_pipe(self, stdin, stdout): + return subprocess.Popen([self.lcmds.XZ, '--check=crc32', '-9', '-c'], + stdin=stdin, stdout=stdout) + + def compress_module(self, filename): + return subprocess.call([self.lcmds.GZIP, '-9', '-f', + filename]) + def remove_locales(self): chroot = lambda: os.chroot(self.root) @@ -310,14 +317,7 @@ class LoraxInstallTree(BaseLoraxClass): for root, _, fnames in os.walk(moddir): for fname in filter(lambda f: f.endswith(".ko"), fnames): path = os.path.join(root, fname) - with open(path, "rb") as fobj: - data = fobj.read() - - gzipped = gzip.open("{0}.gz".format(path), "wb") - gzipped.write(data) - gzipped.close() - - os.unlink(path) + self.compress_module(path) def run_depmod(self, kernel): systemmap = "System.map-{0.version}".format(kernel) @@ -521,9 +521,9 @@ class LoraxInstallTree(BaseLoraxClass): stdin=find.stdout, stdout=subprocess.PIPE, preexec_fn=chdir) - gzipped = gzip.open(initrd.fpath, "wb") - gzipped.write(cpio.stdout.read()) - gzipped.close() + compress = self.compress_initrd_pipe(stdin=cpio.stdout, + stdout=open(initrd.fpath,"wb")) + compress.communicate() # move modules out of the tree again shutil.move(joinpaths(self.root, "modules", kernel.version), -- 1.7.4

5 10

[PATCH] Clarify that loader method entries are looking for a tree.
by Chris Lumens 25 Feb '11

25 Feb '11

We're not looking for the stage2 image anymore, so stop referring to "installation image". Also, there's no prompting to do for rescue mode anymore either. --- loader/hdinstall.c | 10 +++++----- loader/loader.c | 9 ++------- loader/nfsinstall.c | 4 ++-- loader/urlinstall.c | 2 +- loader/urls.c | 2 +- 5 files changed, 11 insertions(+), 16 deletions(-) diff --git a/loader/hdinstall.c b/loader/hdinstall.c index c321afb..b509409 100644 --- a/loader/hdinstall.c +++ b/loader/hdinstall.c @@ -180,7 +180,7 @@ int promptForHardDrive(struct loaderData_s *loaderData) { /* now find out which partition has the stage2 image */ checked_asprintf(&buf, _("What partition and directory on that " - "partition holds the installation image " + "partition holds an installation tree " "for %s? If you don't see the disk drive " "you're using listed here, press F2 to " "configure additional devices."), @@ -203,7 +203,7 @@ int promptForHardDrive(struct loaderData_s *loaderData) { kspartition = NULL; } - label = newtLabel(-1, -1, _("Directory holding image:")); + label = newtLabel(-1, -1, _("Directory holding tree:")); dirEntry = newtEntry(28, 11, dir, 28, (const char **) &tmpDir, NEWT_ENTRY_SCROLL); @@ -280,7 +280,7 @@ int promptForHardDrive(struct loaderData_s *loaderData) { files = get_file_list(buf, ends_with_iso); if (!files) { newtWinMessage(_("Error"), _("OK"), - _("That directory does not contain installation media.")); + _("That directory does not contain an installable tree.")); umount("/mnt/isodir"); free(buf); continue; @@ -298,7 +298,7 @@ int promptForHardDrive(struct loaderData_s *loaderData) { if (doPwMount(buf, "/tmp/testmnt", "auto", "ro", NULL)) { free(buf); newtWinMessage(_("Error"), _("OK"), - _("That directory does not contain installation media.")); + _("That directory does not contain an installable tree.")); umount("/mnt/isodir"); continue; } @@ -307,7 +307,7 @@ int promptForHardDrive(struct loaderData_s *loaderData) { if (access("/tmp/testmnt/.treeinfo", R_OK)) { newtWinMessage(_("Error"), _("OK"), - _("That directory does not contain installation media.")); + _("That directory does not contain an installable tree.")); umount("/tmp/testmnt"); umount("/mnt/isodir"); continue; diff --git a/loader/loader.c b/loader/loader.c index 47021cc..eb59432 100644 --- a/loader/loader.c +++ b/loader/loader.c @@ -1366,13 +1366,8 @@ static void doLoaderMain(struct loaderData_s *loaderData, } installNames[i] = NULL; - rc = newtWinMenu(FL_RESCUE(flags) ? _("Rescue Method") : - _("Installation Method"), - FL_RESCUE(flags) ? - _("What type of media contains the rescue " - "image?") : - _("What type of media contains the installation " - "image?"), + rc = newtWinMenu(_("Installation Method"), + _("What type of media contains the installation tree?"), 30, 10, 20, 6, installNames, &loaderData->method, _("OK"), _("Back"), NULL); if (rc == 2) { diff --git a/loader/nfsinstall.c b/loader/nfsinstall.c index ed92f78..df58a32 100644 --- a/loader/nfsinstall.c +++ b/loader/nfsinstall.c @@ -82,7 +82,7 @@ static int nfsGetSetup(char ** hostptr, char ** dirptr, char ** optsptr) { entries[3].value = NULL; if (asprintf(&buf, _("Please enter the server and path to your %s " - "installation image and optionally additional " + "installation tree and optionally additional " "NFS mount options."), getProductName()) == -1) { logMessage(CRITICAL, "%s: %d: %m", __func__, __LINE__); abort(); @@ -259,7 +259,7 @@ int promptForNfs(struct loaderData_s *loaderData) { if (getFileFromNfs(url, "/tmp/.treeinfo", loaderData) && !isNfsIso(loaderData)) { newtWinMessage(_("Error"), _("OK"), - _("The URL provided does not contain installation media.")); + _("The URL provided does not contain an installable tree.")); free(url); continue; } diff --git a/loader/urlinstall.c b/loader/urlinstall.c index d20748e..23fe7b3 100644 --- a/loader/urlinstall.c +++ b/loader/urlinstall.c @@ -211,7 +211,7 @@ int promptForUrl(struct loaderData_s *loaderData) { if (getFileFromUrl(url, "/tmp/.treeinfo", loaderData)) { newtWinMessage(_("Error"), _("OK"), - _("The URL provided does not contain installation media.")); + _("The URL provided does not contain an installable tree.")); free(url); continue; } diff --git a/loader/urls.c b/loader/urls.c index 72f7706..b5f0a0a 100644 --- a/loader/urls.c +++ b/loader/urls.c @@ -264,7 +264,7 @@ int urlMainSetupPanel(struct loaderData_s *loaderData) { buttons = newtButtonBar(_("OK"), &okay, _("Back"), &cancel, NULL); checked_asprintf(&buf, - _("Please enter the URL containing the %s installation image on your server."), + _("Please enter the URL containing the %s installation tree on your server."), getProductName()); reflowedText = newtReflowText(buf, 47, 5, 5, &width, &height); -- 1.7.1.1

2 1

[rhel5-branch] Do not lose selection in the bootloader's drive order dialog (#583837).
by Ales Kozumplik 25 Feb '11

25 Feb '11

--- iw/driveorderwidget.py | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/iw/driveorderwidget.py b/iw/driveorderwidget.py index 0bd58fb..c2979f0 100644 --- a/iw/driveorderwidget.py +++ b/iw/driveorderwidget.py @@ -101,13 +101,16 @@ class DriveOrderWidget: # there has got to be a better way to do this =\ drive = model.get_value(iter, 0)[5:] index = self.driveOrder.index(drive) - if direction == gtk.ARROW_DOWN: + if direction == gtk.ARROW_DOWN and index < len(self.driveOrder) - 1: + previous = self.driveOrderStore.get_iter(index + 1) + self.driveOrderStore.swap(previous, iter) self.driveOrder.remove(drive) self.driveOrder.insert(index + 1, drive) - elif direction == gtk.ARROW_UP: + elif direction == gtk.ARROW_UP and index > 0: + next = self.driveOrderStore.get_iter(index - 1) + self.driveOrderStore.swap(next, iter) self.driveOrder.remove(drive) self.driveOrder.insert(index - 1, drive) - self.makeDriveOrderStore() # make the store for the drive order def makeDriveOrderStore(self): -- 1.7.3.3

2 1

[PATCH master f15-branch NTH?] Check repo instead of method type when enabling network in loader (#673824)
by Radek Vykydal 25 Feb '11

25 Feb '11

Now when we have stage 2 in initrd.img. This change fixes netinstall which is not identified as METHOD_CDROM because of missing .treeinfo/.discinfo so initial METHOD_URL is kept. I wonder if this this check is also worth fixing, or if we even should add .treeinfo to netinst.iso. --- loader/kickstart.c | 8 +------- loader/loader.c | 4 ++-- loader/loadermisc.c | 14 ++++++++++++++ loader/loadermisc.h | 1 + 4 files changed, 18 insertions(+), 9 deletions(-) diff --git a/loader/kickstart.c b/loader/kickstart.c index 7e7379b..89cff39 100644 --- a/loader/kickstart.c +++ b/loader/kickstart.c @@ -412,13 +412,7 @@ int isKickstartFileRemote(char *ksFile) { location = ksFile + 3; } - if (!strncmp(location, "http", 4) || - !strncmp(location, "ftp://", 6) || - !strncmp(location, "nfs:", 4)) { - return 1; - } else { - return 0; - } + return isURLRemote(location); } void getKickstartFile(struct loaderData_s *loaderData) { diff --git a/loader/loader.c b/loader/loader.c index 47021cc..9c0ca77 100644 --- a/loader/loader.c +++ b/loader/loader.c @@ -1459,8 +1459,8 @@ static void doLoaderMain(struct loaderData_s *loaderData, } case STEP_NETWORK: { - if (((installMethods[validMethods[loaderData->method]].type != - DEVICE_NETWORK) && (!hasGraphicalOverride()) && + if ((!isURLRemote(loaderData->instRepo) && + !hasGraphicalOverride() && !FL_ASKNETWORK(flags) && !FL_EARLY_NETWORKING(flags) && !ibft_present()) || diff --git a/loader/loadermisc.c b/loader/loadermisc.c index d0ff3d4..9f0c795 100644 --- a/loader/loadermisc.c +++ b/loader/loadermisc.c @@ -166,3 +166,17 @@ int simpleStringCmp(const void * a, const void * b) { return strverscmp(first, second); } + +int isURLRemote(char *url) { + if (url == NULL) { + return 0; + } + + if (!strncmp(url, "http", 4) || + !strncmp(url, "ftp://", 6) || + !strncmp(url, "nfs:", 4)) { + return 1; + } else { + return 0; + } +} diff --git a/loader/loadermisc.h b/loader/loadermisc.h index 3ffacb2..b59016b 100644 --- a/loader/loadermisc.h +++ b/loader/loadermisc.h @@ -29,5 +29,6 @@ int copyFileFd(int infd, char * dest, progressCB pbcb, struct progressCBdata *data, long long total); int recursiveRemove(int fd); int simpleStringCmp(const void * a, const void * b); +int isURLRemote(char *url); #endif -- 1.7.2

2 1

[PATCH] Fix up remaining anaconda.id references (#680296)
by Brian C. Lane 24 Feb '11

24 Feb '11

anaconda.id.storage no longer exists, it is anaconda.storage now --- pyanaconda/iutil.py | 2 +- pyanaconda/platform.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/pyanaconda/iutil.py b/pyanaconda/iutil.py index 197bf15..fc751b5 100644 --- a/pyanaconda/iutil.py +++ b/pyanaconda/iutil.py @@ -851,7 +851,7 @@ def reIPL(anaconda, loader_pid): anaconda.canReIPL = False devstring = None - for disk in anaconda.id.storage.disks: + for disk in anaconda.storage.disks: if disk.name == ipldev: devstring = disk.description break diff --git a/pyanaconda/platform.py b/pyanaconda/platform.py index ee00777..acf7d5e 100644 --- a/pyanaconda/platform.py +++ b/pyanaconda/platform.py @@ -212,7 +212,7 @@ class EFI(Platform): def bootDevice(self): bootDev = None - for part in self.anaconda.id.storage.partitions: + for part in self.anaconda.storage.partitions: if part.format.type == "efi" and self.validBootPartSize(part.size): bootDev = part # if we're only picking one, it might as well be the first -- 1.7.4

2 1

Draft proposal for using full anaconda as the default Fedora download
by Máirín Duffy 24 Feb '11

24 Feb '11

Hi, After some discussion in #anaconda earlier this week I put together a proposal for using a full anaconda environment as the default installation method for Fedora rather than the current live installation environment. Before I sent this to fedora-devel (which I'm admittedly terrified of) I was hoping you folks might be willing to look over it below and sanity-check it for me? The next step I think is maybe to have some discussion on fedora-devel and propose it to FESCo. I really appreciate any feedback! Thanks, ~m --- PROPOSAL: Use full installer environment as default Fedora install method Currently (and since ~Fedora 12) the default media promoted for installation of Fedora both via our website at fedoraproject.org and at conferences and other events is the Desktop Live Media ISO, delivered via pressed optical media at events, and typically delivered via home-burned optical media or live usb media created via dd, livecd-creator on the command line, or the Live USB Creator GUI (the latter the most popular for non-Linux systems.) Live Media affords some clear advantages over traditional installers, primarily in its ability to be used via USB sticks as optical drives are less ubiquitous in laptops and its singularity as one image you can try-before-you-buy to test out drivers, rescue machines, and use as a full installer. It also affords a gee-whiz factor. However, there are some serious concerns about the stability and overall user experience in promoting live media as the primary installation method of Fedora. There is also a larger concern about the future direction and maintenance of the spins project. Creating and maintaining usable live media is not a trivial task and many of our spins maintainers have understandably burnt out. Reconsidering how we deliver installation of Fedora to our end users may offer an opportunity to help this situation. First we'll walk through the advantages and disadvantages of live media, then we'll specifically address how switching to a full install environment affects each point and try to assess via discussion whether or not this is a proposal worth considering. = Advantages of Live Media: = ============================= 1. Try-before-you buy - not sure if Fedora will work with your video card or other hardware? You can easily pop it in and test it out without the trouble of a full install. 2. Very fast install time (due to use of dd?) 3. Convenient transition from trying to buying 4. Only one image to download for try, install, and rescue 5. Constrained / curated package set, no burden on the user to configure too much up front 6. Live environment means it's easier to take screenshots of crashes and look up helpful information on line to assist with installation 7. Viable long-term solution for those with computer access but no administrative control (e.g., children with access to school & library computer labs) to provide access to free software (if persistence worked well) 8. It works off of USB, which is good for the many laptops and slim towers today that come without optical drives. = Disadvantages of Live Media: = ================================ 1. Live environment is confusing to novice users who don't understand what's going on. They may not realize the environment is on the USB stick, and pull it out while it's running losing data (I have witnessed this multiple times.) They also may think their system is 'installed' when it's not, go about their work, and then lose it on reboot.) 2. Live environment means it's possible to put the system into a state that anaconda won't know how to deal with it and install-to-disk will fail ("a system that actively encourages you to go screw around with things until anaconda can no longer trust how things are set up") 3. Getting it onto the USB stick is non-trivial. There are three ways to do it (dd, liveusb-creator command line, liveusb-creator UI) and no single clear path is promoted. 4. Having to download both the ISO and a client to put the image on a USB stick afterwards is a lot to download and hard to figure out for novice users. 5. Requires use of isohybrid which means media can't boot on Macs without bootcamp 6. Dangerous option for long-term use because persistence is still not reliable and depending on the brand of USB key it may just die unpredictably. = Can the full installer provide the advantages of Live Media? = ================================================================= Let's walk through the advantages of live media and see if the full installer can also provide them: 1. Try-before-you-buy While it's not advertised or often talked about, you can use the anaconda UI to install Fedora to a USB key or external hard drive to try before you buy. 2. Very fast install time When I installed Fedora 14 via DVD, it took: ‣ 1.5 hours (mostly idle) to download the ISO ‣ 10 minutes to burn the ISO to a DVD and set the computer to burn to DVD ‣ 45 minutes from starting the install to booting into a running desktop When I installed Fedora 14 via LiveMedia, it took: ‣ > 2 active hours and pain to get it downloaded and onto a USB stick ‣ 10-15 minutes for the meat of the install process, but varies based on drive type (that was an SSD) ‣ Total elapsed install time after that, including media check, was 45 minutes. 3. Convenient transition from trying to buying It would be a little less convenient. You would need two USB keys - one for your 'trial' installation of Fedora, the other for the full installer - which you'd use both to create your 'trial' install and your real install-to-hard-disk install. You couldn't click a button from the running 'trial' USB install to install to disk - you'd have to reboot using the installer USB key. 4. Only one image to download for try, install, and rescue You only need to download one ISO with the DVD as well for try & install. I'm not sure about rescue. Can the full installer media be used as a rescue disk or would we need an additional image for this? 5. Constrained / curated package set, no burden on the user to configure too much up front It would be possible to make the full installer behave this way too via comps groups juggling. 6. Live environment means it's easier to take screenshots of crashes and look up helpful information on line to assist with installation This is definitely harder to do in the full installer, but you could always use a camera to take screenshots. There isn't a lot of evidence to indicate that users actually take advantage of the live install environment to look up documentation. Anaconda used to have a documentation pane and it was removed because it simply wasn't being used. Note that some developers told me they like the live environment because they can debug anaconda while it's running and get it working again without a reboot. Definitely a narrow edge-case, though. 7. Viable long-term solution for those with computer access but no administrative control... You can use anaconda to install directly to a USB key. How easy this is to produce live USB keys en masse, I'm not sure. 8. It works off of USB, which is good for the many laptops and slim towers today that come without optical drives. With some modifications LiveUSB-creator could make a bootable full install environment on a USB key. = Can the full installer improve the disadvantages of Live Media? = =================================================================== 1. Live environment is confusing to novice users who don't understand what's going on. The full install environment is clearly its own world and there is no confusion regarding the state of the system when it is fully running, nor is there any temptation to start working on documents that you would then lose if you weren't sure what was really going on. 2.Live environment means it's possible to put the system into a state that anaconda won't know how to deal with it. The full install environment is far more stable and reliable and would likely result in a better overall success rate for users. 3. Getting it onto the USB stick is non-trivial. There are three ways to do it (dd, liveusb-creator command line, liveusb-creator UI) and no single clear path is promoted. Since this would be a new delivery method for Fedora, we have the opportunity to develop clear & consistent messaging for it. 4. Having to download both the ISO and a client to put the image on a USB stick afterwards is a lot to download and hard to figure out for novice users. This would still be an issue, but there are other solutions to this (e.g., offer the liveusb-creator as the default download. LiveUSB-creator can download ISOs for you!) 5. Requires use of isohybrid which means media can't boot on Macs without bootcamp We would still need isohybrid to run anaconda off of a USB stick unfortunately. 6. Dangerous option for long-term use because persistence is still not reliable and depending on the brand of USB key it may just die unpredictably. Data persistence would NOT be an issue with an anaconda-installed USB stick since it's not a live environment. = Summary = =========== In summary, we could say that moving to the full installer would have the potential disadvantages: • Require a modification of liveusb-creator to support the creation of bootable usb media for the full installer • Might possibly require a separate rescue image • Not require much more time for installation if you start out media-less (the website use-case), but would require more time if you are handed a disc or USB key (the conference / LUG / office case). • Require a minor inconvenience - users will need to reboot to install fully while trying out Fedora off of the bootable Fedora USB stick. • Make it a little bit harder to take screenshots and debug the installation process when it fails. It would bring several compelling advantages: • Anaconda-installed Bootable USB media are going to be more reliable and pose less risk to user data and thus less risk to the impact of outreach efforts such as the Girl Scouts program we recently engaged in. • Bootable USB media for Fedora may be easier to create as well as the installer is a single robust method and the same method used for real computer installations. • There will be less confusion about the state of the computer when full anaconda is running. • Less temptation for users to create documents / bookmarks / conversations / other media that will be lost post-install. • The opportunity to present a single, clear and consistent path to getting the bootable installer onto a USB stick. • No live environment means no opportunity for changing the state of the system in unpredictable ways, causing difficult-to-impossible-to-debug crashes in installations. Suggested Path to Getting There • Modify comps-groups / anaconda appropriately to provide a sane, curated default package set via the full installer. ∘ Consult with desktop SIG on this • Modify the website: ∘ to provide links to the full installer by default ∘ Or (even better) modify the website to provide links to liveUSB creator (link may change based on sniffed OS, offer Win / OS X links to the creator as well) ∘ (if needed) Add links to rescue media • Modify liveusb-creator: ∘ streamline live USB creator to make it clear how to download the appropriate ISO ∘ Usability review & redesign for Live USB creator to optimize for new use cases: ‣ create bootable anaconda ‣ create bootable Fedora or install Fedora to disk ∘ Modify liveusb-creator to support the creation of bootable usb media for the installer ∘ Modify liveusb-creator to support OS X • If additional rescue media images are needed, the creation of these added to the release engineering processes • Modify docs to clearly outline new installation steps • Development of docs / website tutorials to outline the new try-before-you-buy USB creation process • Spins.fedoraproject.org and spins in general.... :( I don't know. Replaced with comps groups? Open Questions • Is separate rescue media necessary if we opt for full installer? • What happens to spins.fedoraproject.org? • What happens to spins in general • Is the LiveUSB-creator work required to make this happen feasible? Is it something we can put more effort behind?

8 29

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel February 2011