Anaconda-devel August 2014

anaconda-devel@lists.stg.fedoraproject.org

4 participants
5 discussions

anaconda/grub2/ostree/uefi/cats/dogs
by Colin Walters 16 Oct '14

16 Oct '14

This is a followup to: https://bugzilla.redhat.com/show_bug.cgi?id=1101359 https://bugzilla.redhat.com/show_bug.cgi?id=1100938 While it's not strictly related to Anaconda the codebase, this is a good mailing list which has the relevant participants, and I find email to be better for architectural discussions than Bugzilla. Now, unfortunately the OSTree model definitely impacts the bootloader situation badly. The fundamental promise of it is that upgrades are atomic, and the way that's implemented is for it to be in control of the bootloader configuration, specifically to perform an atomic replacement. That bootloader configuration then has an ostree= kernel argument which is used in the initramfs. The original design was to use the http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ - it had the promise of bootloader-independent configuration. I really liked that idea, as it got me out of the grubby-like model of having to keep up with lots of file formats for the many bootloaders. Peter did add support for the BLS to grub2. However at the time, syslinux didn't implement BLS, and rather than hack it, I cowardly decided to take the easy route and just generate syslinux configs as well. Now fast forward a bit, and mainly Chris convinced me in: https://bugzilla.redhat.com/show_bug.cgi?id=1101359 that the BLS design of having kernels/initramfs on FAT isn't right. See also: https://lists.fedoraproject.org/pipermail/desktop/2014-June/009962.html There's another thread here, which is that I recently discovered grub2 has support for reading syslinux config files: http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/commands/syslinuxc… This dovetails with a Fedora feature Dennis created to use syslinux config files for u-boot: http://fedoraproject.org/wiki/Changes/u-boot_syslinux (Incidentally OSTree has code to generate u-boot too: https://git.gnome.org/browse/ostree/tree/src/libostree/ostree-bootloader-ub… that could go away) Now, this offers the opportunity to basically have the unified configuration aspect of the BLS, without anything else. We retain the current way UEFI boots work. OSTree and grubby remain the tools to read/write bootloader configuration (we could entertain some code merging but I don't see that as a priority). One thing to work out with this I think would be how probed entries were merged with static syslinux config entries. Or would we just do probing at install time? Does that all make sense?

3 5

pdb.set_trace() with liveinst
by Gene Czarcinski 20 Sep '14

20 Sep '14

Is it possible to use pdb.set_trace() when liveinst is used to run anaconda? I tried and, if it is suppose to work, there is a bug because it blows up and exits when it hits the first pdb.set_trace() How do you debug when you have the liveinst environment? Gene

3 5

does anyone still use run-hub, run-spoke, &al.?
by David Shea 20 Aug '14

20 Aug '14

I don't think they work anymore? And I don't know whether anyone cares about them hard enough to make them work. Is it time to send these old friends out to pasture?

2 1

RE: BZ 1094856: screen redesign idea
by Máirín Duffy 13 Aug '14

13 Aug '14

Truly sorry for the top post... working on getting a better mobile client - I agree 100% with your assessment of disclosure triangles. I think they would be a better widget in GTK+ if they were more easily targetable. I also agree a lot of users look under them to peek anyway. What I will say is that they can be effective in the users' first perception of the screen. I've recently been through the process of selling my house, and one real estate factoid I have heard frequently is buyers form their main impression of a house in the first 15 seconds. I think this could apply to UI screens too. If at the outset there's a ton of controls and other clutter on the screen, it can be a very overwhelmed first impression. (like one messy house I visited that smelled like a litter box as soon as you walked in.) But the disclosure triangles give you this dirty trick that makes the screen seem very clean and uncluttered at first glance which might give users more confidence / less stress to start. When they dig into the extended controls underneath, they are opting into that so they feel more in control of the situation. Where the disclosure triangles really fail is twofold: - they start breeding and suddenly there's multiple screens' worth of cruft shoved in there (as Chris pointed out) - when many users *must* open up the disclosure to access controls they teuly need. I have screwed this up in the past with anaconda designs and it's my bad. It's just a speed bump at that point and way annoying. So if these controls are definitely very rarely used, the disclosure might be a nice way to go if the mouse target area could be somehow padded to make it easier to click. But design 2 is okay too. My one reservation with it that I should point out is that it becomes unbalanced when you dont have the vg selector in non LVM device types... which is the main reason I stacked the name / label controls vertically in #3. ~m On 07/31/2014 04:28 AM, Vratislav Podzimek wrote: I found those "expandables" problematic. They are hard to hit with the mouse cursor, they are quite tiny and don't scale on big screens and everybody's just interested what may be there so everybody will click/expand it anyway. -- Vratislav Podzimek Anaconda Rider | RHCE | Red Hat, Inc. | Brno - Czech Republic _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list

2 1

BZ 1094856: screen redesign idea
by Máirín Duffy 01 Aug '14

01 Aug '14

Hi, vpodzime mentioned BZ 1094856 to me earlier today in IRC. Basically, when you are in custom partitioning and click on the little wrench/screwdriver icon to get to the 'Configure Mount Point' dialog (so you can pick which disks/devices your mount point will live on), your selection doesn't apply until you hit the 'Update Settings' button on the right hand side of the main dialog. This actually came up in a usability test this past Feb as well, so it's definitely not just one person running into the confusion. The issue is that the change is made in a dialog launched from the left, but the application button is on the main screen and towards the right. So we had the idea in IRC to move the disk selection tool over to the right hand side, so the button would look more like it would apply to it. I also designed it such that there's a little 'preview' of the disks the mount point is associated with so it looks like you'd have to hit the update settings button (if that makes sense.) Of course, being a designer and a pain in the ass, I made some purely aesthetic tweaks to try to help the flow of the screen and general cleanliness of the layout since we're adding yet another element to an already-cluttered area: - I mocked this up with the widget labels vertically above the widgets rather than to the left. GTK+ should allow for this (and *hopefully* it's just a matter of tweaking a single boolean.) This gives the widgets a lot more room to breathe and enables the next point... - I put the widgets in columns to group items that are roughly related together. For example, the volume group selection is now vertically grouped with the device type, whereas the filesystem is in a column to the right of that. The name and label and capacity are grouped together in one column since those are all kind of basic metadata kind of things, then the mountpoint and the disk selection are grouped together in the right column since they both vaguely pertain to the 'location' of the partition. Anyway here is the before (as it currently looks in RHEL 7.0 GA): http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Move-Device-Selec… And here is the after: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Move-Device-Selec… It kind of works, right? What do you think? Is the mucking about doable here? ~m

6 18

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel August 2014