Anaconda-devel July 2014

anaconda-devel@lists.stg.fedoraproject.org

23 participants
12 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

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

BZ 1072355: language selection indicator
by Máirín Duffy 31 Jul '14

31 Jul '14

Hi folks, Here's another UX bug - David Shea and I have been talking about this one today in IRC. Basically the problem is that users can select multiple langauges from the languages screen in the main hub, but when they do so it's not clear in the list which languages they've already selected. This is sort of a positional / wayfinding issue - the users are visting different areas within the list but then it's unclear where they've already been and where Our guess is that the average user who needs this screen is bi-lingual. Although there is probably a use case where a sysadmin is using anaconda just to generate a ks file from it, in which case he may need to support end users of many languages. So 2 languages or many languages are kind of potential use cases here. Anyway, I did some research and could not find many design patterns similar to this scenario. One very common one that isn't *exactly* the same but kind of close is visited links on webpages turning a different color, e.g. a darker color. One issue with relying on color too heavily though is that for visually-impaired folks, doing custom colors might cause issues and especially in an environment like anaconda where the user isn't at the point they can tweak the environment reasonably to their own preference, we want to be able to be usable by the folks from the start, so I think having some kind of indicator besides a color change would be important. So here is the mockup - the idea is to highlight the ones you've selected and also denote them via an icon of some sort - here we used the 'ok' icon from the GNOME symbolic icon set: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Lang-Multi-Select… What do you think? ~m

3 2

Screen blanking in f20
by Jerry Amundson 30 Jul '14

30 Jul '14

Hi. How can I prevent the screen from blanking during fully automated, kickstart, text mode installation? Thanks, jerry

2 2

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

30 Jul '14

again, you are bringing an unrelated issue into this thread. Sent from my phone, which is not an iphone. <div>-------- Original message --------</div><div>From: Felix Miata <mrmazda(a)earthlink.net> </div><div>Date:07/30/2014 1:36 AM (GMT-05:00) </div><div>To: anaconda-devel-list(a)redhat.com </div><div>Subject: Re: BZ 1094856: screen redesign idea </div><div> </div>On 2014-07-29 15:25 (GMT-0400) Máirín Duffy composed: > Felix Miata wrote: >> ...them thinking to make things bigger rather than having more >> things on screen at once. > whitespace is important to establish relationships between > elements and make a lot of information easier to understand / digest. Whitespace may be "important", but shouldn't come at the expense of content legibility. Here there is too much of this "important" thing, as I hope the following will understandably demonstrate: Non-contextual screenshots made by Anaconda/F21TC2: running 1024x768: http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-SofSel-0768vr-Sg520.png running 1280x1024: http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-InsDes-1024vr-Sg520.png http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-ManPar-1024vr-Sg520.png http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-SelDis-1024vr-Sg520.png running 1600x1200: http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-InsDes-1200vr-D2000fp.png http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-ManPar-1200vr-D2000fp.png http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-SelDis-1200vr-D2000fp.png http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-SofSel-1200vr-D2000fp.png What do they tell anyone? Not a thing about legibility, because display density is unknown, and thus how big physically a pixel or the screen is is also unknown. Viewing context is missing a crucial component. These are the same 1600x1200 images inserted into a context: http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-InsDes-1200vr-132dpi.png http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-ManPar-1200vr-132dpi.png http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-SelDis-1200vr-132dpi.png http://fm.no-ip.com/SS/Fedora/anacondaSS-f21t2-SofSel-1200vr-132dpi.png Contextual attributes: 1-display density is given as 132 DPI (137.5% of the industry yardstick that is the basis for the CSS px unit definition, 96 DPI), modestly above whatever "normal" might be, well below what display manufacturers and vendors describe as "high resolution" or "high density", with names like "Retina" and "UltraSharp". 2-The image viewer is displaying those images at 100% of intrinsic size on an F21 installation on the same system and using the same displays on which Anaconda was run for capturing most of the first group of images. The desktop is personalized for this user, so you have the context of the system in normal action, with menu text open, font settings open, Firefox open, and a calculator utility, all for contextual comparison to the installation image. 3-Each image has a "yardstick", a tool you can use as a basis to adjust the physical size of the image on your screen so that you can very closely emulate the experience here trying to use Anaconda. All that's required of you is to open each image in a viewer with which you can make the included 1" image 25.4mm wide measuring it with a ruler on your screen. So, regardless of your display's size or resolution or density, you can emulate what is happening here, and know a major reason if not the biggest reason why I don't like Anaconda. Notwithstanding its other attributes, and all its "important" whitespace, it falls far short of being user friendly on the basis of its marginal legibility even at common display density, plus lack of any appreciable way (that I've been able to discover) to improve legibility. >> Clickable link omitted from OP: >> https://bugzilla.redhat.com/show_bug.cgi?id=1094856 > ? BZ 1094856 in a plain text email is not a clickable link. To see what it refers to requires getting Bugzilla open in something, then copy & paste or type it in to find out what it's about. URI you quoted above is a clickable link in every GUI email program's plain text display mode that I've ever used, a convenient one step process. -- "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/ _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list

