Anaconda-devel May 2014

anaconda-devel@lists.stg.fedoraproject.org

13 participants
16 discussions

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

Follow installation progress
by Artem Bityutskiy 30 May '14

30 May '14

Hi, I am installing Fedora 20 to my servers using PXE boot + Kickstart mechanisms, so that it is fully automatic. It works well. However, there is one basic problem I cannot solve - How do I follow the installation progress? Here is the issue: sometimes the installation is fast, sometimes it is slow, and sometimes it dies in the middle (e.g., the repository, which is remote, becomes unavailable). Currently I have a simple time-out solution. If the installation does not finish within 45 minutes, I assume that it failed. My scripts just wait for a '/tmp/post-finished' file to be created, and I create it from the '%post' section of the KS file. Instead, what I would like to do, is to follow the package installation log. Like the one that I see in VGA: Installing package A Installing package B .... But the problem is that this log is not available anywhere but the VGA display. I googled around, people mention some install.log file, but it does not exist in my case. I also saw that there is an option to make anaconda send log message to a remote syslog, but this would not be a good solution for me. I'd really prefer anaconda to log to a file (and flush the stream), and let me follow the log. Is this possible, any suggestions? Thanks in advance! -- Best Regards, Artem Bityutskiy

5 9

bad value in /boot/grub2/grubenv
by Gene Czarcinski 29 May '14

29 May '14

The value for saved_entry set by anaconda is bad ... that is, incorrect. The only reason that things generally works is that if grub2 does not find a match, it defaults to the first menuentry and this is generally what folks want to happen. So, before I go about creating a fix, I am asking how folks want this fixed because there are two options ... well, really three because there is always the option of doing nothing. From grub2-set-default --help: MENU_ENTRY is a number, a menu item title or a menu item identifier. Option 1. Set "saved_entry=0". This is valid and, until changed will always boot the first kernel entry. One positive thing is that grubby won't have to change. Option 2. Set "saved_entry=<first_field_on_menuentry>" is valid. But you will keep booting this after new kernels are installed unless you change grubby. Depending on you point of view, this can be good or bad. This is the purist's answer. This old engineer prefers option 1 because grubby does not have to change and things behave as most folks expect. The user can always run grub2-set-default to set the wanted default. Comments? Gene

2 1

need help debugging anaconda-yum
by Gene Czarcinski 28 May '14

28 May '14

I am having a problem with anaconda-yum hanging with 100% VCPU (my last hang lasted 100 minutes before I gave up and reset): https://bugzilla.redhat.com/show_bug.cgi?id=1101544 The problem is very unpredictable because it does not always happen and my current attempt seems to be running to completion. 1. qemu-kvm virtual systems with 2 VCPUs, 2GB memory and 8GB virtual disk. 2. The input is a DVD iso (created by mock/pungi) based on the5/26/2014 version of rawhide. 3. Install LXDE desktop on regular partitions with ext4. 4. Boot the DVD iso with "inst.debug=1 extlinux" and the command line. When it hangs, it is somewhere is anaconda-yum. Any tips on how to debug this? Although anaconda-yum is python code, it runs as a separate process outside of the regular anaconda so I am uncertain as to how to approach debugging. Gene

2 2

rw versus ro for btrfs rootfs
by Gene Czarcinski 27 May '14

27 May '14

At one time it was pointed out to me that it is unnecessary to mount rootfs ("/") ro if the filesystem is btrfs (I have since lost the reference). Things seem to work just fine if "ro" is changed to "rw" and all btrfs entries in /etc/fstab have 0 0 for the fifth and sixth fields thus fsck will not be run. In any case, btrfsck can only be run on an unmount filesystem and not a subvolume. So, should things be changed for extlinux.conf and grub.cfg so that, if the rootfs is btrfs, it will be mounted rw rather than ro? Also, are there other filesystems with "0 0" which should also be mounted rw instead of ro? Comments? Gene

1 0

need help debugging Live Install
by Gene Czarcinski 27 May '14

27 May '14

