Improving the offline updates user experience
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
== The Problem ==
It is very common for users to have systems with encrypted root
partitions (or even just /var and /etc). This may be due to a personal
concern for their data or a corporate policy mandating full-disk
encryption. Disk encryption requires a password (or other more
complicated credentials) be be presented just after the kernel is
booted and before the drives can be mounted and their data read.
With the current implementation of the offline updates in Fedora, this
leads to a very unpleasant user experience when updating. We offer two
ways to perform offline updates in the default user environment of
Fedora Workstation: "Install updates and reboot" or "Install updates
and shut down".
With "Install updates and reboot", the behavior is as follows:
1) The system shuts down and initiates an ACPI reboot.
2) The system presents the kernel boot menu and then starts the
updater kernel.
3) The system presents the user with a password prompt for the disk
encryption (possibly more than one, if the system is configured with
different passwords for different partitions).
4) The offline updates occur.
5) The system shuts down and initiates an ACPI reboot.
6) The system presents the kernel boot menu and then starts the
standard (possibly updated) kernel.
7) The system presents the user with a password prompt for the disk
encryption (possibly more than one, if the system is configured with
different passwords for different partitions).
8) The system completes booting.
During this experience, the user has been required to enter their disk
encryption password *twice*. The same is true for the "Install and
shut down" case, except that the two passwords are separated by some
actual wallclock time.
== Proposed Improvements ==
We could significantly improve this situation by allowing the system
to drop directly from the interactive system into the updater
environment without doing a full reboot or relaunching the kernel.
Lennart, would it be possible to set up a special systemd target for
performing updates that would essentially stop all processes except
for systemd and then apply the updates?
In an ideal world, it would then also be possible after update is
completed to restore operation to the standard boot targets of systemd
so that the system comes back up without having to perform a total
reboot. The exceptional case would of course be that in which either
the kernel, libc or systemd[1] needed to be updated, in which case a
reboot could be performed.
In this scenario, we can reduce the number of encrypted disk
challenges to at most a single one, and that only if absolutely
minimal plumbing packages saw an update.
I'd very much like to hear from the plumbers on this matter.
[1] I'm told that this might not be necessary; that systemd can
re-exec itself to pick up its own updates. That would reduce the scope
presumably to "only the kernel" forcing reboots.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlQTB1YACgkQeiVVYja6o6MvpgCeLbkWSgY5XGI4nJg3skjyu8v+
nQUAoIyvNHpJ8SRytPPKGZ3C8kZ560J9
=zZ+N
-----END PGP SIGNATURE-----
9 years, 5 months
Proposal for integration tests infrastructure
by Honza Horak
Fedora lacks integration testing (unit testing done during build is not
enough). Taskotron will be able to fill some gaps in the future, so
maintainers will be able to set-up various tasks after their component
is built. But even before this works we can benefit from having the
tests already available (and run them manually if needed).
Hereby, I'd like to get ideas and figure out answers for how and where
to keep the tests. A similar discussion already took place before, which
I'd like to continue in:
https://lists.fedoraproject.org/pipermail/devel/2014-January/193498.html
And some short discussion already took place here as well:
https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000...
Some high level requirements:
* tests will be written by maintainers or broader community, not a
dedicated team
* tests will be easy to run on anybody's computer (but might be
potentially destructive; some secure environment will not be part of tests)
* tests will be run automatically after related components get built
(probably by Taskotron)
Where to keep tests?
a/ in current dist-git for related components (problem with sharing
parts of code, problem where to keep tests related for more components)
b/ in separate git with similar functionality as dist-git (needs new
infrastructure, components are not directly connected with tests, won't
make mess in current dist-git)
c/ in current dist-git but as ordinary components (no new infrastructure
needed but components are not directly connected with tests)
How to deliver tests?
a/ just use them directly from git (we need to keep some metadata for
dependencies anyway)
b/ package them as RPMs (we can keep metadata there; e.g. Taskotron will
run only tests that have "Provides: ci-tests(mariadb)" after mariadb is
built; we also might automate packaging tests to RPMs)
Structure for tests?
a/ similar to what components use (branches for Fedora versions)
b/ only one branch
Test maintainers should be allowed to behave the same as package
maintainers do -- one likes keeping branches the same and uses "%if
%fedora" macros, someone else likes specs clean and rather maintain more
different branches) -- we won't find one structure that would fit all,
so allowing both ways seems better.
Which framework to use?
People have no time to learn new things, so we should let them to write
the tests in any language and just define some conventions how to run them.
Cheers,
Honza
9 years, 5 months
Multiple problems with multiple monitors
by Basil Mohamed Gohar
I've searched for bugs related to the specific problems I've been
having, and I've not been able to find anything that describes what I'm
seeing.
I have an HP EliteBook 840 that also comes with an UltraDock, to which
I've plugged-in two external monitors and I use in conjunction with the
built-in laptop display.
Issue #1: I use LUKS to encrypt my disk, and when I first start up the
computer, after choosing the kernel to boot into in GRUB, the GUI prompt
for the LUKS passphrase shows-up on the middle monitor, not the laptop's
built-in display. I don't mind this when I have multiple monitors
plugged-in, but when I boot-up without the external monitors, such as
when I'm unplugged from the UltraDock, I now get NO GUI prompt for the
LUKS passphrase. I can enter it, and I can see a text prompt if I hit
ESC. I suspect its attempting to display on the now phantom, unplugged
monitor. Note, it was never plugged-in during this cycle. The problem
is, I don't even know what's instructing LUKS or the GUI prompt to
display on any monitor, so I don't know where to go to debug this.
Issue #2: When I undock my laptop while logged-in, Gnome Shell just
crashes. When I redock after the laptop has been started when
unconnected, one of the two external monitors start-up (the one
connected by VGA), but not the one connected by a DisplayPort
connection. And, recently (but not when I first started using this
laptop with the dock, which was about a month ago), now when I start-up
with the laptop docked and both external monitors connected, both
external monitors will be active, but the built-in display will show
nothing. Gnome Shell reports the built-in display is active, but will
not display anything unless I deactivate it and reactivate it via the
settings "Displays" utility.
Issue #3: The monitor connected via DisplayPort display significant
tearing and delay on the upper-right half of the screen in the form of a
triangle taking-up half of the screen. Reading about displayport and
tearing issues, I guess the idea that these were resolved in the past. I
don't know if this is the same or something different.
I don't mean to use devel as a bug reporting venue, but I think these
issues are either related or I just don't know how to address them to
make significant progress to fixing them. Any guidance is more than
welcome. Thanks!
--
Libre Video
http://librevideo.org
9 years, 5 months
RE: Proposal for integration tests infrastructure
by John Dulaney
Some thoughts:
>> Where to keep tests? a/ in current dist-git for related components
>> (problem with sharing parts of code, problem where to keep tests
>> related for more components) b/ in separate git with similar
>> functionality as dist-git (needs new infrastructure, components are
>> not directly connected with tests, won't make mess in current
>> dist-git) c/ in current dist-git but as ordinary components (no new
>> infrastructure needed but components are not directly connected
>> with tests)
>>
>> How to deliver tests? a/ just use them directly from git (we need
>> to keep some metadata for dependencies anyway) b/ package them as
>> RPMs (we can keep metadata there; e.g. Taskotron will run only
>> tests that have "Provides: ci-tests(mariadb)" after mariadb is
>> built; we also might automate packaging tests to RPMs)
To answer both of these, the plan is to keep taskotron tasks in their own
git repo; currently this is at (0).
To run the tasks, taskotron sets up a disposable task client and then git
clones the task to be run. This solves the issue of delivery and allows
a continuous integration-like solution.
>> Structure for tests? a/ similar to what components use (branches
>> for Fedora versions) b/ only one branch Test maintainers should be
>> allowed to behave the same as package maintainers do -- one likes
>> keeping branches the same and uses "%if %fedora" macros, someone
>> else likes specs clean and rather maintain more different branches)
>> -- we won't find one structure that would fit all, so allowing both
>> ways seems better.
This is something we'll need to figure out, but, I suspect git branches will
be involved.
>> Which framework to use? People have no time to learn new things, so
>> we should let them to write the tests in any language and just
>> define some conventions how to run them.
You'll need to at least define the task in a yaml file, and output will need to
be TAP. The example task is at (1).
> TAP (Test Anything Protocol) FTW. It really makes sense when you're
> trying to combine tests from multiple different languages, testing
> frameworks, etc.
>
> Stef
>
Indeed, which is why we settled on it.
John.
(0) https://bitbucket.org/fedoraqa
(1) https://bitbucket.org/fedoraqa/task-rpmlint
9 years, 5 months
possibly problem with rawhide (systemd-217?): "Found ordering cycle on basic.target/start"
by Matthew Miller
Updated my rawhide system. Now it doesn't boot cleanly. Will try to
figure out the details in the morning (long week!), but "Found ordering
cycle on basic.target/start" seems to be part of it, and I wanted to
see if anyone else is hitting this (and possibly caution care on
upgrading right now).
Note "Breaking ordering cycle by deleting job sysinit.target/start".
The system partially comes up, but there is a _lot_ of failure-to-work
afterwards - probably related.
Not positive it was the systemd update, or possibly some other unit
file, or something else altogether. Will dig deeper after some sleep.
:)
-- Logs begin at Mon 2014-06-02 17:02:01 EDT, end at Thu 2014-10-30 21:40:54 EDT. --
Oct 30 21:39:37 ubik.home.mkmiller.org systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Cannot add dependency job for unit ksm.service, ignoring: Unit ksm.service failed to load: No such file or directory.
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Cannot add dependency job for unit ksmtuned.service, ignoring: Unit ksmtuned.service failed to load: No such file or directory.
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Cannot add dependency job for unit systemd-readahead-collect.service, ignoring: Unit systemd-readahead-collect.service failed to load: No such file or directory.
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Cannot add dependency job for unit systemd-readahead-replay.service, ignoring: Unit systemd-readahead-replay.service failed to load: No such file or directory.
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job systemd-update-utmp.service/verify-active
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Job systemd-update-utmp.service/verify-active deleted to break ordering cycle starting with basic.target/start
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job auditd.service/start
Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Job auditd.service/start deleted to break ordering cycle starting with basic.target/start
Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start
Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job sysinit.target/start
Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Job sysinit.target/start deleted to break ordering cycle starting with basic.target/start
Oct 30 21:39:54 ubik.home.mkmiller.org systemd[1]: iptables.service: main process exited, code=exited, status=1/FAILURE
Oct 30 21:39:54 ubik.home.mkmiller.org systemd[1]: Failed to start IPv4 firewall with iptables.
Oct 30 21:39:54 ubik.home.mkmiller.org systemd[1]: Unit iptables.service entered failed state.
Oct 30 21:39:54 ubik.home.mkmiller.org systemd[1]: iptables.service failed.
Oct 30 21:39:56 ubik.home.mkmiller.org systemd[1]: Configuration file /usr/lib/systemd/system/wpa_supplicant.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Oct 30 21:40:01 ubik.home.mkmiller.org systemd[1]: Unit squid.service cannot be reloaded because it is inactive.
Oct 30 21:40:01 ubik.home.mkmiller.org systemd[1]: Unit iscsi.service cannot be reloaded because it is inactive.
Oct 30 21:40:04 ubik.home.mkmiller.org systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
Oct 30 21:40:04 ubik.home.mkmiller.org systemd[1]: Failed to start Docker Application Container Engine.
Oct 30 21:40:04 ubik.home.mkmiller.org systemd[1]: Unit docker.service entered failed state.
Oct 30 21:40:04 ubik.home.mkmiller.org systemd[1]: docker.service failed.
Oct 30 21:40:11 ubik.home.mkmiller.org systemd[1]: Unit iscsi.service cannot be reloaded because it is inactive.
Oct 30 21:40:11 ubik.home.mkmiller.org systemd[1]: Unit squid.service cannot be reloaded because it is inactive.
Oct 30 21:40:11 ubik.home.mkmiller.org systemd[1]: Unit iscsi.service cannot be reloaded because it is inactive.
Oct 30 21:40:11 ubik.home.mkmiller.org systemd[1]: Unit squid.service cannot be reloaded because it is inactive.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9 years, 5 months
5tFTW: Fedora Beta, Council & Elections, Strategic Planning, Outreach Committee, and FUDCon Reports (2014-10-31)
by Matthew Miller
Reposted from <http://fedoramagazine.org/5tftw-2014-10-31/>.
Fedora is a big project, and it’s hard to keep up with everything that
goes on. This series highlights interesting happenings in five
different areas every week. It isn’t comprehensive news coverage — just
quick summaries with links to each. Here are the five things for
October 31st, 2014:
Fedora Beta due Next Week
-------------------------
I’ll keep this item short: Fedora 21 Beta is Go, and will be available
Tuesday, November 4th. Next week, we’ll do an all-beta 5tFTW.
This puts the final release target at December 9th. As always, these
targets are more like guidelines than deadlines, but as we are verging
on the holiday season we are going to make extra effort to avoid
further adjustment.
* https://lists.fedoraproject.org/pipermail/devel-announce/2014-October/001...
* http://fedoraproject.org/wiki/Releases/21/Schedule
* https://www.youtube.com/watch?v=6GMkuPiIZ2k
Council Update and Elections
----------------------------
The Fedora Council — our new top-level leadership body — includes
two of seats appointed by elected committees and two seats elected by
the Fedora Contributor community at large. The appointed seats covering
Fedora Engineering and Fedora Outreach (more on that below) are now
filled, by Josh Boyer and Christoph Wickert respectively.
(Congratulations and thank you to Josh and Christoph!) Now it’s time to
fill the elected seats — see the schedule announcement for details.
Quick summary: nomination period next week; “campaign” week after that,
and finally a week for community voting after that. The Council will
take over from the Fedora Project Board when this is complete.
* https://fedoraproject.org/wiki/Council
* https://lists.fedoraproject.org/pipermail/announce/2014-October/003236.html
* http://fedoraproject.org/wiki/Board
Fedora Objectives
-----------------
If you haven’t seen it already, I would like everyone who cares about
what Fedora does and where the project is going to take a look at my
recent Fedora Magazine article about Fedora objectives — why, how, and
eventually what.
As I mentioned a few weeks ago, high-level strategy discussions can
feel disconnected and pointless. This is a process by which we can
actually connect them into what we’re doing in a meaningful way, and by
doing so increase the impact of our actions. Take a look, and take part
in upcoming discussions on the public board discuss list.
* http://fedoramagazine.org/lets-talk-about-fedora-project-objectives/
* https://lists.fedoraproject.org/pipermail/announce/2014-October/003235.html
* https://admin.fedoraproject.org/mailman/listinfo/board-discuss
Fedora Outreach Steering Committee?
-----------------------------------
Fedora has long had two high-level elected steering committees, FESCo,
the Fedora Engineering Steering Committee, and FAmSCo, the Fedora
Ambassadors Steering Committee. The meritocratic representative
positions on the Council are appointed by these committees.
This is straightforward for the relatively wide-reaching FESCo, but the
seat appointed by FAmSCo is actually intended to represent a much
broader section of the project than ambassadors alone. This lead to a
discussion about creating a new Outreach steering committee, tying
together and coordinating efforts of Ambassadors, Marketing,
Brand/Design, some aspects of the product Working Groups, Docs, various
support channels — overall, all the parts of the project which are
outward looking rather than focused on building the distro and
infrastructure.
Since FAmSCo has successfully delegated a lot of responsibility to
regional ambassadors committees, and since the new Council will work on
the high level community budget, this new body would make FAmSCo
obsolete — so we’re not just piling on yet more committees, here!
If you’re interested, join the new Fedora Outreach mailing list and
let’s start building this!
* https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee
* http://fedoraproject.org/wiki/Fedora_Ambassadors_Steering_Committee
* https://lists.fedoraproject.org/mailman/listinfo/outreach
Reports from FUDCon Managua
---------------------------
As promised last week, some updates from FUDCon Managua, our
user-and-developer conference held this year in Nicaragua. Check out
reports from:
- Alejandro Prez (Lots of pictures and people!)
- William Moreno Reyes (In Spanish *and* English!)
- Rino Rondan (All in Spanish, although the photographs are
multilingual)
- Robert Mayr (Just “day 0″ so far; check back for more updates
from robyduck!)
- Kiara Navarro (In Spanish with a lot of details, and again a lot
of photos — and also, there’s part 2 and part 3)
- Abdel G. Martínez L. (Particularly, highlights positive impact
of the event on project contribution — nice!)
- Daniel Bruno (In English)
Thanks to everyone who made these reports, and thanks to the FUDCon
LATAM organizers, and congratulations to everyone on yet another
successful Fedora Premier Event!
* https://fedoraproject.org/wiki/FUDCon:Managua_2014
* http://msvslinux1.blogspot.com/2014/10/fudcon-managua-2014.html
* http://otroblogdegnu-linux.blogspot.com/2014/10/fudcon-managua.html
* http://www.itrestauracion.com.ar/?p=2002
* http://robyduck.fedoraonline.it/?p=12
* http://panamahitek.com/fedora-users-developers-conference-managua-nicarag...
* http://panamahitek.com/fudcon-fedora-users-developers-conference-managua-...
* http://panamahitek.com/fudcon-fedora-users-developers-conference-managua-...
* http://www.abdelmartinez.com/2014/10/fudcon-managua-final-report.html
* http://dbruno.org/fudcon-managua/
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Fedora Project Leader mattdm(a)fedoraproject.org <http://fedoraproject.org/>
9 years, 5 months
Self Introduction: Alexander Ploumistos
by Alexander Ploumistos
Hello everyone,
I've decided to join the package maintainers and I would like to introduce
myself.
I have been a linux user since 2001 and a Red Hat/Fedora user since 2003.
My main systems run on Fedora (of course) and Gentoo. I have a background
in chemistry, particularly molecular modeling and for the past decade I
have been working as a "general purpose IT guy" and part-time
web-developer. I build systems, I design and deploy SOHO networks, I do
some light pen-testing and provide tech support. I have experience coding
in Fortran, Perl, PHP, Python, shell scripts, (X)HTML/CSS, I have worked
with several CMSs -though in the past few years mostly with Joomla- and I
have built some customized versions of embedded distros such as OpenWRT and
other device-related software. During the past decade I have done
alpha/beta/QA testing for a number of projects (most of them FLOSS) and I
have provided translations and bug reports for others.
I would like to give back something more than bug reports and translations
and also improve my coding skills along the way. I have a couple of
programs that I would like to maintain, but for the moment there remains an
issue with their licenses.
There is also a patched version of libatasmart, that takes care of an issue
with several older Western Digital hard drives, that is awaiting review (
https://bugzilla.redhat.com/show_bug.cgi?id=1157150) and I would really
appreciate it if someone could take the time to look into that.
Best Regards
Alexander
9 years, 5 months
RHEL 6.6 MPI mess
by Dave Love
The undocumented openmpi and mpich updates in RHEL6.6 have broken binary
compatibility and seem to be provoking general rebuilds of things in
EPEL. While that may be OK for things that are packaged in EPEL, it at
best doesn't help with our HPC users' locally-built programs or
local/copr-published rpms (especially if the rebuilds involve their own
ABIs incompatibilities, like scalapack currently in testing).
It seems to me that the best approach, assuming Red Hat won't address
the issue, is to supply compatibility packages in EPEL if that will
work. I haven't had a chance to try, but I'll probably have to make
something work eventually for openmpi, and presumably there are plenty
of people in a similar situation. The updates are blocked by the
dependencies of many installed packages here, but it will be
increasingly awkward with packages that can't be updated without
rebuilds.
Has anyone tried that tack already, or is it clear it can't work for
some reason?
9 years, 5 months
