Re: Upgrading from F30 to F31 beta reboot issue

2019-10-07 Thread alan 


> On 10/7/19 12:33 PM, a...@clueserver.org wrote:
>> If you use --allowerasing, the upgrade transaction works, but since
>> that
>> flag does not get passed to the upgrade after the reboot, the process
>> fails because it tries to upgrade those packages and they were never
>> downloaded.
>
> That is certainly not true, because I have had to use that on most
> upgrades.  The problem is somewhere else and it's hard to tell why dnf
> is coming up with a different transaction on the reboot phase.  I wonder
> if a temporary workaround would be for you to manually download those
> missing packages and put them in the sysupgrade directory before
> rebooting.

As have I. Something has changed in how this gets resolved. Hopefully it
will get identified before the non-beta version gets released.

Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Upgrading from F30 to F31 beta reboot issue

2019-10-07 Thread alan 


> On 10/7/19 10:51 AM, Alan wrote:
>> On Sat, 2019-10-05 at 13:37 +, Rodger Etz wrote:
>>> Thanks, Chris! I did so, but reboot did not create a debugdata dir.
>>> Therefore I have uploaded the dnf logs.
>>>
>>>  From what I have seen so far, it still seems the best option to
>>> modify system-upgrade so it safes the transaction before reboot and
>>> reboot reruns it ... or something similar.
>>>
>>> Trying to figure out what obscure dependency constellation this is
>>> causing, will be painful and most likely fail, because we do not have
>>> enough information and the state of dependencies changes so quickly,
>>> the issue might not occur after the next update of those packages.
>>> And even if we find this particular one, it might be there are others
>>> as well.
>>
>> This is what I get if I don't use the --allowdelete option. The "does
>> not belong to a distupgrade repository" is the part that concerns me.
>
> I assume you mean --allowerasing?  Why don't you want to use that?

Yes. (My sinus headache is not helping.) Because it causes the upgrade to
fail after the reboot.

> The libgit2 module problem is a known issue that is currently being
> hotly discussed.  The "does not belong to a distupgrade repository"
> message is bit confusing.  Usually what it seems to mean is that some
> package that is getting upgraded was a dependency for something that
> isn't.  The original version which is still required is not available in
> any of the repos being used for the upgrade.  It would be a lot more
> helpful if dnf would provide some more useful information, like which
> package is getting upgraded to cause the problem.  Maybe that info is
> further up in the list of packages getting upgraded?
>
>> Error:
>>   Problem 1: package gnome-shell-extension-fedmsg-0.1.9-19.fc29.noarch
>> requires fedmsg-notify, but none of the providers can be installed
>>- fedmsg-notify-0.5.9-1.fc29.noarch does not belong to a distupgrade
>> repository
>
> I don't know what's happening here.  Neither one is getting upgraded
> because they are both retired.  Maybe it's a python 2 thing.
>
>>   Problem 2: package plasma-discover-snap-5.15.5-1.fc30.x86_64 requires
>> plasma-discover = 5.15.5-1.fc30, but none of the providers can be
>> installed
>>- plasma-discover-5.15.5-1.fc30.x86_64 does not belong to a
>> distupgrade repository
>
> Not sure here either, although there appears to have been a build
> problem.  A build of an older version was done after a newer one, so
> something could be confused.
>
>>   Problem 3: problem with installed package kf5-ktexteditor-5.59.0-
>> 1.fc30.x86_64
>>- package kf5-ktexteditor-5.61.0-1.fc31.x86_64 requires
>> libgit2.so.28()(64bit), but none of the providers can be installed
>>- kf5-ktexteditor-5.59.0-1.fc30.x86_64 does not belong to a
>> distupgrade repository
>>- package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is
>> excluded
>>- package libgit2-0.28.3-1.fc31.x86_64 is excluded
>
> This is the libgit2 issue.  It can't upgrade libgit2, so it can't
> upgrade kf5-ktexteditor.  It's telling you that the old version is not
> available in F31.
>
>>   Problem 4: problem with installed package qt5-qtwebengine-freeworld-
>> 5.12.4-2.fc30.x86_64
>>- package qt5-qtwebengine-freeworld-5.12.4-3.fc31.x86_64 requires
>> qt5-qtbase(x86-64) = 5.12.4, but none of the providers can be installed
>
> qt5-qtbase was updated in Fedora, but qt5-qtwebengine-freeworld which
> depends on it is in rpmfusion.  I see there is a new build today, so
> this issue should be fixed soon.
>
>>- qt5-qtwebengine-freeworld-5.12.4-2.fc30.x86_64 does not belong to
>> a
>> distupgrade repository
>>- qt5-qtbase-5.12.4-4.fc30.x86_64 does not belong to a distupgrade
>> repository
>
> Just telling you that the packages are no longer available.
>
>>   Problem 5: problem with installed package scribus-generator-2.8.1-
>> 1.fc30.noarch
>>- package scribus-generator-2.8.1-2.fc31.noarch requires tkinter,
>> but
>> none of the providers can be installed
>
> "tkinter" used to be provided by the python2-tkinter package, but the
> provide has been dropped.  scribus-generator needs to change the depend
> to python2-tkinter now, although it should really move to python3
> instead.
>
>>- scribus-generator-2.8.1-1.fc30.noarch does not belong to a
>> distupgrade repository
>>- python2-tkinter-2.7.16-2.fc30.x86_64 does not belong to a
>> distupgrade repository
>
> Again, the ol

Re: Upgrading from F30 to F31 beta reboot issue

