Hi, On Friday we had a discussion about boot device selection in the new UI. David L started it with: <dlehman> maybe we need to introduce a screen or widget in the autopart flow to make them pick a boot disk before any partitions are allocated. perhaps we should make them pick the boot disk up front even for custom partitioning <dlehman> that will reduce complexity everywhere. and, really, can anyone say they don't know which disk they'll be booting from before they start the install? ISSUE: BOOT DEVICE SELECTION ============================ The new UI mockups don't currently account for boot disk selection. If we were to add it, where would it go...? In the current UI, we have a clearpart screen. You don't see it until late in the install process for custom partitioning. It would be ideal, according to David, to know which disk is meant to be the boot device before we touch any partitions. If you're a user who needs to pick which disk to boot off of, how do you know how to make the right decision? - if you only have one local disk (laptop) then it's that disk. - if you have multiple disks, it's the disk you have set to boot from your firmware. - the first local, non-removable disk is the obvious default If you pick the wrong disk for boot, your firmware won't know where the os is and will pop up an 'operating system not found' error. There are some complicated cases, though: (1) CHAINLOAD / MULTI-BOOT If you have chainload set up (multi-boot scenario) then you'll only need stage2 (/boot) and you'll always get that. (2) REMOVABLE MEDIA Say you have a one-disk laptop with usb media: we don't necessarily have a good way of knowing whether it would be reasonable to let a user pick the usb device or not (and one of the devices may have the installer itself on it). it is nearly impossible these days to find out from anaconda if a device contains boot media. the symptom of picking a usb or other removable device as your boot disk is that when the device is removed from your machine, it won't boot. wwoods says that we will, as of f17, be able to tell if a given disk, usb or otherwise, contains the install media. That helps this scenario to an extent - we'll be smart enough not to display anaconda's media as a choice - but if I have say an sdcard stuck in the slot i forgot to pull out last time i downloaded pictures off of my camera - then when I put it in my camera my OS won't boot. There's two base cases in this situation: - I want *this system* to be bootable vs. - I'm using this system to make a *removable device* bootable <= super edge case If we know the user's intention at that level in this scenario, then we know which boot options to offer them. Us there any kind of device metadata we have about someone's machine to refer to it? So we could say something like, "Do you want to run Fedora on your Lenovo x220T, or one of your removable devices?" Would anybody ever want to make a usb stick a boot device for a system that has critical mountpoints on other devices? E.g., / is on usb disk 1, /home is on usb disk 2, /var is on some random hard drive <= seems like a messy soup of pain "There's always going to be that guy who wants to install to a USB (real) disk and move it from one machine to another, but there's literally like two or three such guys on the planet." Let's not ruin the experience for everyone for the sake of these three people. (3) NETWORK BOOT DEVICE You may want to set a network drive as a boot disk. This is done with iscsi. ibft is the mechanism. (ibft = Iscsi Boot Firmware Table) the firmware keeps track of the iscsi target (the storage) that it authenticated to and booted from, and then it fills out the ibft structure in ram, and the OS goes and finds it there and uses that data to setup storage a second time. The firmware to do this may not become as widespread as PXE... today it is common on IBM servers, many intel pcie network cards can be flashed with firmware to enable it... it won't be uncommon on server hardware. from anaconda, do we know whether or not the device we're running on supports this? we expose it in sysfs via a kernel driver, so various tools wind up checking in sysfs. the trick is that it's not something the iscsi target (the storage) knows about... you'll only see ibft data if somebody has already set it up as a boot device in their platform firmware, of course. But at that point, yeah, we can detect it. if it's not set up in the firmware, we can't support it - the user has to tell their firmware, no matter what the case, what device to boot from and we cant do that for them. - non ibft network devices - we support nfsroot via dhcp, but there isn't anything in anaconda to support it. Summary of devices to be supported: * We have laptops, 1 drive = easy. it shouldn't pop anything up to the user - it should just set that single hard drive as the boot device * Laptops with USB devices = tricky, is it a usb key or a real disk? * Servers with multiple disks = okay, user must pick the right disk * Servers with ibft = we can tell they're using it and offer it as an option for boot * A desktop computer with multiple internal disks = hope the user set the jumpers and the firmware up correctly ISSUE: UNPARTITONED BOOT DISKS ============================== We only support booting from partitioned disks, which is reasonable. There is the possibility that some disks are not partitioned at the time we are presenting boot disk choices. in this case, they may choose an empty/new/lvmpv (not partitioned) disk, in which case we'll have to warn them that they must allow us to reinitialize this device so that we can put a disklabel on it and therefore make it boot-worthy. The risk of reinitialized disks without telling the user is that they would lose any data on their disk - any disk, any data. We can't wait until the user has made their partitioning/fs selections to ask, because he boot device will have special requirements which can only be satisfied in the partitioning process. For example, if they want to boot from sdd which is unpartitioned with an ext3 fs on it, we're gonna need to put a disklabel on that. If they want to boot from sdb which is empty, we know we'll need to put a bios boot partition on it so they can boot from it. We definitely need to make the selection of unpartitioned boot devices opt-in, so by default the unpartitioned devices aren't like a little booby-trap in the list of possible boot devices. SUMMARY ======= We should assume local boot disk by default and select the first non-removable one by default. We should provide an opt-in way to view the boot device we selected (rather than explicitly asking via pop-up, etc.) Let users change the boot device, and let them opt-in to being able to choose from removable and unpartitioned devices (by default, we won't display removable or unpartitioned devices in the list.) For IBFT users... if we see a signal in RAM that they are booted that way, we should explicitly ask them if they want to set the IBFT device as their boot device. At that point, we can safely assume they know what they are doing and set up their firmware for it, and they'd appreciate the convenience. There wouldn't be a risk of confusing newbie fedora desktop users here since they wouldn't have that pre-requisite of having IBFT configured in their BIOS/firmware. We should allow them to manually say that an iscsi disk they've added is the boot device if it uses a proprietary iscsi boot rom that we can't support... this should be a deeply-nested opt-in, under the area you opt-in to customize your boot device described above. Does this make sense? ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