3 5

anaconda bad for high density displays and visual acuity below median
by Felix Miata 30 Jul '14

30 Jul '14

When I have to install using Anaconda, I'm in the habit of switching into temporary use of a little old 1024x768 LCD to get installation started in that mode, after which I switch to a usual display that can make everything big enough to not be uncomfortable or even illegible, as is "1 storage device selected" at the bottom of both original and mockup. The bother involved makes me test Rawhide less often than I otherwise would. It certainly seems like there ought to be a way via cmdline switch and/or initial screen to accommodate visual needs, but if there is, it's managed to escape my notice for years. -- "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/

2 2

Re: anaconda/grub2/ostree/uefi/cats/dogs
by Matthew Garrett 23 Jul '14

23 Jul '14

On Tue, Jul 08, 2014 at 03:46:28PM -0600, Chris Murphy wrote: > > On Jul 7, 2014, at 2:43 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > > > Ok, here are my first attempts at modifying the spec to be more > > generally useful. Note that this means that gummiboot can no longer > > implement the full spec, but since gummiboot is also unable to do > > several other things that we need to do I don't see that as a problem in > > Fedora. > > > > https://secure.freedesktop.org/cgit/www/log/MatthewGarrett/BootLoaderSpec.m… > > > * What's the distinction between $boot and $root in > grub-core/commands/blscfg.c? GRUB_BOOT_DEVICE is $boot when > GRUB_MACHINE_EFI. While GRUB_BOOT_DEVICE is $root on non-UEFI. Yet the > revised spec says /org/freedesktop/bls goes on the ESP as $boot > whether UEFI or non-EFI. I need to actually set up a BIOS system again to verify how this is going to work properly - it's been too long since I used one. However, there's still no requirement that grub be installed on the ESP on BIOS systems, so drawing a distinction between "The disk with grub on it" and "The disk with the config on it" is still important. > * Changes, 3rd bullet, "There's no reason to enforce VFAT as long as > the filesystem is able to read it." I'm thinking "filesystem" was > meant to be "firmware". Correct. > * What happens to BIOS Boot on BIOS systems where GPT is either > preferred, or necessary to support > 2.2TB drives? Looks like such > systems get BIOS Boot still for core.img, a FAT formatted ESP for > /org/freedesktop/bls/entries, and a Linux boot partition for > kernel+initramfs, grub, etc. And I'm not sure really what's gained by > changing the legacy layout with one more partition, formatted as FAT, > for just bootloader snippets. The bios boot partition has no filesystem, so can't be used to store configuration. /boot is not required to be shared between multiple operating systems. > * Spec doesn't address how a spec compliant installer should behave > when installing along side an existing installation: Should > bootability of the previous OS must be preserved? That seems a > critical point of contention with most distros erring on the side of > "oh, whatever" <hand waive> "user obviously doesn't care about the > other OS that much, they're installing ours." I think as a default > behavior it's pernicious. Sure, that's outside the spec. If there's a boot fragment for the other OS then it'll remain installable. If the OS wants to support booting non-compliant OSes then it should ensure that fragments are generated. What *is* missing is guidance on naming of chainload/efi fragments - using the machine ID there is obviously inappropriate. I'll add something on that. > * A consequence of BLS is multiple device resilient boot isn't > possible because the configuration files go on a single ESP disk, > which can't be on md raid (or btrfs). So it becomes a single point of > failure. For BIOS systems there's no problem with RAIDing the ESP. For UEFI systems it's already a single point of failure. -- Matthew Garrett | mjg59(a)srcf.ucam.org

6 13

LiveCD or equivalent questions...
by Jon Stanley 22 Jul '14

22 Jul '14

I'm not sure where to post this, but I think all of the relevant players are on this list, but I'm happy to move this elsewhere if warranted. At $DAYJOB we have a fairly simple requirement - a stateless image that can be either PXE booted or booted off of local disk. The important characteristic here is that when the machine is rebooted, it loses all concept of local state. The authority of what state the machine should be in lives elsewhere, so it needs to come up, be stupid. and phone home for further instructions. We originally thought that LiveCD was the perfect mechanism for this, and it worked fine - until the devicemapper read/write overlay (RAM backed in this case) got filled up, and then the whole thing goes BOOM! What I'm interested in is finding some way for a non-persistent overlay to not blow up in our faces when the system has been up for awhile and various logs, etc have been written. The use case is for a KVM hypervisor, so we'll have long running VM's on the hypervisor and all the attendant logs being written. The VM's are of course backed by local disk. Is such a thing feasible? Am I barking up the wrong tree, or is there something that I'm not thinking of here?

4 3

[lorax] how to decrease squashfs.img size, it increase more than install size
by 耳东 22 Jul '14

22 Jul '14