I am trying to do some debugging of anaconda running livepayload. Is there a way to run pdb.set_trace() or something equivalent? When I try, it crashes anaconda. Also, is the --debug suppose to do something? If so, what? Gene

2 1

Re: execution order involving the bootloader install
by Chris Murphy 24 May '14

24 May '14

Observations with today's Rawhide: Fedora-Live-Workstation-x86_64-rawhide-20140522.iso First, the grub.cfg is hosed. The rescue boot entry is listed first, and is the default. It should be reversed. https://bugzilla.redhat.com/show_bug.cgi?id=1100504 I don't know which component's bug this is, anaconda for calling grub2-mkconfig before the kernel and initrd have even been created, or grubby for not adding the entry in the right location. So before I file anymore bugs I'd like to know whether grub2-mkconfig is really supposed to be called before all kernels and initramfs's are in /boot, and the expectation is that grubby will fix all missing items in the grub.cfg. Chris Murphy

2 10

execution order involving the bootloader install
by Gene Czarcinski 22 May '14

22 May '14

Recently, a change was made to install.py which has the bootloader install taking place before "post-installation setup tasks". This has resulted in a problem: https://bugzilla.redhat.com/show_bug.cgi?id=1099627 The problem has been mostly "fixed" by modifying grubby to handle the situation. While the result sort-of works (I can boot), I consider that there is still a problem which (most likely) can only be handled in anaconda: 1. The order of grub2 menuentry is now rescue-kernel then regular-kernel rather than the usual order of regular-kernel then rescue kernel. 2. The value for the default kernel is incorrectly set so that, when you boot up, the default is the first kernel ... the rescue kernel. To me, this is wrong and should be fixed. Question: what is the purpose of changing the order of when the bootloader is installed? Gene

2 1

definite bug and not a feature
by Gene Czarcinski 21 May '14

21 May '14

This is not a biggie but is definitely a blocker for alpha. https://bugzilla.redhat.com/show_bug.cgi?id=1099627 The problem is the livecd produced a system which is not bootable. See the bug report for info on specifics. I am looking into the cause. Until fixed, just remember to run grub2-mkconfig -o /boot/grub2/grub.con while chrooted in the new system before you actually reboot. The priority for fixing this needs to be raised. [yes, I know thast there is at least one more very high priority problem out there] Gene

1 0

feature or bug?
by Gene Czarcinski 21 May '14

21 May '14

At some point in the last couple of Fedora releases, it was decided to eliminate /sbin and /bin and use /usr/sbin and /usr/bin instead. For compatibility, there are symbolic links in the root for bin -> /usr/bin and sbin -> /usr/sbin. Great! Do not have to worry anymore about the different locations for programs. BTW, a similar thing is done for /lib and /lib64. Really simplifying things. BUT (and here is the rub) anaconda (in rawhide) lets you put /usr on a separate BTRFS subvolume but it will not let you put /etc on a separate subvolume. IIRC, the idea of /sbin and /bin (as well as /etc) was that it had to be there for the system to bootup and if it was on a separate partition, that could not be guarenteed. I am equating partition and subvolume as equivalent. If I can put /usr on a different subvolume which will include /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64, then I should be able to put /etc on a separate subvolume and anaconda should be enhanced to permit it. On the other hand, if I need all of those directories, then anaconda has a bug and should be updated to disallow putting /usr on a separate subvol or partition or LVMlv. My reason for bring this up is that I recently screwed up one of my systems and had to reinstall. Well, asside from the OS itself, I did have backups for /home and my development directories which are on separate BTRFS subvolumes. To do backups, I use btrfs-snapshot and then btrfs-send for a baseline or delta. This proved to work well. I simply had the do btrfs-receive the baseline and install it in the new btrfs-filesystem. Then do another btrfs-receive for the delta.. Since both the restored snapshots are r/o, I could then do a new btrfs-snapshot to r=create a r/w subvol. When I realized how well this worked and how easy it was to do, I wanted to do the same thing for /etc becuase I change a lot of stuff in it such as /etc/libvirt definitions. OK, is putting /usr on a different btrfs subvol a bug or a feature? Gene

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel May 2014