FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 02-06-2012, 04:47 PM
Máirín Duffy
 
Default Summary of boot device selection IRC discussion, Friday 3 Feb

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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 07:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org