hi guys. I want to build a cutom liveos by lorax. my first liveos , dracut miss 'livenet' module, so it can **NOT** boot under PXE boot failed message: dracut: FATAL: Don't Know how to handle 'root=live:http:// ...squashfs.img' first create command: livemedia-creator --no-virt --make-iso --ks=centos7.liveos.ks.cfg After I add 'dracut-network' package in centos7.liveos.ks.cfg '%package' section, the second create liveos with 'livenet' module can boot from PXE successfully: livemedia-creator --dracut-arg="--no-hostonly" --no-virt --make-iso --ks=centos7.liveos.ks.cfg But squashfs.img size increased was larger than the size initramfs.img increased. I hope to slim 'squashfs.img' size, so it could boot from PXE speedily. I mount the squashfs.img compare the different size of these two liveos, the different size was **only** at initramfs.img install size was increase on 11M, but squashfs.img increase 50M : # df -h ... /dev/loop1 296M 296M 0 100% /mnt/1 <-- squashfs.img size /dev/loop2 21G 817M 20G 4% /media/1 <-- install size ... /dev/loop3 346M 346M 0 100% /mnt/2 <-- squashfs.img size /dev/loop4 21G 828M 20G 4% /media/2 <-- install size 'du -sh' show it under '/boot' direcory. # du -sh /media/1/*|sort -rh 748M /media/1/usr 31M /media/1/boot <-- initramfs.img without livenet 22M /media/1/var 9.6M /media/1/etc 3.2M /media/1/opt 143K /media/1/root 12K /media/1/lost+found 11K /media/1/tmp 1.0K /media/1/sys 1.0K /media/1/srv 1.0K /media/1/run 1.0K /media/1/proc 1.0K /media/1/mnt 1.0K /media/1/media 1.0K /media/1/home 1.0K /media/1/dev 0 /media/1/sbin 0 /media/1/lib64 0 /media/1/lib 0 /media/1/bin # du -sh /media/2/*|sort -rh 748M /media/2/usr 42M /media/2/boot <-- nohostonly initramfs.img with livenet 22M /media/2/var 9.6M /media/2/etc 3.2M /media/2/opt 143K /media/2/root 12K /media/2/lost+found 11K /media/2/tmp 1.0K /media/2/sys 1.0K /media/2/srv 1.0K /media/2/run 1.0K /media/2/proc 1.0K /media/2/mnt 1.0K /media/2/media 1.0K /media/2/home 1.0K /media/2/dev 0 /media/2/sbin 0 /media/2/lib64 0 /media/2/lib 0 /media/2/bin increase SIZE was at initramfs.img: -rw-r--r-- 1 root root 34M | 2014-07-17 22:58:56 | initramfs-3.10.0-123.4.2.el7.x86_64.img -rw-r--r-- 1 root root 23M | 2014-07-17 20:28:49 | initramfs-3.10.0-123.4.2.el7.x86_64.img /media/1/boot: total 31M drwxr-xr-x 2 root root 1.0K | 2014-07-17 20:27:43 | grub drwxr-xr-x 3 root root 1.0K | 2014-07-17 20:27:47 | grub2 -rw-r--r-- 1 root root 174K | 2014-06-10 16:16:36 | elf-memtest86+-4.20 -rw-r--r-- 1 root root 173K | 2014-06-10 16:16:36 | memtest86+-4.20 -rw-r--r-- 1 root root 224K | 2014-07-01 00:20:49 | symvers-3.10.0-123.4.2.el7.x86_64.gz -rw-r--r-- 1 root root 23M | 2014-07-17 20:28:49 | initramfs-3.10.0-123.4.2.el7.x86_64.img -rw-r--r-- 1 root root 120K | 2014-07-01 00:18:32 | config-3.10.0-123.4.2.el7.x86_64 -rw------- 1 root root 2.8M | 2014-07-01 00:18:32 | System.map-3.10.0-123.4.2.el7.x86_64 -rwxr-xr-x 1 root root 4.7M | 2014-07-01 00:18:33 | vmlinuz-3.10.0-123.4.2.el7.x86_64 /media/2/boot: total 42M drwxr-xr-x 2 root root 1.0K | 2014-07-17 22:57:34 | grub drwxr-xr-x 3 root root 1.0K | 2014-07-17 22:57:38 | grub2 -rw-r--r-- 1 root root 174K | 2014-06-10 16:16:36 | elf-memtest86+-4.20 -rw-r--r-- 1 root root 173K | 2014-06-10 16:16:36 | memtest86+-4.20 -rw-r--r-- 1 root root 224K | 2014-07-01 00:20:49 | symvers-3.10.0-123.4.2.el7.x86_64.gz -rw-r--r-- 1 root root 34M | 2014-07-17 22:58:56 | initramfs-3.10.0-123.4.2.el7.x86_64.img -rw-r--r-- 1 root root 120K | 2014-07-01 00:18:32 | config-3.10.0-123.4.2.el7.x86_64 -rw------- 1 root root 2.8M | 2014-07-01 00:18:32 | System.map-3.10.0-123.4.2.el7.x86_64 -rwxr-xr-x 1 root root 4.7M | 2014-07-01 00:18:33 | vmlinuz-3.10.0-123.4.2.el7.x86_64

3 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel July 2014