Re: Change of release level of Mediakit ISO Size test case
On Tue, Jan 31, 2012 at 7:29 PM, Adam Williamson 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 ... -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New testcase for installation without selinux
On 01/31/2012 09:00 PM, Adam Williamson wrote: On Tue, 2012-01-31 at 11:43 -0500, Chris Lumens wrote: "The installed system must run normally if the user chooses to install without SELinux" There is no test case for this now. I have one note on this. There is used noselinux option, but it doesn't work now. I filled bug [2] there is another option with the same effect - selinux=0 and this one works fine, but Anaconda have noselinux in documentation, so it should work and they're working on it. The option to install without selinux was added at a time when selinux was a new, experimental feature in Fedora. Now, it's an integral part of the distribution. It's time for this option to go away. I disagree. Though SELinux isn't in the poor shape it once was, there are still situations, where users prefer or can not avoid to switch off SELinux. If we don't want to support that, the alternative is to ditch the release criterion. I'm okay with that. I am not OK with that. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 17’s unified filesystem (/usr-move)
On Wed, 2012-02-01 at 02:38 +0100, Kay Sievers wrote: > > Installation fails at partitioning stage, with udisksd hitting "Error > > opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such > > file or directory (g-file-error-quark, 4)" > > > > The file /etc/crypttab indeed doesn't exist. I'm not sure if this is > > actually specific to the /usr move stuff, but it does prevent me being > > able to ensure that installation works from a /usr-moved live image. I > > have a non-usr-move image also, I'll test install with that. > > Sounds unlikely that this is related. But tests should show. > > Unrelated: Do you know if the installer uses udisks? If, it should > probably switch to the current udisks2, because udisks will not much > longer be supported, and we should people give a note about that. Confirmed that this bug is not related to /usr move. I'm working with anaconda team now to try and get an anaconda that's actually capable of completing a live install, with or without the /usr move stuff. I'm not sure if anaconda uses udisks directly, or if it's something else calling udisksd. The udisksd error may not actually have been the cause of the anaconda crash, according to bcl. -- 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 installation with minimal set of packages
On Tue, Jan 31, 2012 at 2:56 PM, Bill Nottingham wrote: >> That's an implementation detail. It's not a capability-driven >> description of which packages should actually be in the minimal package >> set, as was discussed earlier in the thread. > > Merely stating that if you're linking to what the minimal set of packages > will be, that's it. But to Adam's point, who defines what is in @core and what it can do? Could I decide tomorrow that the GNOME desktop is a core functionality of the distro and commit it to comps and so it is (I seriously hope someone would come shoot me if I *actually* did that :) )? I guess this goes to the point that no one "owns" comps groups, but I think someone should, and @core (and to a lesser extent @base) should be "special" to have some defined set of functionality. But I think this is getting *way* off topic for QA and should be a fesco discussion :) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, 2012-01-31 at 14:23 -0800, Adam Williamson wrote: > On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote: > > Hello Testers and rawhide Users, > > > > Fedora 17 will locate the entire base operating system in /usr. The > > directories > > /bin, /sbin, /lib, /lib64 will only be symlinks: > > /bin → /usr/bin > > /sbin → /usr/sbin > > /lib → /usr/lib > > /lib64 → /usr/lib64 > > I've just tested building a live image from the /usr move repository. It > boots, and the /usr move changes appear to be implemented. I'm currently > testing if it can be installed successfully. > > One thing I already noticed is that there seems to be a problem with the > ntfs-3g executables. /bin/ntfs-3g seems to be a symlink to itself - it > shows as "/bin/ntfs-3g -> /bin/ntfs-3g" in ls output. Trying to do 'ls > -l /usr/bin/ntfs-3g' results in 'cannot access /usr/bin/ntfs-3g: Too > many levels of symbolic links'. /bin/ntfsmount is similarly affected. > > On a pre-/usr move system it seems that these executables are actually > located in /bin but have symlinks in /usr/bin - /usr/bin/ntfs-3g is a > symlink to /bin/ntfs-3g . Perhaps the existence of these symlinks > in /usr/bin confused things? Installation fails at partitioning stage, with udisksd hitting "Error opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such file or directory (g-file-error-quark, 4)" The file /etc/crypttab indeed doesn't exist. I'm not sure if this is actually specific to the /usr move stuff, but it does prevent me being able to ensure that installation works from a /usr-moved live image. I have a non-usr-move image also, I'll test install with that. -- 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: Fedora 17’s unified filesystem (/usr-move)
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote: > Hello Testers and rawhide Users, > > Fedora 17 will locate the entire base operating system in /usr. The > directories > /bin, /sbin, /lib, /lib64 will only be symlinks: > /bin → /usr/bin > /sbin → /usr/sbin > /lib → /usr/lib > /lib64 → /usr/lib64 I've just tested building a live image from the /usr move repository. It boots, and the /usr move changes appear to be implemented. I'm currently testing if it can be installed successfully. One thing I already noticed is that there seems to be a problem with the ntfs-3g executables. /bin/ntfs-3g seems to be a symlink to itself - it shows as "/bin/ntfs-3g -> /bin/ntfs-3g" in ls output. Trying to do 'ls -l /usr/bin/ntfs-3g' results in 'cannot access /usr/bin/ntfs-3g: Too many levels of symbolic links'. /bin/ntfsmount is similarly affected. On a pre-/usr move system it seems that these executables are actually located in /bin but have symlinks in /usr/bin - /usr/bin/ntfs-3g is a symlink to /bin/ntfs-3g . Perhaps the existence of these symlinks in /usr/bin confused things? -- 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
Fedora 15 updates-testing report
The following Fedora 15 Security updates need testing: https://admin.fedoraproject.org/updates/FEDORA-2012-1077/wicd-1.7.0-11.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0888/curl-7.21.3-13.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0939/moodle-1.9.16-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0917/znc-0.204-3.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0916/bip-0.8.8-2.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0987/mysql-5.5.20-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0752/jetty-6.1.26-7.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0826/BackupPC-3.2.1-7.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0849/polipo-1.0.4.1-6.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-1066/ettercap-0.7.4-3.fc15 https://admin.fedoraproject.org/updates/FEDORA-2011-17233/tor-0.2.1.32-1500.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0353/pdns-2.9.22.5-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2011-16980/asterisk-1.8.7.2-1.fc15 The following Fedora 15 Critical Path updates have yet to be approved: https://admin.fedoraproject.org/updates/FEDORA-2012-1097/nss-3.13.1-11.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-1068/systemd-26-15.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-1070/krb5-1.9.2-6.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-1085/gnupg-1.4.12-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0987/mysql-5.5.20-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0997/rsyslog-5.8.7-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0929/rpm-4.9.1.2-3.fc15.3 https://admin.fedoraproject.org/updates/FEDORA-2012-0943/system-config-printer-1.3.8-2.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0762/redhat-rpm-config-9.1.0-16.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-0659/virtuoso-opensource-6.1.4-4.fc15 https://admin.fedoraproject.org/updates/FEDORA-2011-13190/phonon-backend-gstreamer-4.5.90-2.fc15,phonon-4.5.57-1.20110914.fc15 https://admin.fedoraproject.org/updates/FEDORA-2011-11955/evolution-mapi-3.0.3-2.fc15,evolution-exchange-3.0.3-1.fc15,evolution-3.0.3-1.fc15,evolution-data-server-3.0.3-1.fc15,gtkhtml3-4.0.2-1.fc15 The following builds have been pushed to Fedora 15 updates-testing bacula-5.0.3-26.fc15 cherrytree-0.25.2-1.fc15 ettercap-0.7.4-3.fc15 glade3-3.10.0-3.fc15 gnupg-1.4.12-1.fc15 gpredict-1.3-4.fc15 ibus-hangul-1.4.0-2.fc15 jd-2.8.5-0.2.svn3993_trunk.fc15 krb5-1.9.2-6.fc15 mtpaint-3.40-1.fc15 nss-3.13.1-11.fc15 python-docutils-0.8.1-2.fc15 rt3-3.8.11-6.fc15 sevmgr-0.2.0-1.fc15 systemd-26-15.fc15 tcpflow-1.1.0-1.fc15 tudu-0.8.1-1.fc15 wicd-1.7.0-11.fc15 Details about builds: bacula-5.0.3-26.fc15 (FEDORA-2012-1081) Cross platform network backup for Linux, Unix, Mac and Windows Update Information: Correct license to AGPLv3, split off libs in separate backends and fix ldconfig/alternatives symlinks on removal of packages. ChangeLog: * Mon Jan 30 2012 Simone Caronni - 5.0.3-26 - Fix ldconfig/alternatives symlinks on removal of packages. * Mon Jan 30 2012 Lukas Nykryn - 5.0.3-25 - Remove dependency on WxGTK in RHEL. * Fri Jan 27 2012 Simone Caronni - 5.0.3-24 - Correct license to AGPLv3. - Split off libs in separate backends. - Trim changelog for version <5.0.0. * Thu Jan 26 2012 Simone Caronni - 5.0.3-23 - Add ldconfig after setting up symlinks for libbacsql variants. References: [ 1 ] Bug #784587 - Bacula director broken, trys to connect to postgresl when database is mysql https://bugzilla.redhat.com/show_bug.cgi?id=784587 cherrytree-0.25.2-1.fc15 (FEDORA-2012-1084) Hierarchical note taking application Update Information: Upstream bugfix release ChangeLog: * Wed Jan 25 2012 Robin Lee - 0.25.2-1 - Update to 0.25.2 ettercap-0.7.4-3.fc15 (FEDORA-2012-1066) Network traffic sniffer/analyser, NCURSES interface version --
Fedora 16 updates-testing report
The following Fedora 16 Security updates need testing: https://admin.fedoraproject.org/updates/FEDORA-2012-1059/wicd-1.7.0-10.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0913/moodle-2.0.7-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0921/znc-0.204-3.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0941/bip-0.8.8-2.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0730/jetty-6.1.26-8.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0972/mysql-5.5.20-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0825/BackupPC-3.2.1-7.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0840/polipo-1.0.4.1-6.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1098/samba-3.6.3-78.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1054/ettercap-0.7.4-3.fc16 https://admin.fedoraproject.org/updates/FEDORA-2011-14691/tomcat6-6.0.32-19.fc16 The following Fedora 16 Critical Path updates have yet to be approved: https://admin.fedoraproject.org/updates/FEDORA-2012-1064/nss-3.13.1-11.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1089/evolution-data-server-3.2.3-2.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1073/clutter-1.8.4-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1067/krb5-1.9.2-6.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1061/gnupg-1.4.12-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1098/samba-3.6.3-78.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1062/net-tools-1.60-126.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1031/coreutils-8.12-6.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-1025/alsa-lib-1.0.25-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0972/mysql-5.5.20-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0934/strigi-0.7.7-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0820/schroedinger-1.0.11-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-0689/virtuoso-opensource-6.1.4-4.fc16 https://admin.fedoraproject.org/updates/FEDORA-2011-15301/lxpanel-0.5.8-1.fc16,lxinput-0.3.1-1.fc16,lxsession-edit-0.2.0-1.fc16,lxrandr-0.1.2-1.fc16,lxpolkit-0.1.0-1.fc16,lxterminal-0.1.11-1.fc16,lxshortcut-0.1.2-1.fc16 The following builds have been pushed to Fedora 16 updates-testing bacula-5.0.3-26.fc16 cherrytree-0.25.2-1.fc16 clutter-1.8.4-1.fc16 ettercap-0.7.4-3.fc16 evolution-data-server-3.2.3-2.fc16 glade3-3.10.0-6.fc16 gnome-tweak-tool-3.2.2-2.fc16 gnupg-1.4.12-1.fc16 gpredict-1.3-4.fc16 ibus-hangul-1.4.0-2.fc16 jd-2.8.5-0.2.svn3993_trunk.fc16 krb5-1.9.2-6.fc16 lcov-1.9-1.fc16 m4ri-20111203-1.fc16 mtpaint-3.40-1.fc16 net-tools-1.60-126.fc16 nss-3.13.1-11.fc16 perl-Gnome2-Vte-0.09-1.fc16 python-docutils-0.8.1-2.fc16 python-libcloud-0.6.2-3.fc16 python-sqlalchemy-0.7.5-1.fc16 qemu-0.15.1-4.fc16 redis-2.4.6-2.fc16 rsh-0.17-68.fc16 rt3-3.8.11-6.fc16 samba-3.6.3-78.fc16 sevmgr-0.2.0-1.fc16 spice-gtk-0.9-1.fc16 srm-ifce-1.12.2-6.fc16 tcpflow-1.1.0-1.fc16 tudu-0.8.1-1.fc16 vala-0.14.1-1.fc16 wicd-1.7.0-10.fc16 Details about builds: bacula-5.0.3-26.fc16 (FEDORA-2012-1072) Cross platform network backup for Linux, Unix, Mac and Windows Update Information: Correct license to AGPLv3, split off libs in separate backends and fix ldconfig/alternatives symlinks on removal of packages. ChangeLog: * Mon Jan 30 2012 Simone Caronni - 5.0.3-26 - Fix ldconfig/alternatives symlinks on removal of packages. * Mon Jan 30 2012 Lukas Nykryn - 5.0.3-25 - Remove dependency on WxGTK in RHEL. * Fri Jan 27 2012 Simone Caronni - 5.0.3-24 - Correct license to AGPLv3. - Split off libs in separate backends. - Trim changelog for version <5.0.0. * Thu Jan 26 2012 Simone Caronni - 5.0.3-23 - Add ldconfig after setting up symlinks for libbacsql variants. References: [ 1 ] Bug #784587 - Bacula director broken, trys to connect to postgresl when database is mysql https://bugzilla.redhat.com/show_bug.cgi?id=784587 cherrytree-0.25.2-1.fc16 (FEDORA-2012-1095) Hierarchical note taking application Update Information: Upstream bugfix release ChangeLog: * W
Re: usrmove problem
On 31/01/12 20:25, Adam Williamson wrote: Has anyone else who's done the /usr move tried to install a kernel after the move? If so, does it work, or do you hit the same problem Tom hit? I ran into the same problem, but after seeing Tom's post held off reporting. Will check more guests in the morning. -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: usrmove problem
On Tue, Jan 31, 2012 at 3:25 PM, Adam Williamson wrote: > On Tue, 2012-01-31 at 09:26 -0800, Adam Williamson wrote: >> On Tue, 2012-01-31 at 10:44 -0500, Tom H wrote: >> >> > >> Also, the problem is in your initramfs, not the kernel itself. >> > >> >> > >> Harald? >> > > >> > > I was about to follow up. I tried rebuilding the rc6 kernel's >> > > initramfs but there was no joy. I then managed to boot with the rc6 >> > > kernel using the rc4 initramfs. >> > > >> > > I've unpacked my the rc4 and rc6 initramfs's to take a look but have >> > > had to go back to real work... >> > >> > Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and >> > initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6": >> > >> > [root@localhost ~]# find . -name 'libc.so.6' >> > ./rc4/run/initramfs/lib/libc.so.6 >> > [root@localhost ~]# >> >> The initramfs is generated on-the-fly when the kernel is installed. So I >> suspect the bug here is correctly described as 'When installing any >> kernel package after doing the /usr move updates, the generated >> initramfs will not contain /lib/libc.so.6' - i.e. the actual kernel >> package in question doesn't matter, it's rather that any attempt to >> generate an initramfs after doing the /usr move will fail. This is >> obviously a significant problem, if I'm correct. > > Has anyone else who's done the /usr move tried to install a kernel after > the move? If so, does it work, or do you hit the same problem Tom hit? I hope that no one else hits it and that it's just some bad juju on my side but it's happened with two different installs. I've also just duped my VM and run dracut for the bootable kernel - and it's now unbootable. [root@localhost ~]# rpm -q dracut dracut-014-77.git20120126.fc17.1.noarch -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: usrmove problem
On Tue, Jan 31, 2012 at 12:26 PM, Adam Williamson wrote: > On Tue, 2012-01-31 at 10:44 -0500, Tom H wrote: > >> >> Also, the problem is in your initramfs, not the kernel itself. >> >> >> >> Harald? >> > >> > I was about to follow up. I tried rebuilding the rc6 kernel's >> > initramfs but there was no joy. I then managed to boot with the rc6 >> > kernel using the rc4 initramfs. >> > >> > I've unpacked my the rc4 and rc6 initramfs's to take a look but have >> > had to go back to real work... >> >> Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and >> initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6": >> >> [root@localhost ~]# find . -name 'libc.so.6' >> ./rc4/run/initramfs/lib/libc.so.6 >> [root@localhost ~]# > > The initramfs is generated on-the-fly when the kernel is installed. So I > suspect the bug here is correctly described as 'When installing any > kernel package after doing the /usr move updates, the generated > initramfs will not contain /lib/libc.so.6' - i.e. the actual kernel > package in question doesn't matter, it's rather that any attempt to > generate an initramfs after doing the /usr move will fail. This is > obviously a significant problem, if I'm correct. Bug submitted: https://bugzilla.redhat.com/show_bug.cgi?id=786261 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: usrmove problem
On Tue, 2012-01-31 at 09:26 -0800, Adam Williamson wrote: > On Tue, 2012-01-31 at 10:44 -0500, Tom H wrote: > > > >> Also, the problem is in your initramfs, not the kernel itself. > > >> > > >> Harald? > > > > > > I was about to follow up. I tried rebuilding the rc6 kernel's > > > initramfs but there was no joy. I then managed to boot with the rc6 > > > kernel using the rc4 initramfs. > > > > > > I've unpacked my the rc4 and rc6 initramfs's to take a look but have > > > had to go back to real work... > > > > Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and > > initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6": > > > > [root@localhost ~]# find . -name 'libc.so.6' > > ./rc4/run/initramfs/lib/libc.so.6 > > [root@localhost ~]# > > The initramfs is generated on-the-fly when the kernel is installed. So I > suspect the bug here is correctly described as 'When installing any > kernel package after doing the /usr move updates, the generated > initramfs will not contain /lib/libc.so.6' - i.e. the actual kernel > package in question doesn't matter, it's rather that any attempt to > generate an initramfs after doing the /usr move will fail. This is > obviously a significant problem, if I'm correct. Has anyone else who's done the /usr move tried to install a kernel after the move? If so, does it work, or do you hit the same problem Tom hit? -- 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: Fedora 17’s unified filesystem (/usr-move)
On 01/30/2012 10:38 PM, Harald Hoyer wrote: you forgot to convert with dracut before yum upgrade... right?? Yes, my bad. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New criterion for reporting failure of installer and accessing debug mode
On Tue, 2012-01-31 at 11:42 -0500, Chris Lumens wrote: > > "The installer must be able to handle the failure and report the issue. The > > installer must be also able to access debug mode." > > Debug mode is intended to be used by developers to test and fix > anaconda. I don't think this belongs in test criteria. If it's never expected to be used by end users, then yeah, we should leave it out of the criteria and ditch the test or make it non-blocking. -- 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 testcase for installation without selinux
On Tue, 2012-01-31 at 11:43 -0500, Chris Lumens wrote: > > "The installed system must run normally if the user chooses to install > > without SELinux" > > > > There is no test case for this now. > > > > I have one note on this. There is used noselinux option, but it doesn't > > work now. I filled bug [2] there is another option with the same effect - > > selinux=0 and this one works fine, but Anaconda have noselinux in > > documentation, so it should work and they're working on it. > > The option to install without selinux was added at a time when selinux > was a new, experimental feature in Fedora. Now, it's an integral part > of the distribution. It's time for this option to go away. If we don't want to support that, the alternative is to ditch the release criterion. I'm okay with that. -- 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 installation with minimal set of packages
Adam Williamson (awill...@redhat.com) said: > On Tue, 2012-01-31 at 10:52 -0500, Bill Nottingham wrote: > > Petr Schindler (pschi...@redhat.com) said: > > > > Yeah. As far as QA is concerned, the key questions are 'is there a > > > > minimal package set present, does an install with that package set > > > > complete properly, does it boot'. What's *in* it is not really our > > > > concern. > > > > > > So new beta criteria should be: > > > > > > "The installer must be able to complete package installation with a > > > minimal usable set of packages" > > > > > > And what "minimal set" means should be defined somewhere else? And > > as soon as it will be somewhere, we should give the link. > > > > @core > > That's an implementation detail. It's not a capability-driven > description of which packages should actually be in the minimal package > set, as was discussed earlier in the thread. Merely stating that if you're linking to what the minimal set of packages will be, that's it. Bill -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New criterion for installation with minimal set of packages
On Tue, 2012-01-31 at 10:52 -0500, Bill Nottingham wrote: > Petr Schindler (pschi...@redhat.com) said: > > > Yeah. As far as QA is concerned, the key questions are 'is there a > > > minimal package set present, does an install with that package set > > > complete properly, does it boot'. What's *in* it is not really our > > > concern. > > > > So new beta criteria should be: > > > > "The installer must be able to complete package installation with a minimal > > usable set of packages" > > > > And what "minimal set" means should be defined somewhere else? And > as soon as it will be somewhere, we should give the link. > > @core That's an implementation detail. It's not a capability-driven description of which packages should actually be in the minimal package set, as was discussed earlier in the thread. -- 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 installation with minimal set of packages
On Tue, 2012-01-31 at 10:52 -0500, Petr Schindler wrote: > > From: "Adam Williamson" > > To: "For testing and quality assurance of Fedora releases" > > > > Sent: Tuesday, January 31, 2012 4:51:56 AM > > Subject: Re: New criterion for installation with minimal set of packages > > > > On Mon, 2012-01-30 at 21:56 -0500, Jon Stanley wrote: > > > On Mon, Jan 30, 2012 at 8:49 PM, Adam Williamson > > > wrote: > > > > > > > Yeah, this is kind of problematic, because I don't really want > > > > the > > > > release criteria to prescribe exactly what the 'minimal' package > > > > set > > > > should include. Perhaps we should just explicitly refer to 'the > > > > installer's "minimal" package set' or something like that > > > > > > True - come to think of it, I really don't believe that it is QA's > > > domain to define the task list - but it should be somebody's. What > > > I > > > don't want is the feature creep of the "minimal" package set - next > > > thing you know, GNOME will be part of that package set. But I don't > > > think that QA is the appropriate place to address those concerns :) > > > > Yeah. As far as QA is concerned, the key questions are 'is there a > > minimal package set present, does an install with that package set > > complete properly, does it boot'. What's *in* it is not really our > > concern. > > So new beta criteria should be: > > "The installer must be able to complete package installation with a > minimal usable set of packages" > > And what "minimal set" means should be defined somewhere else? And as > soon as it will be somewhere, we should give the link. More or less, yeah. Maybe we should make the criterion: "The installer must offer a 'minimal' installation option, and must be able to complete installation successfully when this option is selected" (note that a later criterion specifies that any install according to earlier criteria should boot, so we don't need to specify that). -- 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 reporting failure of installer and accessing debug mode
> "The installer must be able to handle the failure and report the issue. The > installer must be also able to access debug mode." Debug mode is intended to be used by developers to test and fix anaconda. I don't think this belongs in test criteria. - Chris -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New testcase for installation without selinux
> "The installed system must run normally if the user chooses to install > without SELinux" > > There is no test case for this now. > > I have one note on this. There is used noselinux option, but it doesn't work > now. I filled bug [2] there is another option with the same effect - > selinux=0 and this one works fine, but Anaconda have noselinux in > documentation, so it should work and they're working on it. The option to install without selinux was added at a time when selinux was a new, experimental feature in Fedora. Now, it's an integral part of the distribution. It's time for this option to go away. - Chris -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal for enhancement of criterion
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: Change of release level of Mediakit ISO Size test case
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. -- 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 updates.img using
On Tue, 2012-01-31 at 09:52 -0500, Petr Schindler wrote: > > Similar to previous: > > > > "The installer must be able to retrieve and use an > > [[Anaconda/Updates| > > installer update image]] by any supported method" > > > > Though this may be too broad, and we may have the problem we had with > > kickstarts in F16, where some really obscure retrieval method doesn't > > work and we don't really want to block the release for that. We might > > want to be more specific and only support more common updates.img > > deployment channels. > > Thank you for suggestions on this. I would require only methods for > which we have test case [1] [2] and from alpha [3]. So I propose beta > criterion: > > "The installer must be able to use an [[Anaconda/Updates|installer > update image]] retrieved from removable media, remote installation > source and HTTP url" > > [1] > https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source > [2] > https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media > [3] > https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL I think we do want to require at least URL to work at Alpha. So have a criterion just for URL at Alpha, then a broader criterion at beta or final. -- 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
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. BTW, Petr, can you set your mail client to wrap at 72 characters, as is conventional? Thanks! -- 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: /usr move testing status and F17 Alpha TC1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, On 01/31/2012 06:31 PM, Adam Williamson wrote: > We have Fedora 17 Alpha TC1 scheduled to be composed today. I think > it may be best to go ahead and spin TC1 without the /usr move > changes, so we have - hopefully - a functional baseline for our > initial validation testing. Once the above issues - and any others > that arise - are verified and, if necessary, addressed, we can go > ahead and tag the /usr move changes into Rawhide, and spin a TC2. In the worst case scenario -- what is the contingency plan for those of us who have already performed the /usr move? The contingency plan does not mention any plan for a rollback. http://fedoraproject.org/wiki/Features/UsrMove#Contingency_Plan Of course, at this stage it's not that much of a hardship to reinstall with an Alpha TC and help test that. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPKDQNAAoJEEr1VKujapN6LikIAJZ5es171Fq7Ekt94rqGbAcf tm71aiRsfujH3NgKVm0jeaEUhfC2Lj59c5NYNCTdKXyyj9cBsCNESFMF/mixZ2+a wLF9AU8QpFcMxr1ZoAJhu2HEpvf0bpeeLOPH6mufdEF5FmoCcKebAhrwcSQHHnU6 hThsxPvDbMLoa88ot8AtItRUQL1UaSSP7xDo7dr3nZxkdQdVe7trdmifLZ3Lx6U6 wvOXkeqB10JyVo7YuuNzYqj/mfdE5UoasTjYBYIL2q5Ovlkd4+g/iXrelu+jbM3B 6A+Eg7hfJetyp+DEkTaKvPRCrTc9uxXdha3YL0NBAAepf0WlWScNwnxqd28bSaA= =Mj0U -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
/usr move testing status and F17 Alpha TC1
Hey, folks. Just wanted to keep the lines of communication open about our results testing the /usr move feature. On upgrading existing Rawhide installs: we have multiple reports of people who have been able to do so successfully following the instructions given by Harald in the post 'Fedora 17’s unified filesystem (/usr-move)'. However, we have one report that when a kernel package is installed after the migration, the initramfs that is generated will be missing /lib/libc.so.6, and will fail to boot: https://lists.fedoraproject.org/pipermail/test/2012-January/105317.html Tim Flink has been trying to build a boot.iso using the /usr move packages, to establish whether we can successfully build images with the /usr move stuff and whether they will then boot and work (install a bootable system). He has not yet been able to do so, and there is one issue in particular he suspects is not specific to his compose process or build machine and may affect official image composes if we land the /usr move changes. He's continuing to investigate this and will report his findings once he's more sure of them. Given the above, and noting also the current confusion about whether explicit Provides are needed for things moved from /bin to /usr/bin and whether that's acceptable, I'd suggest it may be premature to land the changes into Rawhide proper at this time. We have Fedora 17 Alpha TC1 scheduled to be composed today. I think it may be best to go ahead and spin TC1 without the /usr move changes, so we have - hopefully - a functional baseline for our initial validation testing. Once the above issues - and any others that arise - are verified and, if necessary, addressed, we can go ahead and tag the /usr move changes into Rawhide, and spin a TC2. -- 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: usrmove problem
On Tue, 2012-01-31 at 10:44 -0500, Tom H wrote: > >> Also, the problem is in your initramfs, not the kernel itself. > >> > >> Harald? > > > > I was about to follow up. I tried rebuilding the rc6 kernel's > > initramfs but there was no joy. I then managed to boot with the rc6 > > kernel using the rc4 initramfs. > > > > I've unpacked my the rc4 and rc6 initramfs's to take a look but have > > had to go back to real work... > > Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and > initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6": > > [root@localhost ~]# find . -name 'libc.so.6' > ./rc4/run/initramfs/lib/libc.so.6 > [root@localhost ~]# The initramfs is generated on-the-fly when the kernel is installed. So I suspect the bug here is correctly described as 'When installing any kernel package after doing the /usr move updates, the generated initramfs will not contain /lib/libc.so.6' - i.e. the actual kernel package in question doesn't matter, it's rather that any attempt to generate an initramfs after doing the /usr move will fail. This is obviously a significant problem, if I'm correct. -- 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 installation with minimal set of packages
Petr Schindler (pschi...@redhat.com) said: > > Yeah. As far as QA is concerned, the key questions are 'is there a > > minimal package set present, does an install with that package set > > complete properly, does it boot'. What's *in* it is not really our > > concern. > > So new beta criteria should be: > > "The installer must be able to complete package installation with a minimal > usable set of packages" > > And what "minimal set" means should be defined somewhere else? And as soon as > it will be somewhere, we should give the link. @core Bill -- 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
> From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 1:52:49 AM > Subject: Re: Change of release level of Mediakit ISO Size test case > > On Mon, 2012-01-30 at 20:40 +, Andre Robatino wrote: > > Petr Schindler redhat.com> writes: > > > > > > > > Test case [1] is marked as alpha release level in [2]. I propose > > > to change it > > to beta. We have beta criterion > > > "The network installation image, DVD image, and live images for > > release-blocking desktops must meet > > > current size requirements" for this. > > > > > > [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size > > > [2] > > > https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test > > > > I'd prefer that this test be left at alpha level, since if it > > fails, then anyone > > who needs to use the corresponding media is blocked from any other > > testing as > > well. There's also the issue that having to reduce the size of the > > image at a > > later point runs the risk of causing further problems in deciding > > what to cut. > > If some media are considered less important than others, maybe > > there could be > > separate size tests for the different media. > > 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. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New criterion for installation with minimal set of packages
> From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 4:51:56 AM > Subject: Re: New criterion for installation with minimal set of packages > > On Mon, 2012-01-30 at 21:56 -0500, Jon Stanley wrote: > > On Mon, Jan 30, 2012 at 8:49 PM, Adam Williamson > > wrote: > > > > > Yeah, this is kind of problematic, because I don't really want > > > the > > > release criteria to prescribe exactly what the 'minimal' package > > > set > > > should include. Perhaps we should just explicitly refer to 'the > > > installer's "minimal" package set' or something like that > > > > True - come to think of it, I really don't believe that it is QA's > > domain to define the task list - but it should be somebody's. What > > I > > don't want is the feature creep of the "minimal" package set - next > > thing you know, GNOME will be part of that package set. But I don't > > think that QA is the appropriate place to address those concerns :) > > Yeah. As far as QA is concerned, the key questions are 'is there a > minimal package set present, does an install with that package set > complete properly, does it boot'. What's *in* it is not really our > concern. So new beta criteria should be: "The installer must be able to complete package installation with a minimal usable set of packages" And what "minimal set" means should be defined somewhere else? And as soon as it will be somewhere, we should give the link. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: usrmove problem
On Tue, Jan 31, 2012 at 8:30 AM, Tom H wrote: > On Tue, Jan 31, 2012 at 7:42 AM, Josh Boyer wrote: >> On Tue, Jan 31, 2012 at 3:47 AM, Tom H wrote: >>> >>> I noticed late Sunday night that I was booting after the usrmove >>> procedure from a pre-usrmove kernel. When I tried to boot from a >>> kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17), >>> I got: >>> >>> "/bin/sh: error while loading shared libraries: libc.so.6: cannot open >>> shared object file: No such file or directory >>> Kernel panic - not syncing: Attempted to kill init!" >>> >>> So I rebuilt another Rawhide VM and went through the same procedure >>> but I'm having the same problem. >>> >>> I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in >>> pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail >>> at the same point. >>> >>> Has anyone been able to boot from a kernel installed from the >>> f17-usrmove repository? > > >> Those kernels are just inherited from rawhide. There isn't a specially >> built kernel in the f17-usrmove repo that I'm aware of. > > Thanks (although I thought that I'd seen an email here about a patch > to the usrmove kernels). > > >> Also, the problem is in your initramfs, not the kernel itself. >> >> Harald? > > I was about to follow up. I tried rebuilding the rc6 kernel's > initramfs but there was no joy. I then managed to boot with the rc6 > kernel using the rc4 initramfs. > > I've unpacked my the rc4 and rc6 initramfs's to take a look but have > had to go back to real work... Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6": [root@localhost ~]# find . -name 'libc.so.6' ./rc4/run/initramfs/lib/libc.so.6 [root@localhost ~]# -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New criterion for updates.img using
> From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 1:42:30 AM > Subject: Re: New criterion for updates.img using > > On Mon, 2012-01-30 at 11:28 -0500, Petr Schindler wrote: > > I propose new beta criterion: > > > > "The installer must be able to use updates.img obtained by any > > supported way" > > > > I think, that this should be at criteria too. There are test cases > > which uses this feature - [1], [2] > > > > [1] > > https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source > > [2] > > https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media > > Similar to previous: > > "The installer must be able to retrieve and use an > [[Anaconda/Updates| > installer update image]] by any supported method" > > Though this may be too broad, and we may have the problem we had with > kickstarts in F16, where some really obscure retrieval method doesn't > work and we don't really want to block the release for that. We might > want to be more specific and only support more common updates.img > deployment channels. Thank you for suggestions on this. I would require only methods for which we have test case [1] [2] and from alpha [3]. So I propose beta criterion: "The installer must be able to use an [[Anaconda/Updates|installer update image]] retrieved from removable media, remote installation source and HTTP url" [1] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source [2] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media [3] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: usrmove problem
On Tue, Jan 31, 2012 at 7:42 AM, Josh Boyer wrote: > On Tue, Jan 31, 2012 at 3:47 AM, Tom H wrote: >> >> I noticed late Sunday night that I was booting after the usrmove >> procedure from a pre-usrmove kernel. When I tried to boot from a >> kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17), >> I got: >> >> "/bin/sh: error while loading shared libraries: libc.so.6: cannot open >> shared object file: No such file or directory >> Kernel panic - not syncing: Attempted to kill init!" >> >> So I rebuilt another Rawhide VM and went through the same procedure >> but I'm having the same problem. >> >> I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in >> pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail >> at the same point. >> >> Has anyone been able to boot from a kernel installed from the >> f17-usrmove repository? > Those kernels are just inherited from rawhide. There isn't a specially > built kernel in the f17-usrmove repo that I'm aware of. Thanks (although I thought that I'd seen an email here about a patch to the usrmove kernels). > Also, the problem is in your initramfs, not the kernel itself. > > Harald? I was about to follow up. I tried rebuilding the rc6 kernel's initramfs but there was no joy. I then managed to boot with the rc6 kernel using the rc4 initramfs. I've unpacked my the rc4 and rc6 initramfs's to take a look but have had to go back to real work... -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New criterion for Checksum
> From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 1:51:16 AM > Subject: Re: New criterion for Checksum > > On Mon, 2012-01-30 at 18:02 +, Andre Robatino wrote: > > Petr Schindler redhat.com> writes: > > > > > I propose new final criterion: > > > > > > "There must be published correct checksum for each ISO media. > > > Also if there is > > embedded checksum on ISO > > > media, it must be correct." > > > > > > I think we should check this. We have already test case [1]. I > > > propose to > > change release level for this test > > > case to final. > > > > > > [1] > > > https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums > > > > I think that having a published correct checksum for each ISO > > should be Alpha > > level. If the ISO can't be verified, then the results of any other > > testing on it > > are suspect. Also, publishing the correct checksums can be done > > without altering > > the ISOs themselves, so it's easy to ensure that this test passes. > > Getting the > > embedded checksum correct is less important since an independent > > check is > > possible. > > Yeah, I did think that too. It seems like the kind of thing that > should > always be correct. 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. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: usrmove problem
On Tue, Jan 31, 2012 at 3:47 AM, Tom H wrote: > I noticed late Sunday night that I was booting after the usrmove > procedure from a pre-usrmove kernel. When I tried to boot from a > kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17), > I got: > > "/bin/sh: error while loading shared libraries: libc.so.6: cannot open > shared object file: No such file or directory > Kernel panic - not syncing: Attempted to kill init!" > > So I rebuilt another Rawhide VM and went through the same procedure > but I'm having the same problem. > > I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in > pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail > at the same point. > > Has anyone been able to boot from a kernel installed from the > f17-usrmove repository? Those kernels are just inherited from rawhide. There isn't a specially built kernel in the f17-usrmove repo that I'm aware of. Also, the problem is in your initramfs, not the kernel itself. Harald? josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New test case for testing if services start properly
> From: "Adam Williamson"
> To: "For testing and quality assurance of Fedora releases"
>
> Sent: Tuesday, January 31, 2012 1:50:46 AM
> Subject: Re: New test case for testing if services start properly
>
> On Mon, 2012-01-30 at 11:37 -0500, Petr Schindler wrote:
> > I propose new test cases [1]. This test case is related to final
> > criterion:
> >
> > "All services in a default install must start properly"
> >
> > We don't have test case for this right now.
> >
> > [1]
> > https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Services_start
>
> I think the instructions are possibly a tad too tool-specific.
> Instead
> of explicitly referring to alt-f2 and gnome-terminal, it may be more
> future-proof to simply say:
>
> 'In a console, run the command {{command|systemctl --all --failed}}'
>
> You can also drop the comma from "This test case tests, whether all
> services start properly in a default install." It's not needed.
It's amended. Thanks for suggestion.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal for enhancement of criterion
> From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 1:47:55 AM > Subject: Re: Proposal for enhancement of criterion > > On Mon, 2012-01-30 at 11:35 -0500, Petr Schindler wrote: > > I propose to enhance alpha criterion > > > > "The installer must be able to report failures to Bugzilla, with > > appropriate information included" > > to > > "The installer must be able to report failures to Bugzilla, remote > > system and local disk, with appopriate information included" > > > > 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New criterion for reporting failure of installer and accessing debug mode
> From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 1:46:45 AM > Subject: Re: New criterion for reporting failure of installer and accessing > debug mode > > On Mon, 2012-01-30 at 11:29 -0500, Petr Schindler wrote: > > I propose final criterion: > > > > "The installer must be able to handle the failure and report the > > issue. The installer must be also able to access debug mode." > > > > We have test case for this - [1]. It's useful to have this feature. > > > > [1] > > https://fedoraproject.org/wiki/QA:Testcase_Anaconda_traceback_debug_mode > > Well, we already have a criterion for 'reporting a failure to > Bugzilla'. > We also have some more test cases without matching criteria - > "QA:Testcase Anaconda save traceback to remote system" and > "QA:Testcase_Anaconda_save_traceback_to_disk". Perhaps we need a more > comprehensive approach here. > > The existing criterion at Alpha is: > > "The installer must be able to report failures to Bugzilla, with > appropriate information included" > > So following that model, we could have: > > "The installer must be able to enter debugging mode on encountering a > failure" I agree, this is more logical approach then mine. So I propose new final criterion: "The installer must be able to enter debugging mode on encountering a failure" > at Final. Not sure if we want to also add criteria for remote system > and > disk, or if we want to downgrade those to non-blocking tests, but > right > now they're marked as Alpha, so we should do something. This is discussed in another thread. So I will comment there. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New criterion for Memory test
> From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 1:36:38 AM > Subject: Re: New criterion for Memory test > > On Mon, 2012-01-30 at 11:23 -0500, Petr Schindler wrote: > > I propose new final criterion: > > > > "The installer must be able to run memory test." > > > > This feature is very useful and should work. We have test case for > > this yet [1]. I'd move it to final release level. > > > > [1] https://fedoraproject.org/wiki/QA:Testcase_Memtest86 > > Well, it's not actually the installer. memtestx86 is a completely > standalone thing which we just put on the images, with a boot menu > option: if you pick it, nothing Fedora-ish at all actually runs. > > Perhaps: > > "All release media must include a standalone memory test utility. A > boot > menu option to launch this utility must be present and must work > correctly." I agree with that, my fault. So I propose new final criterion: "All release media must include a standalone memory test utility. A boot menu option to launch this utility must be present and must work correctly." Thanks Adam for your feedback. Petr Schindler -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Installation from USB-written images (5/5): DVD.iso + Livecd-iso-to-disk
Hi, thank you for the suggestions, as with the live.iso testcases, I'll just continue in this particular thread, since both DVD testcases are 'the same'. I've updated the testcases [1][2], so they contain the standard 'proceed with installation' steps, and the final 'boots without usb stick plugged in'. The testcase(s) now look like this: --- How to test Insert the USB stick containing DVD.iso, and boot the installer Proceed through install process selecting a set of packages Remove the USB stick before rebooting into installed system when instructed by installer. Check that the computer boots to the installed system, with the USB stick unplugged Expected Results Graphical boot menu is displayed for users to select install options. Navigating the menu and selecting entries must work. If no option is selected, the installer should load after a reasonable timeout Installer boots into loader and prompts for language, keymap Installer transitions to anaconda without error The installer should not require you to configure a package repository, it should be able to install using the packages present on the USB stick. Anaconda functions properly and successfully installs required packages Package errors should not occur The installed system boots successfully. --- j. [1] https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_DVD_litd [2] https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_DVD_dd - Original Message - > From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 1:26:50 AM > Subject: Re: Installation from USB-written images (5/5): DVD.iso + > Livecd-iso-to-disk > > On Mon, 2012-01-30 at 08:17 -0500, Josef Skladanka wrote: > > This testcase [1] should ensure, that if the user uses USB stick > > and transfers the DVD.iso to it using Livecd-iso-to-disk, the > > installation can be successfully finished. > > Installer should be able to use the DVD local package source > > options, but this is caused by the way LITD writes the image to > > the USB stick. > > > > I propose this as a Alpha verification testcase. > > > > --- > > > > = Description = > > > > This test verifies that Fedora DVD Image can be booted & installed > > from USB stick > > > > There are more methods to create the DVD.iso USB stick, this test > > covers Livecd-iso-to-disk. > > > > == Setup == > > > > * Prepare the DVD ISO image and USB stick. > > * Copy the DVD.iso to the USB stick using Livecd-iso-to-disk. [3] > > > > == How to test == > > > > * Insert the USB stick containing DVD.iso, and boot the system > > under test > > * Proceed with the installation the usual way. > > > > == Expected Results == > > > > * Graphical boot menu is displayed for users to select install > > options. Navigating the menu and selecting entries must work. If > > no option is selected, the installer should load after a > > reasonable timeout > > * Installer boots into loader and prompts for language, keymap > > * Installer transitions to anaconda without error > > * Installer should be able to use the DVD local package source > > options > > We could make this a bit clearer - something like 'the installer > should > not require you to configure a package repository, it should be able > to > install using the packages present on the USB stick'. > > > * ??? Installer does not offer the USB stick as a target for > > bootloader and/or partitioning > > We could probably add bits to the 'how to test' section for this, > something like. For instance, ask the user to boot the installed > system > without the USB stick plugged in, to ensure the bootloader was > installed > to the hard disk, not the USB stick. > -- > 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 mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Installation from USB-written images (1/5): Live.iso + dd
Thanks, Adam, as these are all 'the same', I'll just continue in this particular thread. I've updated the testcases [1][2][3], to cover the installation procedure. The testcase(s) now look like this: --- How to test Insert the USB stick containing Live.iso, and boot the system under test At the boot prompt, interrupt the automatic boot sequence by pressing any key. Then select the menu option Boot. From live image desktop, or from the Application menu, click the icon Install to hard drive Complete the installation as desired Reboot the system and remove the Live boot media Expected Results A graphical boot menu is displayed and the graphics look reasonably good. While hi-res images aren't supported in the boot menu, the graphics should not look extremely pixelated. Upon selecting Boot, the Live image boots successfully. The installer starts without error The installer completes without error The system reboots successfully --- [1] https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_Live_dd [2] https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_Live_lcdt [3] https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_Live_litd - Original Message - > From: "Adam Williamson" > To: "For testing and quality assurance of Fedora releases" > > Sent: Tuesday, January 31, 2012 1:23:46 AM > Subject: Re: Installation from USB-written images (1/5): Live.iso + dd > > On Mon, 2012-01-30 at 07:58 -0500, Josef Skladanka wrote: > > This testcase [1] should ensure, that if the user uses dd to > > transfer the Fedora Live.iso to USB stick, the boot process works > > 'as expected'. > > > > I propose this as a Alpha verification testcase. > > > > --- > > > > = Description = > > > > This test verifies that Fedora Live Image can be booted from USB > > stick. > > > > There are more methods to create the Live USB stick, this test > > covers dd. > > > > == Setup == > > > > * Prepare the Live ISO image and USB stick. > > * Copy the Live.iso to the USB stick using dd [1] > > > > == How to test == > > > > * Insert the USB stick containing Live.iso, and boot the system > > under test > > * At the boot prompt, interrupt the automatic boot sequence by > > pressing any key. Then select the menu option Boot. > > > > == Expected Results == > > > > * A graphical boot menu is displayed and the graphics look > > reasonably good. While hi-res images aren't supported in the boot > > menu, the graphics should not look extremely pixelated. > > * Upon selecting Boot, the Live image boots successfully. > > > > --- > > > > > > > > [1] > > https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_Live_dd > > Thanks for your work on this! > > For the three test cases that cover writing live images to USB, > including this one, we want to test not just that the image *boots*, > but > that an installation can be successfully performed using the stick. > Could you extend the test cases to cover 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
usrmove problem
I noticed late Sunday night that I was booting after the usrmove procedure from a pre-usrmove kernel. When I tried to boot from a kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17), I got: "/bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Kernel panic - not syncing: Attempted to kill init!" So I rebuilt another Rawhide VM and went through the same procedure but I'm having the same problem. I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail at the same point. Has anyone been able to boot from a kernel installed from the f17-usrmove repository? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
