reversible dual-boot test station
by Chris Murphy
Hi,
I mentioned this in a QA meeting, and have given it enough testing that I think it's broadly usable. If desired it can be copied out of my user account and put up somewhere where QA folks will see it and can modify it as issues or improvements are discovered.
What is it? The idea is to produce a system that can confidently be used for baremetal testing, without risking the primary operating system. While VM's are a great way to test, it's also a really idealized environment that tends to not expose an assortment of bugs that affect particular hardware. But then quite a lot of folks reasonably don't want to upgrade their daily use hardware early on, because they don't want to always have to debug things, or have to figure out how to undo the upgrade if it really goes badly.
Therefore, I present a dual-boot setup offering:
* no re-partitioning;
* no installation step, instead system upgrade is used;
* reversibility, or undoability, i.e. with just a few steps you can delete the "test OS".
https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation
--
Chris Murphy
2 months
Re: Donate 1 minute of your time to test upgrades from F38 to F39
by Luna Jernberg
Did this on my Thinkpad Edge a couple of days ago, and it went fine :)
Den ons 23 aug. 2023 kl 20:23 skrev Miroslav Suchý <msuchy(a)redhat.com>:
>
> Do you want to make Fedora 39 better? Please spend 1 minute of your time and try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
>
> dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
> This command does not replace `dnf system-upgrade`, but it will reveal potential problems.
>
> You may also run `dnf upgrade` before running this command.
>
>
> The `--assumeno` will just test the transaction, but does not make the actual upgrade.
>
>
> In case you hit dependency issues, please report it against the appropriate package.
>
> Or against fedora-obsolete-packages if that package should be removed in Fedora 39. Please check existing reports against fedora-obsolete-packages first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F39FailsToInstall) reports:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=2168845&bug_id_type=anddep...
>
>
> Two notes:
>
> * you may want to run the same command with dnf5 to help test new dnf.
>
> * this command found zero issues on my personal system - great work all everybody!
>
>
> Thank you
>
> Miroslav
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
7 months, 3 weeks
Make toolbx a crit-path package
by Sumantro Mukherjee
Hey Folks!
Toolbx is very necessary and is becoming very important. It provides
the basic and core
functionality for many users who use immutable OS as daily driver for
installing apps with
dnf. In many cases, help devs manage deps, libs and envs.
Functional breakage of Toolbx causes distress and many folks might be
actually running
apps inside and if after "dnf update" things fall apart[0], that's great UX.
I want to mark Toolbx rpm as crit-path.. thoughts?
Any ideas on how to go about this?
[0] https://github.com/containers/podman/issues/19634
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
8 months
[Test Week] F39 Anaconda WebUI Installer for Workstation is underway!
by Sumantro Mukherjee
Hey folks,
This week we will be testing the new Anaconda WebUI installer written with
React and Cockpit. This installer will be default for Workstation for now and
we would like to run through as many tests as possible from [0].
Note from developers/other likely scenarios are
a) Test the new mount point assignment UI and for this the most likely
use case will be that the user will create the partitioning manually
using blivet-gui (which can now be started from the WebUI interface)
and then switch to the mount point assignment and assign/map the
created devices to mount points
b) Test any system with multiple types of disks a combination (LVM and
RAID), and different bootloader configs.
[0] https://testdays.fedoraproject.org/events/165
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
8 months
Re: [Test Week] F39 Anaconda WebUI Installer for Workstation is underway!
by Sumantro Mukherjee
On Tue, Aug 29, 2023 at 7:48 AM Geoffrey Leach <geoffleach.gl(a)gmail.com> wrote:
>
> Hmmmm ....I guess I haven't been paying attention. Can someone point me
> at the spe for this?
>
> On Tue, 29 Aug 2023 07:31:28 +0530
> Sumantro Mukherjee <sumukher(a)redhat.com> wrote:
>
> > Hey folks,
> >
> > This week we will be testing the new Anaconda WebUI installer written
> > with React and Cockpit. This installer will be default for
> > Workstation for now and we would like to run through as many tests as
> > possible from [0]. Note from developers/other likely scenarios are
> > a) Test the new mount point assignment UI and for this the most likely
> > use case will be that the user will create the partitioning manually
> > using blivet-gui (which can now be started from the WebUI interface)
> > and then switch to the mount point assignment and assign/map the
> > created devices to mount points
> > b) Test any system with multiple types of disks a combination (LVM and
> > RAID), and different bootloader configs.
> >
> > [0] https://testdays.fedoraproject.org/events/165
> >
>
Hey Geoffrey,
spe? I would need some more context.
All of this started with this changeset
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
The test day wiki is
http://fedoraproject.org/wiki/Test_Day:2023-08-28_Anaconda_Web_UI
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
8 months
GNOME RDP port
by Alessio
On GNOME 45, the default remote desktop port is now 3390, while in the
past the "default" port was used. Correct?
The point is that now, using an RDP client you have to specify the port
unlike in the past.
Should we document this somewhere?
Ciao,
A.
8 months, 1 week
2023-08-21 @ 15:00 UTC - Fedora QA Meeting
by Adam Williamson
# Fedora Quality Assurance Meeting
# Date: 2023-08-21
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.libera.chat
Greetings testers! Once again it's been a bit of time since we last
met, sorry for that. Let's meet up on Monday!
If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 39 status, inc. anaconda webUI review
3. Flock report
4. Test Day / community event status
5. Open floor
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
8 months, 1 week
system-upgrade on RPi fails
by Alessio
Hello.
I don't remember if it has always been this way.
I was trying to upgrade from Fedora 38 to 39 on a Raspberry.
sudo dnf system-upgrade download --releasever=39
The point is that on the subsequent boot, following
dnf system-upgrade reboot
the operation fails because the signature verification fails, due to
the fact that the date/time of the RPi is incorrect. You know, each
time the RPi is rebooted, it lose the date/time.
So, has it always been this way and I don't remember that? Or in the
past, system-upgrade was performed after the clock was synchronized
with some source?
Thanks,
A.
8 months, 1 week
