test January 2012

test@lists.fedoraproject.org

50 participants
207 discussions

New criterion for Memory test
by Petr Schindler 16 Feb '12

16 Feb '12

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

2 3

Change of release level of Kickstart Http Server test case
by Petr Schindler 16 Feb '12

16 Feb '12

Test case [1] is associated with alpha release level in [2]. I propose to change it to beta level, where is criterion: "The installer must be able to use all kickstart delivery methods." [1] https://fedoraproject.org/wiki/QA:Testcase_Kickstart_Http_Server_Ks_Cfg [2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

2 2

F16 Alpha GRUB install failure
by Michael Schwendt 13 Feb '12

13 Feb '12

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?

6 14

Proposal for removing Boot method efidisk test case
by Petr Schindler 13 Feb '12

13 Feb '12

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

2 2

Proposal for enhancement of criterion
by Petr Schindler 13 Feb '12

13 Feb '12

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_bugzi… [2] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_disk [3] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remot…

2 4

Change of release level of Mediakit ISO Size test case
by Petr Schindler 13 Feb '12

13 Feb '12

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

4 8

Installation from USB-written images (5/5): DVD.iso + Livecd-iso-to-disk
by Josef Skladanka 02 Feb '12

02 Feb '12

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 * ??? Installer does not offer the USB stick as a target for bootloader and/or partitioning --------------------------- [1] https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_DV… [2] https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria [3] http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Run_livecd-iso…

3 4

Fedora 17’s unified filesystem (/usr-move)
by Harald Hoyer 01 Feb '12

01 Feb '12

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 Some reasoning behind this change is outlined here: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge The official Fedora 17 feature page is here: https://fedoraproject.org/wiki/Features/UsrMove The needed changes to implement the unified filesystem are about to land in rawhide soon. New installations of rawhide/Fedora 17 will install the symlinks right away, and no special care needs to be taken Currently installed systems need some manual steps to convert the current system to match the layout of rawhide/Fedora 17. After that, the system can continue to be updated with YUM as usual. Some RPM packages in rawhide/Fedora 17 will carry a RPM dependency guard, which will make sure, they can only be installed when /bin, /sbin, /lib, /lib64 are symlinks and not directories like in Fedora 16 and older. The installed system’s base filesystem layout can not be safely altered, while the system itself is running on top of it. Dracut, the initramfs used to find and mount the root filesystem, can be instructed to convert the filesystem to match rawhide/Fedora 17’s expectations. A screenshot of a successful conversion process is here: http://people.freedesktop.org/~kay/usrmove-convert-log.png The packages, which are about to land in rawhide, are at this moment available via the ‘f17-usrmove’ koji tag. They are ready for testing now. Any tests, preferably in virtual machines or snapshots, where failures are acceptable, are more than welcome, and any feedback is greatly appreciated. Keep in mind, that this still needs wider testing and a possible bug in the conversion logic might break an installed system. Please be careful with your data, do not try this on a production system, and always have a backup of your data. If your system has a split-off /usr, a separate mount point, the dracut /usr mount conversion logic for /usr on NFS is not yet supported; we are working on it. /usr on iSCSI, FCoE, NBD although is supported, as long as “netroot=...” is specified on the kernel command line for these disks (see man dracut.kernel(7)). Please report any issues regarding the /usr-move test (not general rawhide bugs) by replying to this email, by sending an email to the fedora-test list <test(a)lists.fedoraproject.org>, or by grabbing ‘haraldh’ or ‘kay’ on IRC #fedora-devel on freenode, or contact us by email directly. The final guard in RPM is not yet enabled in the ‘f17-usrmove’ koji tag version of the packages. Make sure you never install any of the packages below this tag on an unconverted system, it will not be able to bootup. Before the packages hit rawhide, the guard will be enabled and safely prevent these packages to be installed on unconverted systems. At the moment, we are still waiting for an updated RPM in the koji buildsystem, which provides the runtime check for the filesystem guard. After this is resolved by Fedora Release Engineering, we can go ahead and enable the needed guard and move the packages from the ‘f17-usrmove’ koji tag to ‘rawhide’: https://fedorahosted.org/rel-eng/ticket/5034 This is the screen log of a full conversion and update process: http://people.freedesktop.org/~kay/usrmove-convert-log.txt Here are the steps to prepare your system, to convert it, and to be able to continue updating your installed system with YUM: Download and install the most recent dracut package from rawhide: # yum --enablerepo=rawhide update dracut Update the installed initramfs image for your current kernel, and instruct dracut to include the dracut module to convert your current filesystem: # dracut --force --add usrmove If dracut detects ‘rd.usrmove’ on the kernel command line at bootup, it starts the filesystem conversion of the root filesystem. Change the following kernel commandline parameter directly in the bootloader menu, which is shown during bootup, or edit the line in /etc/grub*.cfg. - remove “ro” - append “rw” to let dracut mount your root filesystem writeable - remove “rhgb” to hide the graphical bootsplash - append “rd.info” to get a more verbose output from dracut - append “rd.usrmove” to enable the /usr-move conversion script in dracut - append “selinux=0” for now, because the relabeling in a converted F16 system does not seem to work properly at this moment During bootup, dracut will now convert your filesystem, and /lib, /lib64, /bin and /sbin should then all be symbolic links to the corresponding directories in /usr. After the conversion, the system needs to be immediately updated to rawhide. No packages from F16 or F15, or older rawhide packages must be installed anymore. Make sure to disable any F15 and F16 repositories in yum! Any files with conflicting names, which the conversion could not resolve, will be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64, /usr/bin and /usr/sbin. The log messages, which dracut has generated during bootup, can be retrieved with: # dmesg | grep dracut After a successful conversion, revert the changes made to the kernel command line in the bootloader config file /etc/grub*.cfg. SELinux relabelling should take effect after you rebooted your updated system and can take a long time (at least in a VM it takes insanely long and is still not finished). We are currently investigating, what seem to take so long, so you might consider to test with SELinux disabled for now. Until the rawhide repository gets all the converted rpms, use the f17-usrmove repository to update the system after the filesystem conversion and disable rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo [f17-usrmove] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch enabled=1 metadata_expire=1d gpgcheck=0 # yum clean all # yum upgrade After upgrading, all should be set and done. Have fun with your system and say “Good bye” to /bin, /sbin, /lib, /lib64 and meet them in /usr. :-)

11 20

usrmove problem
by Tom H 01 Feb '12

01 Feb '12

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?

4 10

New criterion for installation with minimal set of packages
by Petr Schindler 31 Jan '12

31 Jan '12

I propose new beta criterion: "The installer must be able to install system with minimal usable set of packages." There is test case [1] associated with alpha, I'd change it to beta release level. [1] https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Ins…

4 11

← Newer
1
2
3
4
5
6
7
8
9
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test January 2012