Re: DNF Migration testing overview
On Fri, Feb 20, 2015 at 05:38:03PM -0700, Mike Ruckman wrote: > Greetings Testers! > > With the F22 switch from yum to dnf as a package manager, there was a need to > figure out what the scope would be for QA testing. Naturally, to define the > scope for a subset, I had to figure out (at least in a general sense) how > large the complete set is. There's a multitude of complication vectors with a > switch like this - especially since dnf is specifically designed to not be a > drop in replacement for yum. > > First question: Who/what all uses yum? > -- > > Swapping out yum is the equivalent of someone coming up with a new form of > hemoglobin, then trying to figure out what all could go wrong when you make > the swap (tl;dr: Everything). The first to come to mind is anyone who installs > packages from the CLI. But then you have all the GUI front-ends (PackageKit > and Apper) and all the build tools - not to mention the installer. > > Some places yum touches: > - Oz/ImageFactory (Building Cloud images) > - koji (RPM-based build system) > - pungi (Build installation trees and isos) > - ABRT (Automatic Bug Reporting Tool) > - Anaconda (Fedora installer) > - liveimage-creator (tool for creating live images) > - cloud-init (tool for configuring freshly launched cloud images) > - FedUp (tool for updating Fedora between releases) > - Software Center and Apper (Default software installers) > - rolekit (tool to easily deploy roles to a Server installation) > - virt-builder and friends (tools for manipulating virtualized environments) There is also lorax (used to create boot.iso). For F22 lorax will continue to use yum. But there is a f22-dnf-branch you can test with if you want. https://github.com/rhinstaller/lorax/tree/f22-dnf-branch For F23 lorax is already using DNF with lorax-23.1 -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
On Thu, Feb 05, 2015 at 10:47:44AM -0500, David Cantrell wrote: > On Thu, Feb 05, 2015 at 09:53:30AM +0100, Matthias Clasen wrote: > > On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote: > > > On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote: > > > > On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote: > > > > > > > > > I think the main point is the one nirik made; I don't think the devs > > > > > agree with your assessment of how significant this is. It's a minor > > > > > inconvenience; you just have to come up with a password that passes > > > > > the check, or use a kickstart. So I don't think they agree that it > > > > > needs a full-blown security audit and FESCo review or whatever, > > > > > because they don't think it's really that huge of a change in > > > > > behaviour. > > > > > > > > Having to come up with a password that passes the check is not 'a minor > > > > inconvenience'. Given how capricious libpwquality is about scoring > > > > (there have been some examples in this thread, there are more in > > > > gnome-initial-setup bugs), it is next to impossible. Next to impossible? Really? I've find it easy to come up with passwords that work. We even report libpwquality's reason for any failures. > > > > This discussion has been pretty heated, but I agree with there being > > > > some aspect of 'collective punishment' here: just because _some_ systems > > > > get installed with sshd enabled, all users who install the Workstation > > > > have to spend a couple of frustrating minutes trying to find a password > > > > that gets them past this hurdle. > > > > > > > > If this change stays, I anticipate the Workstation WG asking for a way > > > > to the workstation installer not enforce this. I know the anaconda folks > > > > are not eager to add variations like this, but that is exactly what we > > > > need: If you want to enforce product-specific policy in the installer, > > > > it needs to be a product-specific installer. > > > > > > You're assuming before asking. With the structure of the installer now, > > > we > > > can look at changes like taking the password aspect and making it > > > product-specific controllable by a number of different methods. Our > > > historic aim to end variant specifics in the installer was because the old > > > code (and variants) lacked a way to assign owners to those product > > > specifics, which meant that requests of the installer to be product > > > specific > > > meant we were asked to be the owners of those specifics. > > > > Let me ask now, then: can we make the change to reject 'weak' passwords > > specific to only those products that enable sshd by default, please ? > > [adding anaconda-devel-list to CC] > > >From a technical standpoint, I see this being possible. Conditionalize it > on sshd being enabled or not. That's not really variant-specific and just a > system condition we could work around. > > I'm putting this on anaconda-devel-list for further discussion. bcl, > others? What are your thoughts on this request? I don't think we should make it act differently. While the change request for sshd setup was the initial reason I wrote the changes, I think that ALL passwords on the system need to be strong these days. I don't find any of the arguments against the change to be compelling. The most valid one is repeated installs of throw-away VMs, and I addressed that in my original post. Just make up a password that passes and write it down. If we do make this conditional, either based on sshd being active, or per-product then where do we stop? Most decisions the installer makes about the system could be called 'enforcing', so do we now have to have a vote on every change? Passwords are the gateway to people's private data. We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Heads up - Anaconda 22.17 will enforce 'good' passwords
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords. I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions. And on the bright side, you don't have to click done twice anymore :) -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
gnupg 1.4.18 for F19 needs some karma
This is a fix for a bug introduced in the previous security release, and it needs some karma -- I guess everyone has updated to F20 :) https://admin.fedoraproject.org/updates/FEDORA-2014-7988/gnupg-1.4.18-1.fc19 Thanks! -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: dracut shell instead of anaconda :-(
This was due to a util-linux bug, pjones patched it this afternoon and tonight's compose should be better. We hope. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Call for gnupg 1.4.17 testing
I have built the new version of gnupg that fixes a security issue, among other things. If you can, please test the new build and leave feedback so we can get these stable ASAP. F19 build - https://admin.fedoraproject.org/updates/FEDORA-2014-7678/gnupg-1.4.17-1.fc19 F20 build - https://admin.fedoraproject.org/updates/FEDORA-2014-7676/gnupg-1.4.17-1.fc20 Thanks! -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: First experience with F18-ALPHA-TC1 (virt-install help)
On Mon, Aug 27, 2012 at 12:15:56PM -0400, Scott Poore wrote: > > > - Original Message - > > From: "Brian C. Lane" > ... > > You can kickstart from a network source with just --cdrom, but if you > > want to use a local kickstart file you need to use --location and > > --cdrom so that anaconda can find stage2. > > I get an error (and have for as long as I can remember) when I try using > --cdrom and --location together: > ... > ERROROnly one install method can be used (--location URL, --cdrom CD/ISO, > --pxe, --import, --boot hd|cdrom|...) > ... > > Or, are you talking about using --disk path=/path/to/iso,device=cdrom? That > seemed to work for me but, I'm not entirely sure that it actually booted from > the iso. Is there a way to tell? Whoops, yes, sorry about that. It doesn't boot from the iso, it still boots from the --location, but it makes the iso available to me mounted. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpVC1f9VJUbB.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: First experience with F18-ALPHA-TC1 (virt-install help)
On Mon, Aug 13, 2012 at 11:02:19PM -0400, Scott Poore wrote: > > > - Original Message - > > From: "Brian C. Lane" > > > > root= really shouldn't be needed, anaconda-dracut is supposed to sort > > that out on media boots. > > > > What you have above isn't booting from the iso though, it uses the > > vmlinuz and initrd (that's what --location does), so you also need to > > mount the iso using --cdrom > > I thought with virt-install I needed to use --location to be able to > kickstart. Is there a way to do it with --cdrom too? Does that require > recreating the iso with my ks.cfg in isolinux/? You can kickstart from a network source with just --cdrom, but if you want to use a local kickstart file you need to use --location and --cdrom so that anaconda can find stage2. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpIwAbkefgyl.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: First experience with F18-ALPHA-TC1
On Mon, Aug 13, 2012 at 01:19:18PM -0400, Scott Poore wrote: > - Original Message - > > From: "Petr Schindler" > > To: test@lists.fedoraproject.org > > Sent: Monday, August 13, 2012 6:42:16 AM > > Subject: Re: First experience with F18-ALPHA-TC1 > > > > Hi, > > > > there is missing root parameter on boot line. If you add > > 'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot line, > > you > > will be able to boot. But it won't help you much, there is a problem > > within anaconda, which should be fixed, so this TC is not working. > > > > Petr, Or anyone that can help, > > Should the root= parameter work from a virt-install kickstart as well? > > virt-install --connect=qemu:///system \ > --network=bridge:virbr0 \ > --initrd-inject=./fed.ks \ > --extra-args="root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64 > ks=file:/fed.ks console=tty0 console=ttyS0,115200 serial" \ > --name=f18 \ > --disk path=/data/VirtualMachines/f18.img,format=qcow2 \ > --ram 1024 \ > --vcpus=1 \ > --check-cpu \ > --hvm \ > --location=/data/isos/F18TC1_x86_64.iso \ > --nographics > > I realize that won't resolve the anaconda issue that's being fixed but, > shouldn't this get past the issue mounting the root filesystem? Or, am I > missing something? root= really shouldn't be needed, anaconda-dracut is supposed to sort that out on media boots. What you have above isn't booting from the iso though, it uses the vmlinuz and initrd (that's what --location does), so you also need to mount the iso using --cdrom -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpmS3htufrce.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 18 Nightly ISOs
On Fri, Jul 20, 2012 at 11:11:13AM -0600, Kevin Fenzi wrote: > On Fri, 20 Jul 2012 09:55:09 -0700 > Adam Williamson wrote: > > > On Fri, 2012-07-20 at 20:47 +0800, Ho Wan Chan wrote: > > > Sorry, it's not Rawhide ISOs, but nightly builds ISOs. They all > > > failed as I see it in this website: > > > http://alt.fedoraproject.org/pub/alt/nightly-composes/ > > > > It's not unusual for nightly compose to fail, especially this early > > in a cycle. Having said that, the error message is an interesting one > > I never saw before, looks like some kind of issue on the build host. > > I've not run them in a while because: > > koji still only knows how to use livecd-creator and my understanding is > that we are switching to using livemedia-creator, but koji doesn't > currently understand how to do that. And given the current state of anaconda's newui rewrite and rawhide's general instability this is hard to test. On Friday I got kickstarts working with my lmc test kickstart so progress is being made. > > I don't know how much time/energy bcl wants to spend on livecd-tools if > we are not going to be using them, and they don't actually test the way > we are composing images. I'm fine with bugfixes, but not with major features/changes. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpouIgjsd5nl.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: live image persistence
On Thu, Jun 07, 2012 at 11:17:05PM -0500, Bruno Wolff III wrote: > On Thu, Jun 07, 2012 at 17:14:05 -0700, > Adam Williamson wrote: > > > >Thoughts? We could theoretically require only the whole-system overlay > >to work, not the separate /home overlay, but the separate /home overlay > >possibility exists for a good reason - the whole-system overlay is very > >easy to exhaust, so if you're going to try and use a persistent stick > >for long-term use, it's much better to also/only have a separate /home > >overlay, which is implemented in a way that's much less prone to space > >exhaustion. Thanks! > > You can also rebuild the OS and OS overlay without overwriting the > home file system, which allows you to update without wasting space > or if you want you kernel updated. > > I think Brian was going to try to have livemedia-creator as the > primary live system for F18. It might be good to hear from him > before commiting to something. The overlay stuff should work the same with lmc created images. Eventually I'd like to merge livecd-iso-to-disk's features into a cli version of liveusb-creator if possible. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpGMaZChTkNI.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Anaconda 17.24-1 reverts to msdos disklabels for new installs
Back in Fedora 16 we tried to advance the state of the art. We switched to using GPT disklabels by default, and in many cases this worked just fine. But it has become increasingly obvious that the hardware isn't ready for us. We continue to get reports of boot problems related to BIOS that attempt to examine the disk before booting and GPT confuses them -- even when we set the PMBR's boot flag. So, for Fedora 17 we are going backwards and will wait for the world to catch up. What's changed: * msdos disklabels will be the default for disks under 2TB * GPT can be forced by passing gpt on the kernel cmdline * nogpt cmdline argument has been removed This only effects BIOS installs. EFI will continue to use GPT, as will disks larger than 2T -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpGCpKMIP5Uc.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Change in behaviour of livecd-tools: Testing required
On Thu, Apr 19, 2012 at 10:13:00AM +0100, Adam Williamson wrote: > On Thu, 2012-04-19 at 13:19 +0530, Ankur Sinha wrote: > > On Thu, 2012-04-19 at 00:28 -0700, Dan Mashal wrote: > > > Hey Francisco, > > > > > > Why don’t we schedule a test day for this? > > > > > > Dan > > > > Hey Dan, > > > > It would be a great. I'm not really a tester, so I don't know the > > procedure etc. I'm just pointing out stuff that I think needs work > > before 17 comes out ;) > > > > Adam, you're the "elder" here :) > > Comments/thoughts? > > A livecd-tools test day in general wouldn't be a terrible idea. It might > be a bit late to do one for F17, though - there aren't many slots left > and we probably don't want to change livecd-tools too drastically before > release now anyway. It might be better to do one in the f18 cycle? > Brian, WDYT? The sooner we test the better :) Given that a significant number of people depend on the various ways of writing to USB (litd, liveusb-creator, dd) we should cover them all. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpMQ7dzZa426.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new Release Criterion proposal: kernel+initrd boot
On Tue, Apr 17, 2012 at 12:08:04PM +0100, Adam Williamson wrote: > On Mon, 2012-04-16 at 10:11 -0400, Kamil Paral wrote: > > > > [1] "The installer must boot (if appropriate) and run on all primary > > > architectures, with all system firmware types that are common on > > > those architectures, from default live image, DVD, and boot.iso > > > install media" > > > > If there are no further objections I'll put it into Alpha criteria tomorrow. > > I'm okay with it, but I'm CCing bcl to give him a chance to object if > anaconda team feels that supporting PXE in Alpha is unnecessarily > ambitious... Yes, I think Alpha is too early to require PXE to work. I'm fine with Beta. In general I think we need to be fairly loose with Anaconda and Alpha -- as long as there is some way to boot the installer I'm happy. We currently don't see alot of installer testing in rawhide so the period before Alpha is too short to expect everything to be working. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpOIU9JcTFO6.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases
On Mon, Apr 09, 2012 at 07:18:26PM -0700, Dan Mashal wrote: > As I said in the meeting let's just deprecate it. > > Upgrade methods as follows: > > 1) YUM > 2) DVD > Actually, it would be better if we dropped DVD upgrades and only used preupgrade. yum upgrades have never been officially supported so that's not something we need to think about. As system layouts become more complicated (btrfs, multi-boot, raid, etc.) it becomes more difficult for a DVD based upgrade to figure out the system's setup without user intervention. With preupgrade you are running it from within the system to be upgraded, it already knows everything it needs to about how to setup the system. All it needs to do pass this on to anaconda when it builds the upgrade grub entry. We would probably want to expand preupgrade the be able to setup the upgrade using the DVD as the package source for those cases when network access isn't available or slow. Brian -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgp8fkiNWI8Xv.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: built-in DVD mediacheck is gone
On Fri, Mar 23, 2012 at 11:50:34PM -0700, Adam Williamson wrote: > On Fri, 2012-03-23 at 23:02 -0700, Adam Williamson wrote: > > On Sat, 2012-03-24 at 05:47 +, Andre Robatino wrote: > > > Adam Williamson redhat.com> writes: > > > > > > > On Fri, 2012-03-23 at 20:24 -0400, Andre Robatino wrote: > > > > > The DVD no longer offers to do a mediacheck (I haven't checked the > > > > > behavior of the live images). Is this reported? > > > > > > > > A quick search of bugz.fedoraproject.org/anaconda doesn't show anything > > > > relevant, so I'm guessing 'no' - can you report it? Thanks! > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=806500 > > > > > > I can't find any blocker criteria for built-in mediacheck. I think it > > > should > > > exist at least in Final, though - in fact I think the netinst images > > > should also > > > have it although they haven't for a while. > > > > Yeah, I think maybe we had a proposal for it? Check the archives... > > So we actually added a criterion to final, but it doesn't exactly cover > this: "If there is embedded checksum on ISO media, it must be correct." > Maybe we want to change that to require mediacheck to be present. If you pass 'check' on the cmdline dracut will run a mediacheck. We may want to add a menu option for that under Troubleshooting. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpLT8CByUu1q.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 ALpha TC2
On Thu, Feb 16, 2012 at 02:38:22PM +0100, Michael Schwendt wrote: > On Thu, 16 Feb 2012 05:01:27 -0500 (EST), KP (Kamil) wrote: > > > > PXEBOOT fails on a Gigabyte GA-P55A-UD3 and on a NFORCEE6M-A > > > with a kernel panic about "no or empty root". > > > > https://bugzilla.redhat.com/show_bug.cgi?id=785815 > > Ordinary GRUB2 boot of the DVD image's vmlinuz+initrd also fails like > that. I've tried to boot with an appropriate repo= parameter as with > Fedora 16 and older, but that also fails. You need to tell dracut where to find the root filesystem, copy the root=live:... from the isolinux.cfg -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpsFCcXmCkQx.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Fedora 17 Alpha Test Compose 2 (TC2) Available Now!
On Fri, Feb 10, 2012 at 07:34:51PM -0700, Orion Poplawski wrote: > > Also, if it needs a new file to boot, shouldn't this be mentioned > somewhere in the .treeinfo file? Oh, right. lorax has been patched to do that. It will be in the next build. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpydhRAzJqxG.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Fedora 17 Alpha Test Compose 2 (TC2) Available Now!
On Fri, Feb 10, 2012 at 02:00:29PM -0700, Orion Poplawski wrote: > On 02/09/2012 06:11 PM, Andre Robatino wrote: > >**IMPORTANT**: There were different versions of the TC2 install and live > >images which were overwritten prior to this announcement. I also briefly > >posted delta ISOs for some of these old images. Please make sure that > >the images you are using correspond to the currently posted checksum files. > > > >As per the Fedora 17 schedule [1], Fedora 17 Alpha Test Compose 2 (TC2) > >is now available for testing. > > I'm trying to do a koan driven vm install using the pxeboot images > and the installer fails to boot with: > > dracut: FATAL: No or empty root= argument > dracut: Refusing to continue > > Am I doing something obviously wrong? yes ;) The rootfs is now in LiveOS/squashfs.img so when doing something like PXE boot or virt-install with --kernel and --initrd you also need to provide squashfs.img somehow and point dracut to it with root=live:... I think you can serve it up via http, but I haven't confirmed this myself. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgp69BRxkYuiS.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GPT and Fedora 17
On Mon, Feb 06, 2012 at 04:54:01PM -0800, Adam Williamson wrote: > On Mon, 2012-02-06 at 23:19 +, Pádraig Brady wrote: > > On 02/06/2012 10:40 PM, Brian C. Lane wrote: > > > In Fedora 16 we changed to using GPT as the default disklabel for new > > > installs. In a few cases, mostly limited to Lenovo hardware, we found > > > that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling > > > back to msdos labels in order to solve this. > > > > > > Thanks to Matthew Garrett we found that switching on the boot flag of > > > the GPT's protective MBR these BIOS's would then boot from GPT. Matthew > > > wrote a patch for parted to allow controlling this flag using the > > > disk_set pmbr_boot command in parted. This is in parted-3.0-7 > > > > > > In anaconda-17.6 I have reverted the Lenovo blacklist and changed things > > > so that pmbr_boot is always set on GPT labeled installs. This should > > > ensure that thing boot correctly. > > > > > > If this still causes problems the symptom will be that grub never starts > > > and the bios may complain about not being able to find an OS. If you > > > have problems with this please open a bug with the output from dmidecode > > > > > > You can still force usage of msdos partitions by passing nogpt on the > > > kernel cmdline. > > > > Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29, > > and it didn't help. I.E. point (1.) from the link referenced here: > > https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31 > > > > Fingers crossed I just missed something at the time. > > I'll try out again tomorrow maybe. > > Yes, I remember that. Please do test the change out and let us know the > results, we'd definitely like to know. > > Brian, this change takes effect from Alpha TC2 (whenever we spin it), > it's not in Alpha TC1, correct? Correct. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpBz5fPzsA1C.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
GPT and Fedora 17
In Fedora 16 we changed to using GPT as the default disklabel for new installs. In a few cases, mostly limited to Lenovo hardware, we found that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling back to msdos labels in order to solve this. Thanks to Matthew Garrett we found that switching on the boot flag of the GPT's protective MBR these BIOS's would then boot from GPT. Matthew wrote a patch for parted to allow controlling this flag using the disk_set pmbr_boot command in parted. This is in parted-3.0-7 In anaconda-17.6 I have reverted the Lenovo blacklist and changed things so that pmbr_boot is always set on GPT labeled installs. This should ensure that thing boot correctly. If this still causes problems the symptom will be that grub never starts and the bios may complain about not being able to find an OS. If you have problems with this please open a bug with the output from dmidecode You can still force usage of msdos partitions by passing nogpt on the kernel cmdline. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpJW46yGdwQO.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
livecd-tools needs testing for F13
The update has been stuck for lack of testing, I'd appreciate it if a few people could give it a try and leave feedback: https://admin.fedoraproject.org/updates/livecd-tools-13.2-1.fc13 I'm especially interested in using livecd-iso-to-disk to make USB sticks with Fedora 15 iso's. Thanks! -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpzx2adEvmb1.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Testing f14 anaconda
On Sat, Oct 16, 2010 at 05:17:05PM +0100, mike cloaked wrote: > Then I used the script from http://fedoraproject.org/wiki/User:Bcl > i.e. the file "upd_bootiso" referenced from that web page, and > executed it with the new anaconda rpm downloaded from a mirror for f14 > updates-testing so that a new boot.iso was written containing the new > anaconda. This gave a file new-boot.iso in /tmp/ which I renamed back > to boot.iso to be used as the test install file. I'm glad to see the script is useful to someone other than just me :) It should (meaning I've done it a couple times with F13) also work for updating a full DVD .iso, it just takes longer. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgp9HNoX71grG.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
