F 21 Alpha itself works just fine for booting and rebooting, unfortunately
after updating all packages certain partitions fail to mount (usually home)
which in turn drops me into single user mode.
I am able to do a vgchange -ay and home will be detected and mount, but
doing a ctl-d or systemctl default at that point results in a frozen
There are a heap of updates since alpha so I can't say for sure which one
causes the issue. Looking at the journal on a failed boot shows
systemd-udevd core dumping multiple times. Unfortunately, given my workflow
at this point I don't have a copy of the logs for you folks.
A fresh install renders the same thing on update.
Anyone else experiencing this? Looking through bugzilla I couldn't find a
Lenovo t440p (UEFI)
Samsung 840 EVO SSD
Dual boot with windows
Reposted from <http://fedoramagazine.org/5tftw-2014-09-26/>.
Fedora is a big project, and it’s hard to follow it all. 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 September 18th, 2014:
Fedora 21 Alpha Release!
Of course, this week’s big news is the release of Fedora 21 Alpha — the
first formal test release on the way to an early-December final
release. This will be our first release with distinct Cloud, Server,
and Workstation products — a first phase of Fedora.next. Read the F21
Alpha release announcement, and download the flavor you’re interested
in (or launch the cloud image in EC2).
A gigantic thank you and congratulations to all of the Fedora
contributors who made this happen!
Shellshock and Fedora
And then, this is our *other* big news. By now, this has been
well-covered *everywhere*, but if you haven’t seen it yet, check out
articles tagged `shellshock` on Fedora Magazine to keep your system
If you’re curious, read my "Shellshock: How does it actually work?"
article, where I attempt to give a satisfying level of detail in a way
that anyone can understand. Also, the Red Hat security blog has a nice
post-incident FAQ, with a lot of other background and information, and
explains the reasoning behind the patch Red Hat developed (which is the
one we are using in Fedora).
You might also be interested Dan Walsh’s blog entry on how SELinux
helps contain this attack — it’s not perfect, but when an exploit is
in the wild, it’s important to have meaningful layers of protection.
And! I’ll be live on the Linux Action Show this Sunday, talking
about Shellshock and other things.
In Which Adam Fixes Everything
Fedora QA Community Monkey (no, really, that’s his title) Adam
Williamson apparently does not need to sleep, and in the midst of all of
the Shellshock fun, spent about 36 hours straight cleaning up some of
the documentation in the Fedora wiki around our release schedule and
process. Some of this is only of interest if you’re deeply involved in
Fedora development or QA, but if you’re following Fedora prereleases
(like the alpha!) — and possibly if you have been confused previously —
it’s all a lot better now, with more consistent names and documentation
that actually reflects reality. Take a look at
and about three dozen interlinked pages which are now all nicely
consistent and much more beautiful than they were before. This is a
great example of how "just do it!" works in wikis and open source in
general — some discussion on IRC and mailing lists, but no waiting to
act. Thanks to Adam for seeing a mess and making it better!
Flock (our big annual contributor conference) will be held in North
America next summer — but where? We have four bids, all in the United
* Salt Lake City, Utah
* Colorado Springs, Colorado
* Rochester, New York
* Cape Cod, Massachusetts
The Flock planning team is working on putting together a side-by-side
feature and cost comparison, and will soon be running a straw poll to
find the preferences of potential attendees.
Robyn on Distros and DevOps — and User Communication
Former Fedora Project Leader Robyn Bergeron has an interesting blog
post about "distros and silos, devops and open source". She talks about
several things (all worth reading), but one of the most interesting is
the suggestion she floats for a User Committee. What do you think?
Would a Fedora User Committee help improve our communication and break
Repost note: for the past couple of months, I've just been posting this
to the magazine and not reposting to mailing lists. The mailing list
posts weren't getting a lot of response. I'm trying it again this week,
though — let me know if it's useful to have it here. You can also
follow using the RSS feed at <http://fedoramagazine.org/tag/5tftw/feed/>.
Fedora Project Leader
I need to give up maintaining pdfbox. Hopefully someone else will pick
it up. Dependent packages are:
# repoquery --whatrequires pdfbox --source | sort -u
Let me know if you want to take it.
It currently FTBFS, but some patches have been posted:
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
[plymouth either not installed (Fedora, openSUSE), or disabled via cmdline
Adam Jackson wrote on 2014-09-24 12:28 (UCT-0400):
> On Tue, 2014-09-23 at 21:35 -0400, Felix Miata wrote:
>> with neither VGA= nor video= on cmdline, ttys are in a legacy 80x25
>> video mode that is broken. Trailing spaces are written to screen as high
>> ASCII characters both in bash and parts of mc. Some program output that
>> should be in text is also these junk characters.
> That's probably a bug. It might be in your kernel, it might be in your
> firmware. As a text mode issue it is sort of by definition not a
> graphics bug, so if anyone else feels like investigating it be my guest.
Reproduces using (non-KMS) gfxchips g400 (Dell BIOS) and Z7/Z9 (XG20
core)(sis in Xorg)(Phoenix CSS cME BIOS) in Rawhide (3.17rcx) & F21 (3.16.1-300).
Does not occur using (KMS) gfxchips from Intel (945G), ATI (rv200) or Nvidia
(nv11), nor with g400 or Z7/Z9 on Factory (3.16.2), nor with Z7/Z9 on
As there are no X drivers for the non-KMS gfxchips in the repos, would a bug
filed on this just go in the wontfix bin anyway? If not, what component
should it most likely go into? IOW, where's the bug?
On fresh boot, initial login on tty did thus:
# ll /
Output seemed OK until about the middle screen row, after reaching a
directory with a timestamp Dec 23 2008. Subsequent lines all ended with the
gibberish characters. On further study, I noticed that most lines output no
filename or dirname. The few shown did output correctly the filename characters.
just fills the screen past the bash prompt with "Ĝ" characters. Editing
cmdline, BS key also draws Ĝ. font= or not on cmdline makes no difference.
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
I'm currently like two months behind on devel@ - apologies if I've
missed anything relevant.
A discussion in #anaconda this morning made it clear that folks have
trouble following our full release cycle, and particularly the various
kinds of 'freeze' that exist.
So, there is a page named "Branch freeze policy":
which is marked as deprecated, and hasn't been linked to in the wiki
Releases/XX/Schedule pages since F18. However, I can't for the life of
me see any way in which it is in fact inaccurate, and it doesn't seem to
have been replaced with anything. So far as I can see it still
accurately describes the process we follow.
AFAICS, the "Branch freeze" kicks in at the point we enable Bodhi on the
Branched tree, which is usually a couple of weeks after forking it from
Rawhide. For instance, on the F21 schedule -
https://fedoraproject.org/wiki/Releases/21/Schedule - "Branch Fedora 21
from Rawhide" is listed on 2014-07-08. The first 'Fedora 21
updates-testing' email I have is dated 2014-08-28, so I'd say the
schedule should have had an extra row, "Branch Freeze", dated
2014-08-28. (The period between branching and enabling Bodhi was
unusually long for F21).
The name "Branch freeze" seems unfortunate to me, however, as it's not
really a freeze, it's more of a light cooling. I'd suggest we remove the
'deprecation' notice, update any details on the page which are no longer
correct if anyone can see any, and rename it. Ideas:
Branch update policy enforcement
anyone got anything better?
So, the second part of the process which is apparently causing trouble
is the "Change Deadlines". These, again, seem to be something of a
misnomer, because the Change Deadlines are the *actual* freezes. The
problem is exacerbated by the renaming of 'Features' to 'Changes'. If
you look again at the F21 schedule you'll see that it lists "Change
Proposals Submission Deadline", "Changes Freeze", some "milestone Change
Deadlines", and "Accepted Changes 100% Complete" - but those items are
referring to two entirely *different* things when they use the word
"Change". This is clearly unfortunate.
Again, I'd recommend a renaming here. If we call the "Branch freeze"
something else then we can simply call those points the "Alpha Freeze",
"Beta Freeze" and "Final Freeze", which are the terms used informally in
any case, and would line up with the "freeze exception policy" which
determines what stuff can break those freezes.
Along with the renaming I'd like to work over the documentation a bit so
all the relevant pages link up and sing from the same hymn sheet, but I
can actually do that right now, orthogonal to the renaming, without
really needing any review, so I'll just go do it. (I'll post a reply
explaining what I did in a bit).
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
-----BEGIN PGP SIGNED MESSAGE-----
I would like to inform everyone about changes I plan to do
in Fedora 20+ due to Bug 1097752 (Support for native PKCS#11
interface - needed by FreeIPA).
Currently there is a bind-pkcs11 package which includes
couple of utilities needed for working with PKCS#11.
- From the user feedback I got during the past year or so, utilities
from PKCS#11 didn't work much. I backported the native
PKCS#11 functionality from Bind 9.10 and plan to add/change
the following sub-packages:
- will contain special version of named (named-pkcs11) which
is compiled with the native PKCS#11 and doesn't use OpenSSL,
for crypto, but some HSM.
- libdns and libisc compiled with native PKCS#11 functionality.
These will be distributed as libdns-pkcs11 and libisc-pkcs11.
- development files for the native PKCS#11 versions of libisc
- will provide utilities previously provided by the bind-pkcs11
package. The update path will be solved as described in Packaging
guidelines. These utilities are compiled with native PKCS#11, too.
If this changes could break someone's setup, please let me know
so we can work on some solution. Otherwise I'll do the changes
some day next week.
Software Engineer - EMEA ENG Developer Experience
Red Hat Inc. http://cz.redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
One last thing before I sign off - I'm reliably informed the updates
shipped yesterday don't entirely resolve the bash security issues, so
more build(s) can be expected today. if people can stand ready to test
and karma them ASAP, that'd be just awesome. thanks!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list