2019-10-07 Thread Alan 
On Sat, 2019-10-05 at 13:37 +, Rodger Etz wrote:
> Thanks, Chris! I did so, but reboot did not create a debugdata dir.
> Therefore I have uploaded the dnf logs.
> 
> From what I have seen so far, it still seems the best option to
> modify system-upgrade so it safes the transaction before reboot and
> reboot reruns it ... or something similar.
> 
> Trying to figure out what obscure dependency constellation this is
> causing, will be painful and most likely fail, because we do not have
> enough information and the state of dependencies changes so quickly,
> the issue might not occur after the next update of those packages.
> And even if we find this particular one, it might be there are others
> as well.

This is what I get if I don't use the --allowdelete option. The "does
not belong to a distupgrade repository" is the part that concerns me.

Error: 
 Problem 1: package gnome-shell-extension-fedmsg-0.1.9-19.fc29.noarch
requires fedmsg-notify, but none of the providers can be installed
  - fedmsg-notify-0.5.9-1.fc29.noarch does not belong to a distupgrade
repository
  - problem with installed package gnome-shell-extension-fedmsg-0.1.9-
19.fc29.noarch
 Problem 2: package plasma-discover-snap-5.15.5-1.fc30.x86_64 requires
plasma-discover = 5.15.5-1.fc30, but none of the providers can be
installed
  - plasma-discover-5.15.5-1.fc30.x86_64 does not belong to a
distupgrade repository
  - problem with installed package plasma-discover-snap-5.15.5-
1.fc30.x86_64
 Problem 3: problem with installed package kf5-ktexteditor-5.59.0-
1.fc30.x86_64
  - package kf5-ktexteditor-5.61.0-1.fc31.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed
  - kf5-ktexteditor-5.59.0-1.fc30.x86_64 does not belong to a
distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is
excluded
  - package libgit2-0.28.3-1.fc31.x86_64 is excluded
 Problem 4: problem with installed package qt5-qtwebengine-freeworld-
5.12.4-2.fc30.x86_64
  - package qt5-qtwebengine-freeworld-5.12.4-3.fc31.x86_64 requires
qt5-qtbase(x86-64) = 5.12.4, but none of the providers can be installed
  - qt5-qtwebengine-freeworld-5.12.4-2.fc30.x86_64 does not belong to a
distupgrade repository
  - qt5-qtbase-5.12.4-4.fc30.x86_64 does not belong to a distupgrade
repository
 Problem 5: problem with installed package scribus-generator-2.8.1-
1.fc30.noarch
  - package scribus-generator-2.8.1-2.fc31.noarch requires tkinter, but
none of the providers can be installed
  - scribus-generator-2.8.1-1.fc30.noarch does not belong to a
distupgrade repository
  - python2-tkinter-2.7.16-2.fc30.x86_64 does not belong to a
distupgrade repository
 Problem 6: package kf5-ktexteditor-devel-5.61.0-1.fc31.x86_64 requires
kf5-ktexteditor(x86-64) = 5.61.0-1.fc31, but none of the providers can
be installed
  - problem with installed package kf5-ktexteditor-devel-5.59.0-
1.fc30.x86_64
  - package kf5-ktexteditor-5.61.0-1.fc31.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed
  - kf5-ktexteditor-devel-5.59.0-1.fc30.x86_64 does not belong to a
distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is
excluded
  - package libgit2-0.28.3-1.fc31.x86_64 is excluded
(try to add '--skip-broken' to skip uninstallable packages)


> 
> Is it worth it to start a discussion on devel@ ?
> 
> ‐‐‐ Original Message ‐‐‐
> On Friday, 4. October 2019 20:44, Chris Murphy <
> li...@colorremedies.com> wrote:
> 
> > I suggest trying --debugsolver with both the download and reboot
> > subcommands. 'man dnf system-upgrade' suggests --debugsolver should
> > work. I recommend taring the debugdata dir that will create, and
> > setting the filename and attachment description so it's clear
> > whether
> > the tarball is for reboot or download.
> > 
> > The debugdata dir will be located in the current dir. So that'll be
> > easy to find for the download command. But I have no idea where
> > it'll
> > be located for reboot so you'll probably have to use find.
> > 
> > Sometimes these are bigger than the 20MB attachment size, so you
> > might
> > have to stick it in a dropbox/googledrive like thing and post the
> > URLs
> > for them in the bug report.
> > 
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > --
> > 
> > Chris Murphy
> >

Re: Upgrading from F30 to F31 beta reboot issue

2019-10-03 Thread alan 


> Yes, thanks.
>
> As the pkgs are pretty fundamental I prefer to keep them. I had bad
> eyperiences in the past with this approach. Before I go through dependency
> hell, I'd rather quickly reinstall the whole box.
> And as it is just a system-upgrade test for me, it can wait.

It still needs to get fixed. A "normal" user would be VERY confused by
this issue. Double-plus ungood.


>  Original-Nachricht 
> An 3. Okt. 2019, 22:35, Felix Miata schrieb:
>
>> Rodger Etz composed on 2019-10-03 20:15 (UTC):
>>
>>> Tried that, but it leads to dependency probs that cannot be solved by
>>> --allowerasing or --skip-broken.
>> Another thing I do when such problems arise is remove the offending
>> packages,
>> upgrade, then add them back afterward. Typically this means dnf remove
>> kf5* kde*
>> plasm* *breez*.
>> --
>> Evolution as taught in public schools is religion, not science.
>>
>> Team OS/2 ** Reg. Linux User #[211409](tel:211409) ** a11y rocks!
>>
>> Felix Miata *** http://fm.no-ip.com/
>> ___
>> test mailing list -- test@lists.fedoraproject.org
>> To unsubscribe send an email to test-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>


Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Upgrading from F30 to F31 beta reboot issue

