Re: Getting harder and harder to debug startup probs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/12 23:32, Clyde E. Kunkel wrote: Is it just me, or is it getting harder and harder to debug Fedora startup problems? We'll see if an old dog can learn new tricks... More general: If you're hit by some bug, you get lost; nowadays sooner than later. I can't count, how many times I had some error getting X up (or even system up) since the move to systemd. Next sad thing is, it isn't reproducible every time. Since we're testing moving targets, it's pretty unclear, how to reproduce the situtation _now_ on _my_ special system? Since I can't login, I can't get a package list. - -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPOM+tAAoJEOnz8qQwcaIWIowH/3vQIPTOAHFFJ4OSnk9j+bKG E7jzomzCJcTemSSveWhdIGmxnxN+KBjEBNlsICV1t29oD/1ueFCwh5RPCJzjsS48 h1QKOz8/xrVGN1IHnPTkMTV3HEVz0amZH9FiaZnpksg0GsKkidrJ5u4oiD2ypf0/ ajQMWYFQLUougZEYrJlLCb14yfWe60UybgwjpWl9XFIVzm1+XKPqSVTxtApKTzqr 5viQ0rIyD8pmZlEernNtGw2db2cF7X74AtVl2tdb9EMRkra6mrruSSu+3KbVTBiJ PRB+rTUZDJvQOk3TsN5bHxhJFkAdNA7P0uTb5YvnThrw2sV8hbKdf1dcrCpnmrc= =ezdf -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Getting harder and harder to debug startup probs
On Mon, 13 Feb 2012, Matthias Runge wrote: More general: If you're hit by some bug, you get lost; nowadays sooner than later. I can't count, how many times I had some error getting X up (or even system up) since the move to systemd. Next sad thing is, it isn't reproducible every time. Since we're testing moving targets, it's pretty unclear, how to reproduce the situtation _now_ on _my_ special system? Since I can't login, I can't get a package list. It isn't just systemd. I don't think gnome-shell helps either, because you tend to get an unhelpful blue screen of death type message if something goes wrong making it difficult to work out what the problem is. Previously the system continued as best it could, meaning you might see what the problem was in what did and didn't appear on the desktop, and might get enough functionality on the desktop to debug the problem more easily. Michael Young -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Installation interfaces criterion proposal
Because nobody had any objections, I've added new criterion to [1] and I've changed release level of [2] to final. [1] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria [2] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Cmdline On Fri, 2012-02-03 at 09:55 -0800, Adam Williamson wrote: On Fri, 2012-02-03 at 17:39 +0100, Petr Schindler wrote: I propose new final criterion: The installer must be able to complete an installation using all supported interfaces Serial port is covered by this one. As I've seen some discussion on anaconda-devel list, it's still supported. I'm still waiting for anaconda opinion of cmdline interface [1]. They should say what they want to support. This criterion ensures that all supported interfaces will work in final release. There is another question. Do we still need text interface?? There is an alpha criterion The installer must be able to complete an installation using the text, graphical and VNC installation interfaces, so it should work. +1, looks good. I don't think there's any intent to drop the text installer, anaconda team has already discussed how to implement a text installer with the UI re-design, so it looks like it's sticking around. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New criterion for Checksum
If you have some objection on this one, please, let me know till tomorrow, otherwise if there are no suggestions I'll make changes. On Wed, 2012-02-01 at 11:40 +0100, Petr Schindler wrote: On Tue, 2012-01-31 at 10:23 -0800, Adam Williamson wrote: On Tue, 2012-01-31 at 07:48 -0500, Petr Schindler wrote: OK, so test case should stay in alpha and new criterion should be in alpha too. I propose to drop the part about embedded checksum (that would be only additional check) and new criterion should be: A correct checksum must be published for each official release image. The second possibility is to have two criteria, first in alpha and second in beta. In beta, there would be included embedded checksum. I think that first option is better. Well, I think we probably want to ensure the embedded checksum is correct at final - it would look silly to ship a release where the built-in media check always fails, after all. So I think we may want to have that second criterion at least for final. You are right. So beside this alpha criterion I propose new final criterion: If there is embedded checksum on ISO media, it must be correct. Test case [1] should be mark as Alpha/Final release level. [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums BTW, Petr, can you set your mail client to wrap at 72 characters, as is conventional? Thanks! I'm sorry. I thought that Zimbra makes this implicitly, my fault. I moved to the Evolution and it seems to work well. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Change of release level of Mediakit ISO Size test case
OK, it looks like discussion ended, so I've moved [1] to beta release level in [2] [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size [2] https://fedoraproject.org/wiki/QA:Fedora_17_Install_Results_Template On Wed, 2012-02-01 at 08:35 -0800, Adam Williamson wrote: On Wed, 2012-02-01 at 08:47 +0100, drago01 wrote: On Tue, Jan 31, 2012 at 7:29 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-01-31 at 11:05 -0500, Petr Schindler wrote: We made this Beta not Alpha in the criteria on purpose, specifically because we don't think it's a significant enough problem if the lives are over-size at Alpha stage. It *may* be worth requiring at least the DVD to meet size requirements at Alpha size, although even if it's over, you can still test it in a VM or with a USB stick. I definitely think we shouldn't make the live sizes mandatory at Alpha. Here I don't know. I test in pre-alpha phase only on my VMs. When I want to boot on bare metal, I use USB stick. But it's truth that nothing new should be added after alpha. So the size of images should be quite the same then or not? Still I think it could be in beta. When we talk about 'nothing being added' after Alpha we're really talking about major features. The package sets on the media can, and do, change. It doesn't happen so much lately, but it's been the case in the past that the Alpha live images were, say, 800MB, because no-one had yet trimmed the package set down to keep them under a CD in size. Then they did get properly trimmed down for Beta or Final. We don't want to block the Alpha if this happens. Yes this has been discussed multiple times but ... do we really still care about omg it does not fit on a CD ? I mean it is 2012 ... It's off-topic for this thread, and it's for the spins to decide for themselves. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
mdraid with encrypted fs
I installed a system fresh with Fedora 15 when it was released. I configured the file system to have root on a software RAID 1 and then encrypted the ext4 file system inside of the raid. I tried to upgrade to F16 a few days ago and ran into an Anaconda bug[1]. Is my particular use-case supported and then does it need a QA test case? I see a test case for encrypted root but not for RAID+encrypted root. In regards to the bug, am I stuck doing a yum upgrade or is there a possible workaround to use preupgrade? [1] https://bugzilla.redhat.com/show_bug.cgi?id=753421 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: mdraid with encrypted fs
On Mon, Feb 13, 2012 at 08:55:11AM -0600, Michael Cronenworth wrote: In regards to the bug, am I stuck doing a yum upgrade or is there a possible workaround to use preupgrade? [1] https://bugzilla.redhat.com/show_bug.cgi?id=753421 Just guessing here but if you are using preupgrade then you will end up really using anaconda with a customized local repository so I would be surprised if you would not hit the same bug again. OTOH at least on one system I did run 'yum --distro-sync ...' moving from F14 to F16 and this worked just fine. If, in a cleanup phase, you will get stuck with higher versions of some packages than equivalents in F16 then run 'yum downgrade ' with a list of such packages and that should take care of the issue. You can really use for that a list of orphans. If something is a real orphan it will be skipped on a downgrade. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GType is actually GFlags
On 11/02/12 01:03, Rob Healey wrote: Greetings: Ever since upgrading from F16 to F17 now to Rawhide, I have been getting this warning message, and I am NOT sure if anyone else is too? Is this on the radar of Fedora yet, and if yes, is there a workaround of not? -- Sincerely yours, Rob G. Healey Seen it too. Crashes with python apps. Have bz'd : https://bugzilla.redhat.com/show_bug.cgi?id=790053 -- Regards FRank -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Thu, Aug 25, 2011 at 10:59 PM, David Lehman dleh...@redhat.com wrote: On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote: Between TC1 and release of F16 Alpha, something must have changed to the worse with regard to installing GRUB to a partition's primary sector. Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3. Anaconda now reports failure to install, and I've found this on virtual console: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partitionj. This is a BAD idea.. /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub2-setup: error: will not proceed with blocklists. Bug or feature? Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742 I did Fedora 16 Respin iso install with all latest packages, including latest Anaconda package, and still had this issue. There were two ntfs partitions (Windows 7 + data partition) and 30 GB of free space. From 30GB free space I created /root # 200 MB, ext4 /swap # 2.5 GB, swap / # 8.0 GB, ext4 /home # 19 GB, btrfs grub2 install fails miserably :( Are there any updates regarding this bug? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Fri, Aug 26, 2011 at 12:20 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2011-08-25 at 15:59 -0500, David Lehman wrote: On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote: Between TC1 and release of F16 Alpha, something must have changed to the worse with regard to installing GRUB to a partition's primary sector. Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3. Anaconda now reports failure to install, and I've found this on virtual console: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partitionj. This is a BAD idea.. /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub2-setup: error: will not proceed with blocklists. Bug or feature? Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742 Also see: https://fedoraproject.org/wiki/Common_F16_bugs#grub2-partition-fail -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net This is a really mayor but and I don't understand it why it fails when I tried grub2-install --force then grub installs without issues :( This should have been a blocker Fedora bug. -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal for enhancement of criterion
Because there was no suggestions, I've made changes. [1] is non-blockig now. And I have amended criterion in [2]. [1] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system [2] https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria On Tue, 2012-01-31 at 09:48 -0800, Adam Williamson wrote: On Tue, 2012-01-31 at 07:15 -0500, Petr Schindler wrote: Especially saving failures to disk is important for installation without net access. There are test cases [1], [2] and [3] for testing this feature. [1] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla [2] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_disk [3] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system Ah, that's part of my last-reply-but-one. :) I think certainly adding local disk at Alpha is reasonable. I'm not so sure about supporting saving to a remote system via ssh at Alpha. Ok, I would propose to change test case [1] to non-blocking. I think it could be enough to support saving reports only to disk and bugzilla. So I propose criterion: The installer must be able to report failures to Bugzilla and local disk, with appropriate information included [1] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system That seems reasonable to me. Anyone else have any thoughts on this? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal for removing Boot method efidisk test case
On Mon, 2012-01-30 at 16:47 -0800, Adam Williamson wrote: On Mon, 2012-01-30 at 11:33 -0500, Petr Schindler wrote: I propose to remove [1] test case as we don't need it anymore. EFI booting is handled by regular image. [1] https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_efidisk.img Ack. For F17, I believe, the plan is not to ship an efidisk.img image at all. Done. This test case is no more in [1] [1] https://fedoraproject.org/wiki/QA:Fedora_17_Install_Results_Template -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Mon, 2012-02-13 at 14:25 -0700, Chris Murphy wrote: On Feb 13, 2012, at 9:16 AM, valent.turko...@gmail.com wrote: I did Fedora 16 Respin iso install with all latest packages, including latest Anaconda package, and still had this issue. There were two ntfs partitions (Windows 7 + data partition) and 30 GB of free space. From 30GB free space I created /root # 200 MB, ext4 /swap # 2.5 GB, swap / # 8.0 GB, ext4 /home # 19 GB, btrfs grub2 install fails miserably :( Are there any updates regarding this bug? I think the problem is GRUB2's own install script/app, doesn't do a great job of accounting for disks partitioned where the 1st partition comes less than 35KB after the MBR, and as the core.img is too large it fails to install between the MBR and partition 1. Strangely though, anaconda manages to get it to install without a complaint. No, that's clearly not the problem here, because this thread is about installing grub to the front of a partition - *not* to the MBR. I'm not sure why it's failing for Valent when it does usually manage to do this successfully, but it's definitely not the issue with the post-MBR 'embedding area' being too small. That's an entirely separate issue. anaconda only calls grub2-install, with appropriate parameters, to install grub. It doesn't do anything particularly special or clever. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Mon, 2012-02-13 at 17:21 +0100, valent.turko...@gmail.com wrote: This is a really mayor but and I don't understand it why it fails when I tried grub2-install --force then grub installs without issues :( This should have been a blocker Fedora bug. anaconda already uses grub2-install --force, and installation to a partition does not *generally* fail - it's failing in your specific case for some reason I don't know, but it's not the case that *any* attempt to install grub2 to a partition with F16 fails. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Proven tester status
Just wanted to make note of the current status of proven testers. As decided by FESCo late last year, proven tester feedback now has exactly the same status as non-proven tester feedback, effectively rendering it pointless to be a proven tester. I have added a note about this to the proven tester page: https://fedoraproject.org/wiki/Proven_tester As noted there, and as discussed at meetings and with FESCo, I'm hopeful we'll be able to make use of proven tester status again once Bodhi 2.0 hits. Therefore I don't think we should take down all the documentation, kill the group, or stop accepting membership requests. But do be aware that, at present, proven tester status is basically meaningless. Of course, there'll be lots of discussion at QA meetings and FESCo meetings before we decide whether and how to 'reactivate' the group. Thanks all! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Getting harder and harder to debug startup probs
On Mon, 2012-02-13 at 10:59 +, M A Young wrote: On Mon, 13 Feb 2012, Matthias Runge wrote: More general: If you're hit by some bug, you get lost; nowadays sooner than later. I can't count, how many times I had some error getting X up (or even system up) since the move to systemd. Next sad thing is, it isn't reproducible every time. Since we're testing moving targets, it's pretty unclear, how to reproduce the situtation _now_ on _my_ special system? Since I can't login, I can't get a package list. It isn't just systemd. I don't think gnome-shell helps either, because you tend to get an unhelpful blue screen of death type message if something goes wrong making it difficult to work out what the problem is. Previously the system continued as best it could, meaning you might see what the problem was in what did and didn't appear on the desktop, and might get enough functionality on the desktop to debug the problem more easily. I'd say the answer to the question is 'no, it's just different'. systemd actually makes it *easier* to debug startup issues, really, because it has good and sophisticated tools for investigating the status of all services and the dependencies between them. But it's _different_ from sysv/upstart, and you have to learn how to use the tools and logs. Once you do that, it's actually much better. You can see from the bug report how Kay diagnosed this particular dbus/dracut issue: you can do that too. Also learn how to use systemctl - the man page is great. For Shell, whatever causes the fail whale will almost invariably be pointed up by ~/.xsession-errors; you just have to read it carefully. The fail whale comes up if any one of a certain set of core GNOME components spawns (runs) more than twice within a 60 second period - this is intended to catch crash/respawn loops. So you're looking for a component - usually shell itself, or gdm, or gnome-settings-daemon - crashing more than once. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Proven tester status
On Mon, Feb 13, 2012 at 18:20:38 -0800, Adam Williamson awill...@redhat.com wrote: As noted there, and as discussed at meetings and with FESCo, I'm hopeful we'll be able to make use of proven tester status again once Bodhi 2.0 hits. Therefore I don't think we should take down all the documentation, kill the group, or stop accepting membership requests. But do be aware that, at present, proven tester status is basically meaningless. Note that statistics are still gathered and that future changes might depend on whether or not proventesters do a better job than average of correctly tagging builds as good or bad. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: mdraid with encrypted fs
On Mon, 2012-02-13 at 08:55 -0600, Michael Cronenworth wrote: I installed a system fresh with Fedora 15 when it was released. I configured the file system to have root on a software RAID 1 and then encrypted the ext4 file system inside of the raid. I tried to upgrade to F16 a few days ago and ran into an Anaconda bug[1]. Is my particular use-case supported and then does it need a QA test case? I see a test case for encrypted root but not for RAID+encrypted root. In regards to the bug, am I stuck doing a yum upgrade or is there a possible workaround to use preupgrade? I'd suggest that this is 'supported' in terms of the release criteria, under the Final criterion The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above: we don't explicitly list encryption there, but we probably should, and I'd read the intent of the criterion as being that encryption should be covered. So, I'd say you could propose your bug as a Final blocker. As far as 'should there be a test case' - well, it's kind of a tricky question: there are essentially unlimited permutations when it comes to filesystem layout, and we can't have a test case for *every single one*, especially not a test case that must be done for the release to proceed. There'd be no harm at all in you drawing up a test case for this scenario, but whether we should add it to the matrices and especially whether we should mark it as Final (indicating it has to be completed for the release to ship) is a more difficult question. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Getting harder and harder to debug startup probs
On Mon, 2012-02-13 at 18:30 -0800, Adam Williamson wrote: On Mon, 2012-02-13 at 10:59 +, M A Young wrote: On Mon, 13 Feb 2012, Matthias Runge wrote: More general: If you're hit by some bug, you get lost; nowadays sooner than later. I can't count, how many times I had some error getting X up (or even system up) since the move to systemd. Next sad thing is, it isn't reproducible every time. Since we're testing moving targets, it's pretty unclear, how to reproduce the situtation _now_ on _my_ special system? Since I can't login, I can't get a package list. It isn't just systemd. I don't think gnome-shell helps either, because you tend to get an unhelpful blue screen of death type message if something goes wrong making it difficult to work out what the problem is. Previously the system continued as best it could, meaning you might see what the problem was in what did and didn't appear on the desktop, and might get enough functionality on the desktop to debug the problem more easily. I'd say the answer to the question is 'no, it's just different'. systemd actually makes it *easier* to debug startup issues, really, because it has good and sophisticated tools for investigating the status of all services and the dependencies between them. But it's _different_ from sysv/upstart, and you have to learn how to use the tools and logs. Once you do that, it's actually much better. You can see from the bug report how Kay diagnosed this particular dbus/dracut issue: you can do that too. Also learn how to use systemctl - the man page is great. For Shell, whatever causes the fail whale will almost invariably be pointed up by ~/.xsession-errors; you just have to read it carefully. The fail whale comes up if any one of a certain set of core GNOME components spawns (runs) more than twice within a 60 second period - this is intended to catch crash/respawn loops. So you're looking for a component - usually shell itself, or gdm, or gnome-settings-daemon - crashing more than once. Oh, extending that: how I usually confirm and get more info on 'fail whale' scenarios is to leave the broken GNOME session running and switch to a VT, log in as myself, and look at .xsession-errors. When I think I've spotted what process is failing, I do this: DISPLAY=:0 (command) So if it's gnome-settings-daemon that's failing, I do: DISPLAY=:0 /usr/libexec/gnome-settings-daemon that tries to run the process in question *in the X session*, not in the terminal you're actually typing the command from. That way you can confirm that it really is that process that's failing, and get any error output it spits out to the console but doesn't put in logs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: mdraid with encrypted fs
On 02/13/2012 08:35 PM, Adam Williamson wrote: I'd suggest that this is 'supported' in terms of the release criteria, under the Final criterion The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above: we don't explicitly list encryption there, but we probably should, and I'd read the intent of the criterion as being that encryption should be covered. So, I'd say you could propose your bug as a Final blocker. It looks like it has just been marked as a Beta blocker. As far as 'should there be a test case' - well, it's kind of a tricky question: there are essentially unlimited permutations when it comes to filesystem layout, and we can't have a test case for*every single one*, especially not a test case that must be done for the release to proceed. There'd be no harm at all in you drawing up a test case for this scenario, but whether we should add it to the matrices and especially whether we should mark it as Final (indicating it has to be completed for the release to ship) is a more difficult question. Your test matrix already includes RAID and encryption but not together. The problem post-release is that how do I upgrade? Wait for F17 for a fix? Roll my own installer ISO? Use yum? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: mdraid with encrypted fs
On Mon, 2012-02-13 at 21:04 -0600, Michael Cronenworth wrote: On 02/13/2012 08:35 PM, Adam Williamson wrote: I'd suggest that this is 'supported' in terms of the release criteria, under the Final criterion The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above: we don't explicitly list encryption there, but we probably should, and I'd read the intent of the criterion as being that encryption should be covered. So, I'd say you could propose your bug as a Final blocker. It looks like it has just been marked as a Beta blocker. It's been proposed as one - because, according to dlehman, the encryption isn't actually relevant; it seems the issue will affect any system which has an mdraid partition on upgrade. As far as 'should there be a test case' - well, it's kind of a tricky question: there are essentially unlimited permutations when it comes to filesystem layout, and we can't have a test case for*every single one*, especially not a test case that must be done for the release to proceed. There'd be no harm at all in you drawing up a test case for this scenario, but whether we should add it to the matrices and especially whether we should mark it as Final (indicating it has to be completed for the release to ship) is a more difficult question. Your test matrix already includes RAID and encryption but not together. Yes - it has, what, a hundred or so tests? Most of those could be combined with at least one of the others...you don't need to be able to do the math very precisely to realize that we can't, practically speaking, have a test case for *every possible combination* :) The problem post-release is that how do I upgrade? Wait for F17 for a fix? Roll my own installer ISO? Use yum? You can ask in the bug for an updates image for the F16 installer. See https://fedoraproject.org/wiki/Anaconda/Updates . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: mdraid with encrypted fs
On 02/13/2012 09:13 PM, Adam Williamson wrote: Yes - it has, what, a hundred or so tests? Most of those could be combined with at least one of the others...you don't need to be able to do the math very precisely to realize that we can't, practically speaking, have a test case for*every possible combination* :) I'm not trying to fight with you about adding yet another test case. If I had the time I would have tested the F16 installer and reported this bug to you sooner. :) You can ask in the bug for an updates image for the F16 installer. See https://fedoraproject.org/wiki/Anaconda/Updates . I will look into this. Thanks. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
