Testing request: gdm-on-Wayland on hybrid graphics laptops (esp. Macbooks)
by Adam Williamson
Hi folks!
We have a somewhat-worrying proposed blocker for F22:
https://bugzilla.redhat.com/show_bug.cgi?id=1218787
it appears that after a successful installation of Workstation on the
affected system, GDM-on-Wayland fails to start correctly but also does
not fall through (as it should) to GDM-on-X, leaving the user with a
black screen and no obvious way to proceed. This is obviously a bad
bug, but so far it has only been observed on one test system (a Macbook
Pro 8,2) by one tester. A few other testers have tried to reproduce on
other hybrid graphics systems, but have not been able to.
It would be very helpful to get some more data here. If anyone has a
hybrid graphics laptop and can spare some space (or perhaps attach an
external drive) for a test F22 install, can you please try installing
F22 Workstation TC3 and creating a user:
https://dl.fedoraproject.org/pub/alt/stage/22_TC3/Workstation/x86_64/iso/...
Live-Workstation-x86_64-22-TC3.iso
then boot the installed system, and see if GDM appears correctly?
Thanks.
Note there is a different bug which causes GDM-on-Wayland to flicker on
some hardware:
https://bugzilla.redhat.com/show_bug.cgi?id=1218688
that's something different, and is a bit further along in the
diagnosis/fix process, so we probably don't need further reports of
that one (though once a fix arrives, it'd be good to have folks test
it).
If you find you seem to be affected by the bug, please add your details
to the report. If you test and find you're *not* affected by the bug -
you see GDM properly - please reply to one of the mailing lists, so we
can get some idea of the proportions of affected vs. non-affected
testers. Thanks a lot for your help, folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 11 months
should we always install updates by default at each shut down?
by Kalev Lember
Hi all,
kparal pointed out on IRC today that in F22, gnome-shell's shutdown
dialog has the "Install pending updates" check box always checked. I
knew that we hadn't deliberately changed the default, so I did some digging.
It turned out to be a fallout from
https://github.com/hughsie/PackageKit/commit/0a7b6d67b98cd06cabe03176c02d...
that regressed the PackageKit DBus API that gnome-shell uses, basically
flipping the default from "do not install updates by default" to "reboot
and install updates".
sgallagh asked me to seek guidance on the list here: Is it something
that we should fix before the F22 release and flip the default back so
that when someone hurriedly clicks through the shut down dialog, they
don't accidentally go into a 15-minute offline update applying mode?
--
Thanks,
Kalev
8 years, 11 months
Re: Fixing express install for F23
by Zeeshan Ali (Khattak)
Hi Paul,
Thanks for bringing this up.
> One way to fix that would be to bring them back -- essentially go back
> to producing the images we offered before. That doesn't mean we need
> to advertise them on the website, though.
I think we do need to advertise them. Otherwise I don't see how else
are users supposed to find them. If we only advertise live media for
workstation, most users will simply download and try that and they'd
be annoyed by lack of express installation option for an OS on which
they are likely using Boxes.
Besides, I really don't see a good use case for not advertising these
media. As I pointed out to Christian yesterday, we have plenty of free
space on the right side here for just one more ISO link:
https://getfedora.org/en_GB/workstation/prerelease/
in comparison the server's download page looks more complete:
https://getfedora.org/en_GB/server/prerelease/
> What are the other alternatives for fixing?
As you can see on the discussion on the bug you linked in your mail, I
was told that it'd be good if Boxes/libosinfo could support express
install through netiso. I've spend quite a lot of hours getting that
to work[1]. The final set of patches that will actually make it work
are pending review on libosinfo list. However we still have some
issues that I can't fix on my end:
1. There is still no plan to advertise an F22 workstation or generic
netinstaller.
2. Live media (that is advertised) does not support kickstar AFAIKt:
https://bugzilla.redhat.com/show_bug.cgi?id=947376 . This isn't really
an issue if #1 is resolved.
--
Regards,
Zeeshan Ali (Khattak)
________________________________________
Befriend GNOME: http://www.gnome.org/friends/
[1] That included adding new mechanism in libosinfo to identify media
through volume-size since we won't even ensure unique volume IDs on
every ISO, a standard good practice even followed by certain big
proprietary companies famous for not following standards (Yes, I'm
ranting but I've been very patient about this until now).
8 years, 11 months
The “Windows Just Works” BIG fallacy
by Diogo Campos
Hi. Yes, again.
In this e-mail I just want to share a tiny bit of my personal
experience with people and computers and operating systems. It applies
to Windows XP and, especially, Windows 7. I don't know about Windows 8;
haven't used; Nor OS X.
FIRST THINGS FIRST:
Normal people don't know how to install Windows. Period. Unless there
is hardware coming with Fedora pre-installed, don't even dream about
“compete with” or “compare” a pre-installed Windows with a
Fedora that you have do download(!), boot(!) and install.
Otherwise, the best you can try is to create a DAMN EASY installer and
pray. And by “damn easy” I'm talking about a screen to select the
language (or detect it automatically, somehow, and skip this step) and
another screen with two big buttons saying “Erase everything and
Install Fedora ” and “Install Fedora alongside existing OS and
data”. No partitioning, ever (or, at least, let it hidden behind a
tiny something); choose a filesystem, choose a layout, and make it work
(great) on every workstation's disk scenarios out there. Prefer to
expose the other needed steps (initial setup) after the system is
already on the disk, so the “adventurer”, if scared, can't give up
anymore.
In another words: “Install Fedora” should be compared to “Install
Windows”; “Pre-installed Windows” should be compared to
“Pre-installed Fedora”.
Also, really important, is to perceive that “someone installed
Windows/Fedora on my computer” is way more common that “I installed
Windows/Fedora on my computer”.
THE FALLACY:
Respecting the previous reasoning, never compare “customized
Windows” with “stock Fedora”. So, below, I will compare “stock
Windows” with “stock Fedora” (by “stock” I mean freshly
installed from a official media; by “customized” I mean “stock”
plus additional external work from someone - be individual, company,
vendor, etc).
# Codecs = MP3, AAC, H.264, H.265, Vorbis, Opus, VP8, VP9.
Windows: Yes, Yes, Yes, Yes, No, No, No, No.
Fedora: No, No, No, No, Yes, Yes, Yes,Yes.
Conclusion: analyzing the 8 (4 audio, 4 video) current big codecs on
the market, we have a tie! Is also worth noting that installing
additional codecs on Windows is of a equivalent pain that on Fedora.
# Office Stuff = xls(x), doc(x), ppt(x), ods, odt, odp.
Windows: No, No, No, No, No, No.
Fedora: Yes, Yes, Yes, Yes, Yes, Yes.
Conclusion: in (Microsoft) Windows, even to open files from another
Microsoft product (Office), you can't without additional work from you
(or someone else).
# Miscellaneous = PDF, torrent, common archives.
Windows: No(!), No, No.
Fedora: Yes, Yes(?), Yes (except RAR, for no reason).
Conclusion: WTF Windows? No PDF?!
# Graphic Cards = Intel, AMD, Nvidia.
Windows: No, No, No.
Fedora: Yes, Yes, Yes.
Conclusion: Oh, boy! Windows without video drivers is pure garbage! You
have to, at minimum, select to install the driver on Windows Update to
have 2D (and 3D) acceleration! Sometimes even to have the correct
resolution! On other hand, Fedora comes with all these preinstalled!
Yay!
# Other Hardware (drivers).
Windows: maybe.
Fedora: maybe.
Conclusion: have luck, or have fun looking for drivers. On both systems.
FINAL THOUGHTS:
Fedora isn't the perfect OS. But Windows also isn't. A bunch of reasons
in favor of Windows aren't technical merits. Maybe commercial, or
social; but not technical.
Fedora can do better, sure. And it will. Especially if it doesn't fall
in such misconceptions.
This also highlight the importance of the “pre-installed” (or
“just works”) concept. Be OSes, apps, codecs, drivers, or whatever.
As I showed to you, Windows without the “pre-installed” concept,
simply doesn't shine at all. So, Fedora have to keep this always in
mind: normal people don't know how to “install” things.
I don't expect this to be agreed or disagreed. I just wanted to share a
bit of my experience on the role of “IT guy” that I do to some
normal people. Hope it helps, somewhat. Thanks.
8 years, 11 months
Re: The “Windows Just Works” BIG fallacy
by Chris Murphy
re: codecs. So I had this experience the other day, mp4, and totem (Videos)
gives me some message about how some codec plugins are missing. dnf search
doesn't find them, adding RPM fusion and searching doesn't find them, I do
google searches and I run into the Internet Doesn't Work (TM), or more
specifically Google Search sucks because it doesn't present relevant
results in the first two pages. So I gave up and booted OS X.
re: document formats. I think it's a big pro to point out LibreOffice is
included and provides both Office document format support, and *easily*
enables the user to get out of that b.s. dependency. Closed document
formats really piss me off, much more than closed proprietary codecs. Yay
Document Liberation Project!
re: Windows vs Fedora installation. First there are two kinds of Windows
installations:
-- official media from Microsoft offers a very straightforward installer
that starts out with two options Upgrade and Custom. Neither suggests new
installation, so that's confusing but there are only two paths you pick on
and get it wrong and you pick the other option next time - not difficult.
It's also uncommon, because this method is designed mainly for upgrades,
not new installations.
-- OEM recovery partition. In Windows 8 the options are reset (obliterate
all data and reinstall the OS), and refresh (keep user data, but revert to
a clean unupdated OS and new settings). This is very similar to how mobile
devices reset. And similar to the systemd folks' idea of stateless systems.
And the direction I think installs and resets on Fedora ought to go in,
perhaps with a couple points of additional granularity.
OS X's installer is point and shoot, it offers essentially no options.
Apple and Microsoft don't spend squat on their installers. They're both
largely unchanged in over a decade. I've never run into a bug with either
of them. User confusion is minimized by the fact there are two or zero
options. They definitely never ever crash. Anaconda is just a pile of
feature sprawl and it's completely normal and understandable something that
complicated is going to have x% of presentable bugs and regressions - and
it does. Three years after newui, it still dominates blocker bugs. I
consider it a misallocation of resources, but lovely that life is, it's not
my decision or I'd rip out all of custom partitioning and marry it with
blivet-gui. [1]
re: graphics cards. This is terrible on Linux. It's not Fedora's fault.
Regressions, dual-GPU suckage, crap power management, on and on. It's just
awful, and I don't use Fedora when I'm on the road because of this - the
battery life is just unworkable. OS X has completely seamless integrated
and discrete graphics switching totally figured out, for years now. Of
course, they cheat, controlling drivers and hardware, and sign all the
super secret NDAs to have this functionality (because of course the world
would end fucking tomorrow if anyone knew the super secret shit).
[1]
My idea installation scenario for Fedora Workstation in another dimension,
is live media based on a Btrfs seed device, the user boots the media, and a
minimal UI helps them add a drive (partition) and configure some things,
including G-I-S starting, and then the system is usable. Behind the scenes,
the defined drive is added to the seed device, the seed device is removed,
all data on the live media is migrated to the user defined device and then
the live media is ejectable. No reboot required. Between ostree, or revised
offline updates atomically updating Btrfs snapshots, or Btrfs send/receive,
both the double boot of current offline updates as well as even any
compulsory reboot can be eliminated.
--
Chris Murphy
8 years, 11 months
Tweak Tool in Workstation?
by Paul W. Frields
Re: <https://bugzilla.redhat.com/show_bug.cgi?id=1220007>
There seem to be a bunch of users asking for inclusion of the Tweak
Tool in Workstation.
On the one hand, I'm not sure this is coming from a solid use case
perspective, beyond "I like to fiddle more settings in the GUI than
the standard GNOME Settings allow." It seems to me that if someone
knows what they want to tweak at that level, it would follow they're
capable of installing a piece of software for this.
On the other hand, this may be an opportunity to gather useful
information on tweaks to GNOME. It would be nice not to close the BZ
bug peremptorily. We should consider the request thoughtfully in the
context of Workstation, and if possible, see what information we can
glean from the reporters or interested parties, and see what action is
worth taking.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
8 years, 11 months
LVM in default filesystem layout
by Chris Murphy
This is a consolidated post, responding to multiple parties.
Pete Travis lists at petetravis.com Tue May 5 15:45:11 UTC 2015
> I've seen people get themselves into tricky partitioning layout situations
> - especially on non-GPT systems - and the flexibility of LVM made it
> possible for them to install Fedora. Sometimes they did it to themselves,
> sometimes it's from the OEM. I suspect with admittedly no hard data that
> LVM as default transparently handled many, many situations where without
> LVM, relatively complex manual partitioning would be required.
>
For any preexisting 3 primary partition layout, the remaining MBR partition
can become an extended partition, and Anaconda/GRUB can (and do) use only
logical partitions. For capturing non-contiguous partitions and presenting
them as one volume, either LVM or Btrfs would be needed.
People get themselves into tricky partitioning layouts because Linux
installers are explicitly designed let them do crazy things. This doesn't
happen on Windows, OS X or mobile devices. It's one size fits all, you get
what you get, no discussion.
Yet despite the complexity of the installer's custom partitioning, it can't
delete either LVM VG's or Btrfs volumes, instead this only happens once the
user manually deletes all LVs or subvolumes first; and it requires the user
manually create required partitions on UEFI. It's a task and knowledge not
required for BIOS hardware for all of Fedora's history, and for no benefit.
And yet it's not a bug. [6]
As far as I know this is still a bug, it basically breaks boot of any prior
OS using LVM because its LVs aren't made active during Fedora installation,
therefore boot entries aren't created for it.
Anaconda should run grub2-mkconfig when LVM devices are active
https://bugzilla.redhat.com/show_bug.cgi?id=825236
*Josh Boyer* jwboyer at fedoraproject.org
<desktop%40lists.fedoraproject.org?Subject=Re:%20Re%3A%20LVM%20in%20default%20filesystem%20layout&In-Reply-To=%3CCA%2B5PVA66dJ-KXe7k9SWNSgxEM7%2B2Pe8eOhVZQDFJTkhWNog8cA%40mail.gmail.com%3E>*Tue
May 5 13:32:50 UTC 2015*
> And it's a great example of why we don't immediately default to using
> something shiny and new just because it exists. Btrfs is neither
> shiny or new at this point, and we look at it every release and
> discuss it with upstream and it still isn't ready to be default.
>
More correctly these days, Fedora isn't ready for Btrfs. Even if Btrfs were
as stable as ext4 Fedora couldn't use it by default right now.
The installer still has problems dealing with it [1], and installer team
expects Btrfs development to be slim to none in the near future [2]. Grubby
still doesn't support /boot on Btrfs [3]. For any other file system those
would be blockers. Fedora release criteria considers Btrfs equal, without
exceptions, to other file systems, but in practice at blocker reviews
pretty much anything Btrfs gets a hand waive.
GNOME Disks doesn't support resize, snapshots, subvolume creation or
deletion, gnome-shell gets confused with multiple disk Btrfs when mounting
and umounting, and understanding volume size [4]. But openSUSE ships GNOME
with Btrfs by default, so obviously these bugs aren't show stoppers, but
still no bueno.
None of these are Btrfs kernel code or btrfs-progs related. The fact is,
Btrfs is not a priority on Fedora, maybe not even of tertiary importance to
either Fedora or Red Hat who have a pile of ext4, XFS, and LVM developers
but no Btrfs developers. So to properly pin the tail on this donkey, it's
at least as much Fedora's non-readiness and disinterest in Btrfs right now.
Other things to consider: ext4 on LVM is not well suited for eventual
conversion to Btrfs. It can be done, it should work, if it doesn't it's a
bug. But it just adds complexity for no good reason. Presently (and I'll
argue properly) the installer doesn't permit LVM + Btrfs. There's an open
question on backups and Btrfs volumes especially in the context of
snapshots. We could use a tool that leverages btrfs send/receive so
everything can be backed up, not just mounted subvolumes. The LVM and file
system question opens up a bunch of related things, and I think they all
need an integrated big picture approach rather than it just being a list of
LVM pros/cons being used to arrive at a decision.
*Stephen Gallagher* sgallagh at redhat.com
<desktop%40lists.fedoraproject.org?Subject=Re:%20Re%3A%20LVM%20in%20default%20filesystem%20layout&In-Reply-To=%3C1000897174.11637103.1430859296013.JavaMail.zimbra%40redhat.com%3E>*Tue
May 5 20:54:56 UTC 2015*
> This should probably be its own thread, but I'll note that the current
> state of encryption on Workstation is less than ideal (speaking as someone
> using it). Offline updates with encrypted partitions means re-entering the
> password twice; once to enter the offline-update mode and once to boot
> again afterwards. This is a bigger inconvenience than it sounds.
>
Offline updates requiring two reboots is asinine. Encryption by default
just makes it more obvious. Windows likes to do these double reboots on
updates from time to time too, so it's not completely foreign. But for the
most part they quit the user session, do updates, and reboot once. That's
what happens on OS X also.
To do encryption by default, there needs to be a way for
gnome-control-center>users>change password to also reset the KEK in LUKS,
as well as to add keys when users are added. Right now, LUKS supports 8 key
slots, which may be a problem for encryption by default. Otherwise I
support the idea of encryption by default. [5]
Chris Murphy
[1]
Can't resize btrfs
https://bugzilla.redhat.com/show_bug.cgi?id=962143
Custom partitioning can't delete Btrfs volumes (manual full teardown of
each subvolume must be done by the user)
https://bugzilla.redhat.com/show_bug.cgi?id=1185117
[2]
https://bugzilla.redhat.com/show_bug.cgi?id=585525#c5
[3] This single bug has had numerous side effect bugs related to kernel
upgrades failing to boot, crashes due to the lack of an initramfs entry in
the grub.cfg, install failures. It goes back to 2012, is 102 messages long,
no sane person will click on this link.
https://bugzilla.redhat.com/show_bug.cgi?id=864198
[4]
https://bugzilla.gnome.org/show_bug.cgi?id=746769
https://bugzilla.gnome.org/show_bug.cgi?id=710156
https://bugzilla.gnome.org/show_bug.cgi?id=708786
[5] It's a drag there's no open source UEFI driver to enable FDE OPAL 2.0
support. Many SSDs (I think now all Samsung SSDs) come with OPAL support
and already always encrypt the drive, but it's always unlocked by default
so it appears to be unencrypted.
[6]
https://bugzilla.redhat.com/show_bug.cgi?id=1022316
--
Chris Murphy
8 years, 11 months
F22 blocker/freeze exception review: on-list? in-bug? special meeting?
by Adam Williamson
Hi, folks! We're now frozen for F22 Final, but a pile of blocker and
FE nominations arrived after the review meeting, several with updates
attached. It would be good to get these reviewed before next week.
Especially of note, we have an FE request for
https://bugzilla.redhat.com/show_bug.cgi?id=1211015 which would
necessitate pulling in the KDE Frameworks 5.10.0 release:
https://admin.fedoraproject.org/updates/kf5-plasma-5.10.0-2.fc22
which is obviously a significant change to the KDE spin. We also have
GNOME 3.16.2 pending; they haven't filed that yet, but I'm expecting
it today or tomorrow. If we're going to pull in a pair of significant
desktop updates, we should do it as soon as possible. I really wish we
could somehow stop having these situations where the desktop teams
want to push big updates right after freeze points, as it seems to
keep happening, but for right now we need to make a decision.
So, I'd like to get sufficient votes on the proposed blockers and at
least the significant proposed FEs as soon as possible. Would folks
prefer voting on-list or in-bug, or having a special meeting, perhaps
tomorrow (05-13) or Thursday (05-14) at the usual time (1600 UTC)?
Please reply if you'd be willing to attend a special meeting. If you'd
rather vote in-bug, feel free to do so - we can count those votes at a
meeting if one occurs.
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 11 months