2019-10-03 Thread Alan 
On Wed, 2019-10-02 at 19:13 -0600, Chris Murphy wrote:
> On Wed, Oct 2, 2019 at 6:14 PM Samuel Sieb  wrote:
> > On 10/2/19 5:03 PM, Chris Murphy wrote:
> > > On Wed, Oct 2, 2019 at 3:32 PM Alan  wrote:
> > > > This is interesting... I am going to do a heavy clean of the
> > > > packages
> > > > and try again.
> > > > 
> > > > Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary
> > > > Oct 02 11:22:23 daimajin dnf[1390]:
> > > > ===
> > > > 
> > > > =
> > > > Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages
> > > > Oct 02 11:22:23 daimajin dnf[1390]: Upgrade4828 Packages
> > > > Oct 02 11:22:23 daimajin dnf[1390]: Remove   12 Packages
> > > > Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages
> > > > Oct 02 11:22:23 daimajin dnf[1390]: Skip  3 Packages
> > > > Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service:
> > > > Succeeded.
> > > > Oct 02 11:22:27 daimajin kernel: audit: type=1131
> > > > audit(1570040547.732:91): pid=1 uid=0 auid=4294967295
> > > > ses=4294967295
> > > > subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam>
> > > > Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0
> > > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > > msg='unit=systemd-hostnamed comm="systemd" exe="/usr/>
> > > > Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G
> > > > Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M
> > > 
> > > I'm confused right off the bat, if this is the reboot that's
> > > supposed
> > > to do the offline upgrade. There shouldn't be anything to
> > > download, it
> > > should already have everything downloaded.
> > 
> > dnf runs builds the whole transaction again using cached
> > data.  There's
> > a mention of that at the bottom.  It shouldn't have to download,
> > but
> > that's the problem here.  Somehow there are some missing packages
> > (maybe
> > damaged, but it looks more like missing) and it can't download them
> > because it's in cache-only mode.
> 
> I'm thinking both missing and corrupt. The early message "download
> size: 19 M" is consistent with missing, but then why are they missing
> when the download process includes a transaction check? Ostensibly,
> the transaction check is the same as what happens in the
> offline/cache
> mode. I'm not sure how 'download --allow-erasing' gets passed onto
> the
> reboot and subsequent upgrade. Does it need to be passed twice? And
> then also I wonder if -v can be passed to 'dnf system-upgrade reboot'
> to get verbose messages for the offline/upgrade boot dumped into the
> journal.
> 
> "Error opening file for checksum" taken literally, to me, means the
> file is there but fails RPM checksum. Similar to the above question I
> wonder if '--rpmverbosity debug' can be passed to dnf for the reboot.
> But if so, it should reveal if this really is an RPM checksum fail.

The file does not exist. Not there. I checked.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Upgrading from F30 to F31 beta reboot issue

2019-10-03 Thread Alan 
On Wed, 2019-10-02 at 18:03 -0600, Chris Murphy wrote:
> On Wed, Oct 2, 2019 at 3:32 PM Alan  wrote:
> > This is interesting... I am going to do a heavy clean of the
> > packages
> > and try again.
> > 
> > Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary
> > Oct 02 11:22:23 daimajin dnf[1390]:
> > ===
> > 
> > =
> > Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages
> > Oct 02 11:22:23 daimajin dnf[1390]: Upgrade4828 Packages
> > Oct 02 11:22:23 daimajin dnf[1390]: Remove   12 Packages
> > Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages
> > Oct 02 11:22:23 daimajin dnf[1390]: Skip  3 Packages
> > Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service:
> > Succeeded.
> > Oct 02 11:22:27 daimajin kernel: audit: type=1131
> > audit(1570040547.732:91): pid=1 uid=0 auid=4294967295
> > ses=4294967295
> > subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam>
> > Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > msg='unit=systemd-hostnamed comm="systemd" exe="/usr/>
> > Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G
> > Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M
> 
> I'm confused right off the bat, if this is the reboot that's supposed
> to do the offline upgrade. There shouldn't be anything to download,
> it
> should already have everything downloaded.

It should, but it doesn't. I cleaned everything I could think of and
reran the system upgrade and redownloaded everything and still get the
same problem. Those packages exist on the F30 system, but something
goes wrong in the update. There is only about 220Gigs free, so it is
not drive space.

> 
> > Oct 02 11:23:01 daimajin dnf[1390]: Downloading Packages:
> > Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-
> > 3589ee8a7ee1691d/packages/plasma-
> > desktop-5.16.4-1.fc31.x86_64.rpm
> > Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4-
> > 1.fc31.x86_64" from repository "fedora" has incorrect checksum
> > Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-
> > 3589ee8a7ee1691d/packages/plasma-
> > desktop-kimpanel-scim-5.16.4-1.fc31.x86_>
> > Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-
> > kimpanel-
> > scim-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect
> > checksum
> > Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-
> > 3589ee8a7ee1691d/packages/plasma-
> > integration-5.16.4-1.fc31.x86_64.rpm
> > Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-integration-
> > 5.16.4-
> > 1.fc31.x86_64" from repository "fedora" has incorrect checksum
> > Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-
> > 3589ee8a7ee1691d/packages/plasma-
> > lookandfeel-fedora-5.16.4-1.fc31.noarch.>
> > Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-lookandfeel-
> > fedora-
> > 5.16.4-1.fc31.noarch" from repository "fedora" has incorrect
> > checksum
> > Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-
> > 3589ee8a7ee1691d/packages/plasma-
> > workspace-5.16.4-1.fc31.x86_64.rpm
> > Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace-
> > 5.16.4-
> > 1.fc31.x86_64" from repository "fedora" has incorrect checksum
> > Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-
> > 3589ee8a7ee1691d/packages/plasma-
> > workspace-wayland-5.16.4-1.fc31.x86_64.r>
> > Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace-
> > wayland-
> > 5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect
> > checksum
> > Oct 02 11:23:20 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm-
> > breeze-5.16.4-1.fc31.noarch.rpm
> > Oct 02 11:23:20 daimajin dnf[1390]: Package "sddm-breeze-5.16.4-
> > 1.fc31.noarch" from repository "fedora" has incorrect checksum
> >

