Hey all, hate to be a downer but we might have a bug in the installer
Just installed F23 Workstation via RC10. Encryption with btrfs across two drives. Intel graphics (Lenovo t450s if anyone has access to one). Installed the system, rebooted into system. I get met with a black screen and the text
"Error: Can't find the command: /dev/mapper/luks-0be
Press any key to continue"
Boot continues forward without any action on users behalf, despite what is displayed. Plymouth never loads, text based loading. I got prompted for encryption passphrase, supply it, boot continues.
I get "A start job is running for dev-mapper-luks\(random characters).device ( (timer counter) / no limit)"
And then boot stalls with the counter incrementing. Will try a reinstall later tonight, but before I do that does anyone need / want debug info? Adam?
--Eric
Michael Catanzaro wrote:
> My recommendation is the opposite of what Kevin would say, though. I'd
> like to see a third party responsible for giving final approval on all
> updates, charged with reducing the size of the updates pipe dramatically.
> Maintainers should not have final say on updates except in the event of a
> serious regression (in which case we need a revert button to skip
> updates-testing).
No thanks! If I wanted a distribution with such a strict control on updates,
I'd use RHEL/CentOS, not Fedora! The fact that bugs actually get fixed in
Fedora (whereas in conservative distributions, they often tell you to wait
for the next release that comes months to years later) and that we even get
new improved versions of applications is a huge advantage of Fedora, and
also part of what Fedora is about (see "First"). Throwing it away would be a
very bad idea.
I actually think we need a MORE update-friendly policy, where we recommend
always pushing new versions unless there is a good reason not to. (The
current policies are written the other way round, they recommend NOT pushing
new feature releases unless there is a good reason to. I have been
complaining about that right from the day it was written down.)
> An alternative we've been throwing around in the Workstation group is
> service packs (or "update packs") -- all non-security updates get bundled
> together, QAed, and released every 4-8 weeks. If you want to get your
> update out faster than that, you need a CVE or a special exception.
All that this accomplishes is delaying much needed fixes, it doesn't really
solve any problem. It just creates new ones, such as dumping a huge set of
updates on the user all at once, leading to bandwidth bottlenecks, and a
higher risk of breakage on the flag days.
> Then we need to have separate release cycles for each product, since I
> don't want Workstation blocked indefinitely on everything
> Cloud/Server/KDE want to fix, and presumably those groups don't want to
> block on us... it's frankly annoying to me that we risk blocking
> Workstation on such issues, but it's a compromise we need to make to
> ensure the other releases are good. (And that vice-versa when the other
> releases get blocked on Workstation issues.) As long as we have four
> separate releases on the same cycle, it makes sense that QA gets final
> say.
This egoistical attitude is what is preventing us from shipping quality
releases. The sky is not going to fall if your product/edition/spin gets
released a couple weeks later. And with my proposed change to the release
policy (slip = unfreeze, sync all updates, refreeze), you could also use the
time to get fixes/improvements in that would have otherwise missed the
release.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
