Test Day:2010-09-07 Systemd
|Tue Sept 07, 2010||All day||#fedora-test-day (webirc)|
 What to test?
Today's installment of Fedora Test Day will focus on systemd, the new initialization system being introduced in Fedora 14.
 Who's available
The following cast of characters will be available testing, workarounds, bug fixes, and general discussion...
 What's needed to test
- An updated Fedora 23 pre-release, or the special live image (see below)
- Not-yet-published updates for systemd, initscripts, dbus, ConsoleKit and acpid (see below for details)
 How to test?
 Update your machine
If you're running Fedora 14, make sure you have all the current updates for it installed, using the update manager. If you want to try Rawhide, see the instructions on the Rawhide page on the various ways in which you can install or update to Rawhide. Or:
 Live image
 Live image
Optionally, you may download a non-destructive Fedora 23 live image for your architecture. Tips on using a live image are available at FedoraLiveCD.
This custom live image contains all the necessary updated packages. You will not be able to conduct the full range of tests using the live CD, but you can perform the tests that are possible, and confirm that it boots correctly on your system. You can also use it to install a Fedora 14 system to perform the full range of tests.
 Install additional updates
To provide the best test results, please install the following packages. They have not yet been accepted as official Fedora 14 updates, but they fix several known issues with systemd. If you test with or install from the custom live image linked to above, these updates will already be installed.
- acpid-2.0.5-2.1.fc14 - i686, x86_64
Follow each of these test cases:
 Test Results
If you have problems with any of the tests, report a bug to Bugzilla usually for the component systemd. If you are unsure about exactly how to file the report or what other information to include, just ask on IRC and we will help you. Once you have completed the tests, add your results to the Results table below, following the example results from the first line as a template. The first column should be your name with a link to your User page in the Wiki if you have one. For each test case, if your system worked correctly, simply enter the word PASS. If you had trouble, enter the word FAIL, with a footnote indicator, and put a link to the bug report in the References column (as in the example line). For tests you could not perform, enter a dash.
The rest passes without problem!
|| Some testing on F-14, some on rawhide. Seems to work ok, but there are some behavioral changes. |
|David Ramsey|||| |
system's smolt data
 Long comments
- Error line on poweroff:
Stopping rpcbind (via systemctl): /etc/init.d/killall: line 16: 1654 Terminated /etc/init.d/$subsys stopRHBZ #630915
- AD 12:
service netconsole startprints 'Starting netconsole (via systemctl): [OK]', but
systemctl status netconsoleshows '...exited, status 6/NOTCONFIGURED' and netconsole is really not loaded
- LiveUSB-32, Forcing runlevel 3 reported runlevel "unknown" (as reported by 'runlevel' command) RHBZ #630914 but later (after 'ps' and 'top' and 'telinit 5') reports runlevel 3 5. Shutdown, reboot and teleinit as expected.
- telinit fails to change runlevels properly (e.g. telinit 5 does not start X unless the system booted to runlevel 5 initially). RHBZ #627014
- "halt -p", "poweroff", and "shutdown -h" commands and their rebooting equivalents, when invoked in runlevel 5, appear to cause gdm to be restarted, rather than stopped. RHBZ #631160
- "halt" used to also shut down the system, does not do so any longer (I know this has been discussed, I'm specifically calling it out). Additionally, on current rawhide: (systemd-9-3.fc15.x86_64) the root filesystem always has busy inodes on shutdown and forces a replay of the journal on next boot, lvm2-monitor does not shutdown cleanly on halt, various log entries contain "init: Got invalid poll event on pipe." followed by e.g. "init: Unit sys-kernel-security.automount entered failed state.", and there are several "mount" errors when systemd re-execs itself to apparently try to handle the busy inodes situation.