Re: Upgrading from F30 to F31 beta reboot issue

2019-10-03 Thread Alan 
On Wed, 2019-10-02 at 14:34 -0700, Samuel Sieb wrote:
> On 10/2/19 2:31 PM, Alan wrote:
> > Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-
> > 3589ee8a7ee1691d/packages/plasma-
> > desktop-5.16.4-1.fc31.x86_64.rpm
> > Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4-
> > 1.fc31.x86_64" from repository "fedora" has incorrect checksum
> 
> That's weird, can you check if those files actually exist?

They don't!

I reran it after clearing all the packages and upgrade packages and
data and reran it and got the same results. It passes all the
transaction tests. Everything claims to be OK for the upgrade, but
those files don't exists for some unknown reason.

Could it be some corruption in the rpm database? 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Upgrading from F30 to F31 beta reboot issue

2019-10-02 Thread Alan 
On Wed, 2019-10-02 at 15:23 -0600, Chris Murphy wrote:
> On Wed, Oct 2, 2019 at 3:02 PM Alan  wrote:
> > I have a laptop (Lenovo W540) running Fedora 30. I have preped it
> > for
> > upgrade using dnf.
> > 
> > I get to the reboot step is where it gets interesting.
> > 
> > I reboot and enter the drive password. It goes into the install,
> > says
> > it is preparing and then before it installs anything, it reboots.
> > 
> > Any idea what log to check to figure out why? It passed all the
> > transaction tests.
> 
> Logging goes to the journal. So you'll find it with 'journalctl -b
> -1'
> assuming the (failed) update boot is the immediately prior boot. Can
> you confirm you've done
> 
> # dnf system-upgrade download --releasever=31
> # dnf system-upgrade reboot

Yes. I also had --allowerasing.

This is interesting... I am going to do a heavy clean of the packages
and try again.

Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary
Oct 02 11:22:23 daimajin dnf[1390]:
===
=
Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages
Oct 02 11:22:23 daimajin dnf[1390]: Upgrade4828 Packages
Oct 02 11:22:23 daimajin dnf[1390]: Remove   12 Packages
Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages
Oct 02 11:22:23 daimajin dnf[1390]: Skip  3 Packages
Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service:
Succeeded.
Oct 02 11:22:27 daimajin kernel: audit: type=1131
audit(1570040547.732:91): pid=1 uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam>
Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-hostnamed comm="systemd" exe="/usr/>
Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G
Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M
Oct 02 11:23:01 daimajin dnf[1390]: Downloading Packages:
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum:
/var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-
desktop-5.16.4-1.fc31.x86_64.rpm
Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4-
1.fc31.x86_64" from repository "fedora" has incorrect checksum
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum:
/var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-
desktop-kimpanel-scim-5.16.4-1.fc31.x86_>
Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-kimpanel-
scim-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect
checksum
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum:
/var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-
integration-5.16.4-1.fc31.x86_64.rpm
Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-integration-5.16.4-
1.fc31.x86_64" from repository "fedora" has incorrect checksum
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum:
/var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-
lookandfeel-fedora-5.16.4-1.fc31.noarch.>
Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-lookandfeel-fedora-
5.16.4-1.fc31.noarch" from repository "fedora" has incorrect checksum
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum:
/var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-
workspace-5.16.4-1.fc31.x86_64.rpm
Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace-5.16.4-
1.fc31.x86_64" from repository "fedora" has incorrect checksum
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum:
/var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-
workspace-wayland-5.16.4-1.fc31.x86_64.r>
Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace-wayland-
5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum
Oct 02 11:23:20 daimajin dnf[1390]: Error opening file for checksum:
/var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm-
breeze-5.16.4-1.fc31.noarch.rpm
Oct 02 11:23:20 daimajin dnf[1390]: Package "sddm-breeze-5.16.4-
1.fc31.noarch" from repository "fedora" has incorrect checksum
Oct 02 11:23:24 daimajin dnf[1390]: Error: Some packages have invalid
cache, but cannot be downloaded due to "--cacheonly" option
Oct 02 11:23:24 daimajin systemd[1]: dnf-system-upgrade.service: Main
process exited, code=exited, status=1/FAILURE
Oct 02 11:23:24 daimajin systemd[1]: dnf-system-upgrade.service: Failed
with result 'exit-code'.
Oct 02 11:23:24 daimajin systemd[1]: Failed to start System Upgrade
using DNF.

___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Upgrading from F30 to F31 beta reboot issue

2019-10-02 Thread Alan 
I have a laptop (Lenovo W540) running Fedora 30. I have preped it for
upgrade using dnf.

I get to the reboot step is where it gets interesting.

I reboot and enter the drive password. It goes into the install, says
it is preparing and then before it installs anything, it reboots.

Any idea what log to check to figure out why? It passed all the
transaction tests.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

How do I get a change made to a getfedora.org web page?

2019-04-08 Thread alan 

The page https://getfedora.org/workstation/prerelease/ mentions using the
fedora media writer to write ISOs to USB drives.

It says you can download it using dnf, but it does not give the package name.

The package name is "mediawriter". It would be nice it it actually said
that next to where it mentions it. (The link goes to something that does
not mention media writer.)

Thanks!


perl -pe 's/^\s+//g' *.py
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Problems after upgrade from F29 to F30-beta [FIXED}

