Testcases for no-DHCP and IPv6
Hi, In testing Fedora from my experience, the idea emerges, that most development and testing is done in a network environment with an IPv4 DHCP server running. Testing in a network environment without DHCP and/or IPv6 only makes bugs come up, that are not found so easily when testing in the current testmatrix. Wouldn't it be a good idea to setup testcases that address DHCP-less network environment and IPv6-only network environment. DHCP-less network might be considered non-evident. But as Fedora can be used as DHCP-server, installing a Fedora DHCP-server, by definition I would say, is a case where a sysadmin is confronted with this situation. IPv6 on the other end is the technology of the future. And as Fedora positions itself as 'cutting edge technology', I would consider the need for IPv6 testcases evident. Koos. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Let's stop using wiki for test results
Hi, Tomorrow (sunday) there's an SSD cache Test day. I do like not using the wiki for testresults, but is this tool online available to be used for tomorrow's test day? Rolf On 10/11/2013 06:53 PM, Jóhann B. Guðmundsson wrote: On 10/11/2013 04:47 PM, Adam Williamson wrote: Well, 'we' didn't, really. Josef just thought it would be a useful thing to have, so he wrote it, and someone running a test day wound up using it. There was no strategic meeting or grand conspiracy or plan or something. This is how stuff happens in tech, usually: stuff gets done because people just...do it. Not really but OK Now we have seen test days where we used the wiki to track results and test days where we used josef's little tool to track results, and people seem to like the tool, so maybe now we'll make it more clear to people running test days that they have the option of using the tool to track the results. That's really the sum total of what's going on. Anything beats the wiki really so if it's in ready enough shape we should just move to that one instead. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Thu, 2013-10-10 at 11:34 +0200, Adam Williamson wrote: On Wed, 2013-10-09 at 09:47 -0500, Mike Chambers wrote: Did a test install of F20 64bit on my normal workstation/desktop. Problem seems to be that after I setup nfs to mount, it won't do it automatically on boot. And this usually works just fine out of the box up to F19. I have to mount the directory manually once the system is booted. Is there a particular nfs service that isn't starting/working that would do this for me or something else? Check 'remote-fs.target': this is the systemd target that controls mounting anything considered a 'remote' filesystem, similar to the old 'netfs' service. Looked and it is there, but not sure what to look for besides being there. Any particular info that should be there? Or can someone take a look after a fresh install that might know the program better to see if it's missing something? [mike@scrappy ~]$ more /lib/systemd/system/remote-fs.target # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Remote File Systems Documentation=man:systemd.special(7) After=remote-fs-pre.target DefaultDependencies=no Conflicts=shutdown.target [Install] WantedBy=multi-user.target -- Mike Chambers Madisonville, KY Best little town on Earth! -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Sunday 13th of October: SSD cache test day
On 10/12/2013 10:58 PM, Reartes Guillermo wrote: Maybe that can be enhanced to say cset.uuid instead of just uuid / set uuid? (for which i confused it with dev.uuid shown by blkid, since i never used bcache before). cset.uuid can be obtained from the output of bcache-show-super. Cheers. Thanks, I updated the text! Rolf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Sat, Oct 12, 2013 at 8:05 AM, Mike Chambers m...@mtchambers.com wrote: On Thu, 2013-10-10 at 11:34 +0200, Adam Williamson wrote: Check 'remote-fs.target': this is the systemd target that controls mounting anything considered a 'remote' filesystem, similar to the old 'netfs' service. Looked and it is there, but not sure what to look for besides being there. Any particular info that should be there? Or can someone take a look after a fresh install that might know the program better to see if it's missing something? Actually, you need to check the status of the mount unit itself. (Which is required by remote-fs.target.) They're named by switching out slashes for for dashes in the mount point. For instance, if you have a nfs share mounted on /mnt/foo, it's mount unit is named mnt-foo.mount and you can find out what's going on with it by running `systemctl status mnt-foo.mount`. You can run just plain `systemctl` for a list of units if you need to. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F20 display problems
Hi, I installed F20 which is running fine in general. But there is one topic, I don't understand if and where there is a problem. I'm using a laptop. - Booting and using mobile on battery is fine. - Booting at home (power) is fine. - Booting if office (docking station, power, external display) is messed up. Office: - system lid closed: grub shows up on external display, after that nothing happens. Internal and external display are black. No plymouth, no gdm, ... remote login via ssh works - system lod open: grub shows up on internal display, everything works. If I disable the GNOMEs user-autologin and clode the lid I would expect the system to boot up and show up on the external display, this does not happen. Autologin seems only to work, when LID is open. Logging in via ssh and trying to figure out, what is happening seems to be x.org does not bring up any errors and seems to get the correct external display and resolutions: [ 8.590] (II) intel(0): EDID vendor DEL, prod id 41047 [ 8.590] (II) intel(0): Using hsync ranges from config file [ 8.590] (II) intel(0): Using vrefresh ranges from config file [ 8.590] (II) intel(0): Printing DDC gathered Modelines: [ 8.590] (II) intel(0): Modeline 2560x1440x0.0 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync (88.8 kHz eP) [ 8.590] (II) intel(0): Modeline 1920x1080x0.0 148.50 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync (67.5 kHz e) [ 8.590] (II) intel(0): Modeline 1920x1080ix0.0 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e) [ 8.590] (II) intel(0): Modeline 1280x720x0.0 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz e) [ 8.590] (II) intel(0): Modeline 720x480x0.0 27.00 720 736 798 858 480 489 495 525 -hsync -vsync (31.5 kHz e) [ 8.590] (II) intel(0): Modeline 800x600x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 8.590] (II) intel(0): Modeline 640x480x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 8.590] (II) intel(0): Modeline 640x480x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 8.590] (II) intel(0): Modeline 720x400x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 8.590] (II) intel(0): Modeline 1280x1024x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 8.590] (II) intel(0): Modeline 1024x768x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 8.590] (II) intel(0): Modeline 1024x768x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 8.590] (II) intel(0): Modeline 800x600x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 8.590] (II) intel(0): Modeline 1280x800x0.0 83.50 1280 1352 1480 1680 800 803 809 831 -hsync +vsync (49.7 kHz e) [ 8.590] (II) intel(0): Modeline 1680x1050x0.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) [ 8.590] (II) intel(0): Modeline 1920x1200x0.0 193.25 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync (74.6 kHz e) [ 8.590] (II) intel(0): Modeline 1152x864x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) [ 8.590] (II) intel(0): Modeline 1600x1200x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) [ 8.590] (II) intel(0): Modeline 1280x1024x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 8.590] (II) intel(0): Modeline 720x576x0.0 27.00 720 732 796 864 576 581 586 625 -hsync -vsync (31.2 kHz e) [ 8.590] (II) intel(0): Modeline 1440x480ix0.0 27.00 1440 1478 1602 1716 480 488 494 525 interlace -hsync -vsync (15.7 kHz e) [ 8.590] (II) intel(0): Modeline 1440x240x0.0 27.00 1440 1478 1602 1716 240 244 247 262 -hsync -vsync (15.7 kHz e) [ 8.590] (II) intel(0): Modeline 1440x288x0.0 27.00 1440 1464 1590 1728 288 290 293 312 -hsync -vsync (15.6 kHz e) [ 8.590] (II) intel(0): Modeline 1280x720x0.0 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync (37.5 kHz e) [ 8.590] (II) intel(0): Modeline 1440x576ix0.0 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync (15.6 kHz e) [ 8.590] (II) intel(0): Modeline 1920x1080ix0.0 74.25 1920 2448 2492 2640 1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e) [ 8.590] (II) intel(0): Modeline 1920x1080x0.0 74.25 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync (27.0 kHz e) [ 8.590] (II) intel(0): Modeline 1920x1080x0.0 74.25 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync (28.1 kHz e) (END) I found this in /var/log/messages, not sure if this is related: Oct 13 07:08:25 localhost kernel: [ 316.087969] [ cut here ] Oct 13 07:08:25 localhost kernel: [ 316.088034] WARNING: CPU: 0 PID: 594 at
Re: [Test-Announce] Fedora 20 Beta Test Compose 1 (TC1) Available Now!
Possibly I described my problem with the LXDE Live CD unclearly or not correctly.I didn't install F20, I only run F20 via Live CD, just for fun, only to see what is Fedora 20, and doing this the system time is permanently set to UTC (as Adam said). In this case, in my opinion independent from Anaconda or Windows philosophy, the system time should not be changed (only by a try out of F20). I think on users, who want only to try out Fedora 20, to decide is it fine or not. Bug 1018162. -Ursprüngliche Mitteilung- Von: Adam Williamson awill...@redhat.com An: For testing and quality assurance of Fedora releases test@lists.fedoraproject.org Verschickt: Sa, 12 Okt 2013 5:06 pm Betreff: Re: [Test-Announce] Fedora 20 Beta Test Compose 1 (TC1) Available Now! On Fri, 2013-10-11 at 03:46 -0400, Joerg Lechner wrote: Hi, several times I started Fedora 20 with Fedora-Live-LXDE-i686-20-Beta-TC2.iso via CD. When I later on start Windows XP the time displayed by Windows is changed by approximately 2 hours. Is this already known or is it worthwhile to write a bug? Kind Regards This is usually the result of Linux and Windows having different opinions about whether the system clock should be set to UTC or local time. I believe the installer is currently intended to guess the system clock should be set to local time if Windows is installed, or UTC if it is not. If you have Windows installed but system clock set to UTC, it will break, that's kinda expected. If you have Windows installed and system clock set to local time and it's still going wrong, I think you should file a bug against anaconda. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net 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
