For technical background, see https://bugzilla.redhat.com/show_bug.cgi?id=735733 But the summary is this: Most of the Lenovo Thinkpads in use will not boot after a Fedora 16 install with GPT disk label. They need the boring MSDOS disk labels. 735733 adds the "nogpt" flag, however, given the common use case of Lenovo Thinkpads and Fedora, we need to check the DMI for Lenovo and if found, default to the MSDOS disk labels in this case, without the need for any magic boot flags.
fwiw, I personally am +1 blocker on this, we ought to blacklist thinkpads to ms-dos labels. it's just a much better situation to have, say, 50% of thinkpads using msdos disklabels when they don't really need to, than to have, say, 50% of thinkpads fail to boot after install. we don't know _exactly_ what that ratio is, but anything inside of 20/80 in either direction would give the same result, for me.
oh, to avoid an obvious gotcha: any blacklist should only apply to *non*-EFI installs. obviously we'd still want to use gpt labels when doing an EFI install on a Thinkpad, I think...
Docked Lenovo Thinkpad T500 [spot@pterodactyl ~]$ sudo dmidecode -s "chassis-manufacturer" LENOVO LENOVO [spot@pterodactyl ~]$ sudo dmidecode -s "chassis-type" Notebook Peripheral Chassis Lenovo Thinkpad X220 Tablet (also in an ultradock, but dmidecode doesn't see that) [spot@pandamotor ~]$ sudo dmidecode -s "chassis-manufacturer" LENOVO [spot@pandamotor ~]$ sudo dmidecode -s "chassis-type" Notebook
To test this abomination, add the following to your boot or liveinst command line: updates=http://dlehman.fedorapeople.org/updates-gpt-blacklist.0.img Let me know how it goes, of course.
pjones confirmed this does indeed create msdos label on a thinkpad, and i confirmed it still creates gpt label on a VM, so looks good.
note that a consequence of this fix will be that you won't be able to install to >2TB disks in Lenovo systems, I think, unless you use EFI or pre-format the drive and ensure anaconda doesn't re-format the whole thing.
+1, blocker
for those playing along at home with pocket protectors, the criterion here is "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to create a working user account" (Alpha). Affected systems boot to a black screen after install, not firstboot. =)
we have devel +1 (spot), qa +1 (me), program manager +1 (rberge), that's good enough for government work. acceptedblocker.
anaconda-16.24-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.24-1.fc16
Can someone with an affected system please just verify that this is fixed in TC3? http://dl.fedoraproject.org/pub/alt/stage/16.TC3/ we're 99% sure it is, but just for the record. thanks!
anaconda 16.24-2 (glibc rebuild) went stable, so CLOSING. We could still do with verification that this is fixed in TC3 or pending RC1. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
works on Lenovo W510 if the drive is completely repartioned. Did not work when attempting to use existing F16 Beta partitions.
yes, that would be expected. it's only going to change the disk label when completely reformatting the drive. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Workaround confirmed on ThinkPad T520.