2019-04-08 Thread alan 


> You should be able to uninstall them using dnf from the command line,
> assuming you can get to a TTY. If you manually installed any (e.g.
> dash2dock) check the git repository to see if it comes with a makefile
> rule to uninstall the extension. I mention dash2dock specifically because
> I know that extension comes with said rule.
>
> There may be a better way to handle this that I'm unaware of, but this is
> how I would do it.

There is a better way...

I took .local/share/gnome-shell/extensions and renamed it. The gnome-shell
started up properly.

This is a bug in gnome-shell. If there is old versions the user
downloaded, it crashes.

>
> Best of luck to you, keep us updated.
> - Tom
>
>
>
> Apr 8, 2019, 5:24 PM by a...@clueserver.org:
>
>>> You kinda have to fix or mitigate those in order, because gnome-shell
>>> could be crashing due to either a) or b); or even d) which are the
>>> gnome-shell extensions. Maybe the easiest way to test that is to
>>> create a new user on the cli, and attempt to login as that new user. I
>>> think gnome shell extensions are user specific so maybe a new clean
>>> environment will confirm/deny if that's a possible problem.
>>>
>>
>> The extensions are the problem. It is trying to load old Gnome
>> extensions
>> and failing.
>>
>> Is there a way to prevent Gnome from loading extensions?
>>
>>
>> perl -pe 's/^\s+//g' *.py
>> ___
>> test mailing list -- > test@lists.fedoraproject.org
>> 
>> To unsubscribe send an email to > test-le...@lists.fedoraproject.org
>> 
>> Fedora Code of Conduct: > https://getfedora.org/code-of-conduct.html
>> 
>> List Guidelines: >
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> 
>> List Archives: >
>> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>> 
>>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>


perl -pe 's/^\s+//g' *.py
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Problems after upgrade from F29 to F30-beta

2019-04-08 Thread alan 

> You kinda have to fix or mitigate those in order, because gnome-shell
> could be crashing due to either a) or b); or even d) which are the
> gnome-shell extensions. Maybe the easiest way to test that is to
> create a new user on the cli, and attempt to login as that new user. I
> think gnome shell extensions are user specific so maybe a new clean
> environment will confirm/deny if that's a possible problem.

The extensions are the problem. It is trying to load old Gnome extensions
and failing.

Is there a way to prevent Gnome from loading extensions?


perl -pe 's/^\s+//g' *.py
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Problems after upgrade from F29 to F30-beta

2019-04-08 Thread alan 


> On Mon, Apr 8, 2019 at 10:55 AM  wrote:
>>
>>
>> I upgraded from Fedora 29 to Fedora 30 beta on my laptop.
>>
>> The system boots, asks for the drive password, and then brings up my
>> login
>> in GDM. I select my user account and then enter my password. The screen
>> goes black and then goes back to the gdm login screen.
>>
>> If I try XFCE, it just hangs.
>
> a) login remotely with ssh, `sudo journalctl -b > journal.txt` and
> attach it to a bug report
> b) boot with parameter `systemd.debug-shell=1` and you should have a
> root login available at tty9, collect journal and attach to bug report


https://bugzilla.redhat.com/show_bug.cgi?id=1697592

Done.



---
perl -pe 's/^\s+//g' *.py
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Problems after upgrade from F29 to F30-beta

2019-04-08 Thread alan 


> On Mon, 2019-04-08 at 09:54 -0700, a...@clueserver.org wrote:
>> I upgraded from Fedora 29 to Fedora 30 beta on my laptop.
>>
>> The system boots, asks for the drive password, and then brings up my
>> login
>> in GDM. I select my user account and then enter my password. The screen
>> goes black and then goes back to the gdm login screen.
>>
>> If I try XFCE, it just hangs.
>>
>> There is no root password configured. Emergency boot hangs because it
>> wants root for console. sshd is not started, so I can't connect that
>> way.

Adding a password to root fixes the emergency boot option. Reported as bug.

>>
>> /home is on a separate encrypted drive with the same password. I am
>> wondering if it is not getting mounted.

It is getting mounted.

>> Ideas?
>
> Boot with '3' kernel arg, that should get you to a console where you
> can log in and poke around a bit to try and figure out what's going on
> - look at the logs from the failed boot, and so on.

I can login to the normal user at a terminal prompt. I can login
graphically as root.

Now dredging through logs.



---
perl -pe 's/^\s+//g' *.py
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Problems after upgrade from F29 to F30-beta

2019-04-08 Thread alan 

I upgraded from Fedora 29 to Fedora 30 beta on my laptop.

The system boots, asks for the drive password, and then brings up my login
in GDM. I select my user account and then enter my password. The screen
goes black and then goes back to the gdm login screen.

If I try XFCE, it just hangs.

There is no root password configured. Emergency boot hangs because it
wants root for console. sshd is not started, so I can't connect that way.

/home is on a separate encrypted drive with the same password. I am
wondering if it is not getting mounted.

I am building a thumb drive to see if I can get more information. I tried
the #fedora-qa IRC channel, but it won't let me write there.

Ideas?


perl -pe 's/^\s+//g' *.py
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Please consider adding a QA test case for shutdown, which gives more time to see error mesages - i.e. uses "halt"

2019-01-12 Thread Alan Jenkins 
Alan provided additional input for the proposed new shutdown test. I 
have updated the document and attached it.


This test case 
(https://fedoraproject.org/wiki/QA:Testcase_base_shutdown/reboot) does 
not seem to be in the Base test matrix anymore. We should consider 
adding it back to the matrix.


Thanks very much for correcting me. I guess the shutdown/poweroff and 
reboot test were removed to save time. Possibly I should only argue for 
adding one "halt" test case, with whatever log analysis we can do to 
test how well the halt worked.


At least the non-VM installer tests will hopefully already lead to bug 
reports. I.e. when a tester reboots or powers off the system at the end 
of the test, the tester will notice if the system hangs instead, etc.


Regards
Alan
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Please consider adding a QA test case for shutdown, which gives more time to see error mesages - i.e. uses "halt"

2019-01-11 Thread Alan Jenkins 
On 11/01/2019, pmkel...@frontier.com  wrote:

>> https://fedoraproject.org/wiki/QA:Testcase_base_shutdown/reboot
>>
>> Basically:
>>
>>   1. On a running system, change to a virtual console by pressing
>> Ctrl+Alt+F2
>>   2. At the virtual console, login as the root user
>> +3. Halt the system by running the command
>> +
>> + halt
>> +
>> +4. Read the on-screen messages.
>> +5. You now need to manually re-boot the system. On most hardware (which
>> complies with ACPI), you can manually power off by holding the power
>> button down for five seconds. Then press the power button to power on
>> again.
>>   6. After the system boots, again change to a virtual console by pressing
>> Ctrl+Alt+F2. Note, manually booting the system may be required if the
>> previous step fails.

> pmkelly: Prior step is manual reboot so not sure what this note means

Right, sorry!  This note properly belongs just after the "reboot"
command, i.e. it should have been in step 9 below.

>>   7. At the virtual console, login as the root user
>>   8. Reboot the system by running the command
>>
>>  reboot
>>
>>   9. After the system boots, once again change to a virtual console by
>> pressing Ctrl+Alt+F2.
>> ...

> I took a try a formatting your proposed procedure in the attached file.
> I'm a very junior member of the QA team, and thought I could help a bit
> by doing this. It seems like a good idea to me. Please point out any
> mistakes I made.
>
>   Have a Great Day!
>
>   Pat (tablepc)

Oh, I see what you did now, moving the "expected results" underneath
the relevant step.

It's a good point, especially with the extra steps, there is actually
quite a lot to interpret in this one test case.  It might well be
there is a better way to add a "halt" test, than the edit I proposed.

Looking at your formatting, I think there was some ambiguity in the
original formatting:

-When the system boots, either from a reboot or shutdown operation,
the system successfully boots without error, and all expected disk
partitions are cleanly mounted.
+When the system boots, either after a halt, reboot or shutdown
operation, the system successfully boots without error. All expected
disk partitions are cleanly mounted. Boot logs do not show any "fsck"
(filesystem repair) operations, or "recovering journal" (ext3/4
journal recovery).

E.g. do we need testers to check which filesystems are mounted after
*each* type of shutdown - reboot, shutdown/poweroff, and now halt?  Or
does "either" mean a tester can just look e.g. after the reboot, and
not after the other two, because they are really very similar?

I do not argue in favour of testing after each of the three types of
shutdown.  I think of them as not differing very much.  IMO it is a
bit unfair to tell the tester to read logs checking for errors, and
check the list of mounted partitions, three times in a row.  If that
is really what we want, then perhaps the test needs to include more
information about exactly what they are supposed to be looking at
(what commands?)

Secondly, I do want to argue in favour of looking out for `fsck`,
including when `fsck` does "recovering journal".  If nothing else, the
messages you can see with "halt" might still be unclear.   So it might
help the tester work more confidently if they know to look for `fsck`
logs at the same time.

I for one do not know 100% what "halt" is "supposed" to look like.
Most of it is I have a slow computer.  And I get very suspicious when
it looks like there is more screen-scrolling during shutdown than I
remember from last time :-).

I think it could be useful to mention looking for `fsck` log messages.
It would help define what we think "cleanly mounted" means.  I guess
"recovering journal" from fsck.ext4 will be the most common "unclean"
message.  We don't really want to see "recovering journal" because it
indicates an unclean unmount, and it's useful to mention "recovering
journal" specifically because the next message may still suggest
everything is "clean":

systemd-fsck[461]: /dev/mapper/alan_dell_2016-fedora: recovering journal
systemd-fsck[461]: /dev/mapper/alan_dell_2016-fedora: clean,
365666/2621440 files, 7297878/10485760 blocks

I think the command to check is `journalctl -b /usr/lib/systemd/systemd-fsck`

But... I understand the `fsck` part makes the test case longer to
read, and I haven't checked what would make sense for systems using
XFS in place of ext4, etc.

One alternative approach might be to add a new, separate test case
where you 1) use "halt" 2) have specific instructions about how to
boot and check the `fsck` logs afterwards.

Re: Please consider adding a QA test case for shutdown, which gives more time to see error mesages - i.e. uses "halt"

2019-01-11 Thread Alan Jenkins 
On 11/01/2019, pmkel...@frontier.com  wrote:
>
> On 1/11/19 7:26 AM, Alan Jenkins wrote:
>> Hi QA people!
>>
>> In the past few years I've seen four shutdown bugs.  The problem is that
>> the screen turns off too quickly, so even if it shows error messages, most
>> people don't actually see them.  Or at least, it requires extra effort if
>> you want to report them.
>>
>> At least three of the four shutdown bugs could have been shown up by
>> testing "systemctl halt", which leaves the screen turned and showing the
>> final shutdown messages.
>>
>> * https://bugzilla.redhat.com/show_bug.cgi?id=1575376
>> * https://bugzilla.redhat.com/show_bug.cgi?id=1665432
>> * https://github.com/systemd/systemd/issues/6796
>>
>> In the first two cases, I believe it did not cause a big issue for *me*.
>> However, the error messages were for disassembling DM devices.  These may
>> include "dmraid", such as intel "IMSM" fakeraid.  If a *raid* device is
>> not shut down cleanly, it requires a long resync on the next boot.  This
>> also breaks the redundancy of the raid array for the duration of the
>> resync.  So it can be quite undesirable!
>>
>> The third case was a failure to cleanly unmount the fileystem, causing
>> ext4 journal recovery on the next boot.
>>
>> Please can you add a "systemctl halt" test to the relevant test case?  I
>> would love to see this tested as part of the Fedora release process.
>>
>> "halt" is a pretty weird case and I only find it useful for this type of
>> testing.  So IMO we must still keep both the normal poweroff (shutdown)
>> test, and the reboot test as well.
>>
>> https://fedoraproject.org/wiki/QA:Testcase_base_shutdown/reboot
>>
>> Basically:
>>
>>   1. On a running system, change to a virtual console by pressing
>> Ctrl+Alt+F2
>>   2. At the virtual console, login as the root user
>> +3. Halt the system by running the command
>> +
>> + halt
>> +
>> +4. Read the on-screen messages.
>> +5. You now need to manually re-boot the system. On most hardware (which
>> complies with ACPI), you can manually power off by holding the power
>> button down for five seconds. Then press the power button to power on
>> again.
>>   6. After the system boots, again change to a virtual console by pressing
>> Ctrl+Alt+F2. Note, manually booting the system may be required if the
>> previous step fails.
>>   7. At the virtual console, login as the root user
>>   8. Reboot the system by running the command
>>
>>  reboot
>>
>>   9. After the system boots, once again change to a virtual console by
>> pressing Ctrl+Alt+F2.
>>   10. At the virtual console, login as a non-root user. If no non-root
>> user accounts are available, you can create a new user account using the
>> command useradd
>>   11. Power off the system by running the shutdown command. Consult the
>> man page for different acceptable [TIME] values. For example, to power off
>> the system immediately, type the following command.
>>
>>   shutdown now
>>
>>   12. Lastly, power on the system.  Check that it boots successfully.
>>
>>   ## Expected Results
>>
>>   1. A login prompt is offered at the virtual console
>> +2. The `halt` is accepted and halts the system.  The screen is left
>> powered on, showing the final shutdown messages.  No system filesystem /
>> LVM device is left mounted / active when the system finally halts.  In
>> some cases you might see a number of retries.
>>   3. The `reboot` is accepted and initiates a system reboot. The system
>> reboots with no additional user interaction.
>>   4. The shutdown is accepted and powers off the system without error.
>> -5. When the system boots, either after a halt, reboot or shutdown
>> operation, the system successfully boots without error, and all expected
>> disk partitions are cleanly mounted.
>> +5. When the system boots, either after a halt, reboot or shutdown
>> operation, the system successfully boots without error. All expected disk
>> partitions are cleanly mounted. Boot logs do not show any "fsck"
>> (filesystem repair) operations, or "recovering journal" (ext3/4 journal
>> recovery).
>>
>> Thanks for all the testing :-)
>> Alan

> I took a try a formatting your proposed procedure in the attached file.
> I'm a very junior member of the QA team, and thought I could help a bit
> by doing this. It seems like a good idea to me. Please point out

Please consider adding a QA test case for shutdown, which gives more time to see error mesages - i.e. uses "halt"

2019-01-11 Thread Alan Jenkins 
Hi QA people!

In the past few years I've seen four shutdown bugs.  The problem is that the 
screen turns off too quickly, so even if it shows error messages, most people 
don't actually see them.  Or at least, it requires extra effort if you want to 
report them.

At least three of the four shutdown bugs could have been shown up by testing 
"systemctl halt", which leaves the screen turned and showing the final shutdown 
messages.  

* https://bugzilla.redhat.com/show_bug.cgi?id=1575376
* https://bugzilla.redhat.com/show_bug.cgi?id=1665432
* https://github.com/systemd/systemd/issues/6796

In the first two cases, I believe it did not cause a big issue for *me*.  
However, the error messages were for disassembling DM devices.  These may 
include "dmraid", such as intel "IMSM" fakeraid.  If a *raid* device is not 
shut down cleanly, it requires a long resync on the next boot.  This also 
breaks the redundancy of the raid array for the duration of the resync.  So it 
can be quite undesirable!

The third case was a failure to cleanly unmount the fileystem, causing ext4 
journal recovery on the next boot.

Please can you add a "systemctl halt" test to the relevant test case?  I would 
love to see this tested as part of the Fedora release process.

"halt" is a pretty weird case and I only find it useful for this type of 
testing.  So IMO we must still keep both the normal poweroff (shutdown) test, 
and the reboot test as well.

https://fedoraproject.org/wiki/QA:Testcase_base_shutdown/reboot

Basically:

 1. On a running system, change to a virtual console by pressing Ctrl+Alt+F2
 2. At the virtual console, login as the root user
+3. Halt the system by running the command
+
+ halt
+
+4. Read the on-screen messages.
+5. You now need to manually re-boot the system. On most hardware (which 
complies with ACPI), you can manually power off by holding the power button 
down for five seconds. Then press the power button to power on again.
 6. After the system boots, again change to a virtual console by pressing 
Ctrl+Alt+F2. Note, manually booting the system may be required if the previous 
step fails.
 7. At the virtual console, login as the root user
 8. Reboot the system by running the command

reboot

 9. After the system boots, once again change to a virtual console by pressing 
Ctrl+Alt+F2.
 10. At the virtual console, login as a non-root user. If no non-root user 
accounts are available, you can create a new user account using the command 
useradd
 11. Power off the system by running the shutdown command. Consult the man page 
for different acceptable [TIME] values. For example, to power off the system 
immediately, type the following command.

 shutdown now

 12. Lastly, power on the system.  Check that it boots successfully.

 ## Expected Results

 1. A login prompt is offered at the virtual console
+2. The `halt` is accepted and halts the system.  The screen is left powered 
on, showing the final shutdown messages.  No system filesystem / LVM device is 
left mounted / active when the system finally halts.  In some cases you might 
see a number of retries.
 3. The `reboot` is accepted and initiates a system reboot. The system reboots 
with no additional user interaction.
 4. The shutdown is accepted and powers off the system without error.
-5. When the system boots, either after a halt, reboot or shutdown operation, 
the system successfully boots without error, and all expected disk partitions 
are cleanly mounted.
+5. When the system boots, either after a halt, reboot or shutdown operation, 
the system successfully boots without error. All expected disk partitions are 
cleanly mounted. Boot logs do not show any "fsck" (filesystem repair) 
operations, or "recovering journal" (ext3/4 journal recovery).

Thanks for all the testing :-)
Alan
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Introduction

2017-04-07 Thread Alan McGeoch 
Hi everyone,
I've used Fedora for a good long while, and i imagine i should have got 
involved a long time ago.

I've started testing updates, and hope to get a bit more involved in other 
testing areas, and other areas of Fedora as time goes on. I've applied to join 
the QA group as well.

You might also find me in IRC as 'Eden'
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Self-introduction: Alan Ernhart

2016-06-20 Thread Alan Ernhart 
Hi,

I'm Alan Ernhart and reside in the USA. I've a couple decades in software
test automation, including performance testing at IBM and development of a
Python framework for testing of REST APIs. I've used RHEL a fair amount in
that, but Fedora's been my laptop machine for about 9 years. So I can
attest to the impressive progress in all aspects of the distro.

I learned alot in that process, so would like to contribute back as I can.
There are many places one can jump into open source these days, but
Fedora's on my main screen, so it's the logical place. And I've long been
impressed with the Four Foundations.

Thanks for doing great work in the foundations of FOSS.

Alan

IRC/FAS: aernhart
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: My Fedora 15 beta experiences so far

2011-05-22 Thread Alan 
On Fri, 2011-05-13 at 22:44 -0700, Adam Williamson wrote:
 On Sat, 2011-05-14 at 09:47 +0600, Angel wrote:
 
  If you click the network icon of the panel then Network Settings, that
  ´s the different thing (dumbed down to absolute worthlessness).
 
 yeah - it's so worthless you can only connect to a typical wired or
 wireless network configuration, y'know, like probably 80-90% of all
 network connections ever. I do wish people would be less absurdly
 extremist about everything. 'It doesn't yet cover my particular use
 case' is not the same thing as 'worthless'.

If you can't change anything it is not very useful.  You can turn it on
and off and that is it.  If you need to change the IP address or give it
a fixed IP address or anything else you have to use a different app that
is not installed by default.  (And which requires, oddly enough, a
working network.)

My current problem with networking is that it drops the default route
after a while.  (If I let it sit over night, for example.)  It does not
seem to matter if the connection is actively being used or not. (It was
hard enough to get it to create a default route with a fixed IP address.
That part got fixed in a recent update. It still drops after a while.)

If wanting it to actually work and be useful is extreme, then yes.  I
dislike the idea that in order to appeal to new users you have to remove
any and all ability to configure things so they won't get confused
distasteful in the extreme.


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

My Fedora 15 beta experiences so far

2011-05-13 Thread alan 
I have to admit, this is the most painful Fedora installation I have ever
done. (And I have used them all.)

The networking came up as IPv6 *only*. My router does not do IPv6 and my
ISP (Qwest) does not know when their network ever will. In order to get it
to work I had to hack files in /etc/sysconfig and use dhclient to get an
address since the Network Manager applet is dumbed down to absolute
worthlessness. (More on that later.)  The networking problems seem to have
been fixed, but there were far too many of them. (Having no default route
for fixed IP addresses was a pain.)

If I were to grade Gnome 3 it would be incomplete.  It looks nice, but
it is missing large chunks of functionality. For example, network
configuration is useless. Gnome screen saver's config panel is no where to
be found. To switch the desktop with a mouse now takes 2-3 clicks where it
used to take one. There are no applets to be found. The desktop is bare,
unless you use an the Gtweakui program to hack it. (Which most users will
not ever know about since it is not installed by default.) The option to
use the classic style is a lie. It is still Gnome 3, but with a
kinda-sorta Gnome 2 look. (With all the above still missing.)

Gnome 2 had similar problems. When it was first released, it was dumbed
down and was lacking most of the functionality of Gnome 1.  Now that they
finally have Gnome 2 working well I guess they felt they had to pitch it
all out and start over. This new design looks nice, but is not that
usable. A UI should make it easier to get to what you want to do, not add
useless mouse clicks.

My biggest complaint though is the kernel. I am getting kernel panics in
ext4! (When I can get a log I will post it. It does not get written to
disk since the filesystem dies.)

Another thing... I cannot find a way to disable the Nouveau kernel module.
I have tried all the methods that worked before (rdblacklist and the
modules blacklist.) Nothing seems to work. I am going to have to rebuild
the kernel rpm. Why is this more difficult?

The reason I went to this version when I did was due to a sort of double
bind.  Fedora 13 uses 2.6.34. USB3 does not work well with that kernel. (I
have already spoken with the maintainer. She thinks she knows the cause
and is going to backport the patch.) 2.6.35+ works with USB3, but another
program I use often does not work with my hand-rolled kernel. (Threading
issue.) Upgrade seemed like a good option. Now I am not so sure.

Hopefully I will be able to make this thing work.  I may have to go to KDE
for a bit until the Gnome developers finish writing it. (How long that
will take, I have no idea...)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test