Anaconda-devel October 2011

anaconda-devel@lists.fedoraproject.org

25 participants
57 discussions

changing the color scheme in text based install
by Paul B Schroeder 10 Oct '11

10 Oct '11

Hello all.. I'm doing a custom distro in which the customer would like to change the red and blue color scheme. I've done a quick peruse through the anaconda source tree and it is not readily apparent to me where I would make such a change. Can anybody out there provide me a hint as to where I should look to make this change? Thanks in advance...Paul... -- --- Paul B Schroeder <paul.schroeder "at" vbridges "dot" com> Virtual Bridges, Inc.

3 2

Regarding my recent DD "delay" patch to RHEL6 (#732496)
by Martin Sivak 10 Oct '11

10 Oct '11

Hi, David told me, that some people were curious about why do we need this delay. I will try to explain that. Currently the sequence in which kernel-udev-anaconda chain works during the loader init in UEFI case: - kernel detects compiled-in devices - our init starts - our init starts udev (and udev doesn't see any new messages - already enumerated devices are not processed) - init -> loader - loader calls udev --trigger - kernel/udev starts enumerating all coldplugged devices + detecting new devices - usb-storage is detected and starts it's _5_second_ delay (upstream recently changed it to 1 sec and we will change it in 6.2 too) - loader waits for settled udev (which only means that there are no unprocessed messages in the queue) - udev settles (usb-storage is still waiting) - loader enumerates possible DD sources and finds nothing <- this is the bug (DD is not detected in UEFI mode) - loader commences with normal stuff, net, stage2, ... - usb-storage ends it's waiting phase and reports all it's drives - scsi subsystem starts it's 1 second wait to let the drives settle - udev creates necessary devices - stage2 is started Please notice the compiled in delays (total 6 seconds atm.) in kernel modules and the meaning of udev --settle. If kernel takes more time processing something than udev takes processing pending messages, we get the settled state. We depend on it to continue, but it doesn't mean kernel has enumerated all devices. There is no easy way to synchronize this as neither udev nor kernel support any "all done" flag (obviously, how should they now?). Our settle approach works only if there is uninterrupted stream of kernel messages to udev.. and in this case it just isn't true.. Non UEFI worked only because usb-storage was initialized earlier and the delay loops ended earlier than loader entered the enumeration phase. So the reasoning behind the delays is this. If we add 2 second delay after the first udev trigger, we will match the internal usb/scsi delays and get all the devices. With no driverdiscs, this will cause 2 second delay to the installation. This is the only solution we were able to find with combined effort by me, Harald, Stuart Hayes and Don Zickus (usb-storage guy). Also I'm not porting this to Fedora, since we plan on killing loader anyways and I will (hopefully) be able to use different approach in dracut environment. -- Martin Sivák msivak(a)redhat.com Red Hat Czech Anaconda team / Brno, CZ

1 0

anaconda spend too long long time to download updates.img file
by c.y.liu 09 Oct '11

09 Oct '11

hi all, i'm not sure whether i should post this on devel list, but this is the only place i found. please guide me if there is a more proper place i can find answer. ok, here is the problem i met. i have one RHEL6.1 x86_64 server which severs as PXE server. and i want to provision another RHEL6.1 compute host. after the compute host power on, it can successfully get the IP address from DHCP server and kerner, initrd from tftp server. but when anaconda try to download the updates.img file, it took too much time (more than 20 minutes). i have tried to download the updates.img directly using wget command, it's OK. the files can be downloaded in seconds. so i think the http works well. and the wired thing is this doesn't happen always. sometimes, the anaconda can download very quickly. following are some logs i pick up from tty (Alt + F3) 09:45:29,765 INFO : doing kickstart... setting it up 09:45:34,775 INFO : wait_for_iface_activation (2274): device eth0 activated 09:45:34,781 INFO : trying to mount CD device /dev/sr0 on /mnt/stage2 09:45:34,783 INFO : drive status is CDS_TRAY_OPEN 09:45:34,784 INFO : Drive tray reports open when it should be closed 09:45:49,799 INFO : no stage2= given, assuming http://192.168.10.20/repos/1000/images/install.img 09:45:49,799 INFO : setting language to en_US.UTF-8 09:45:49,813 INFO : starting STEP_METHOD 09:45:49,818 INFO : starting STEP_STAGE2 09:45:49,818 INFO : URL_STAGE_MAIN: url is http://192.168.10.20/repos/1000/images/install.img 09:45:49,818 INFO : transferring http://192.168.10.20/repos/1000/images/updates.img ... (long time wait) (Alt + F4) INFO dhclient: DHCPREQUEST on eth0 to 192.168.10.10 port 67 (xid=0x233777f9) INFO dhclient: DHCPACK from 192.168.10.10 (xid=0x233777f9) INFO NetworkManager: <info> (eth0): DHCPv4 state changed bound -> renew INFO NetworkManager: <info> address 192.168.10.30 INFO NetworkManager: <info> prefix 24(255.255.255.0) INFO NetworkManager: <info> gateway 192.168.10.11 INFO NetworkManager: <info> hostname root01 INFO NetworkManager: <info> nameserver '192.168.10.10' INFO NetworkManager: <info> nameserver '192.168.10.11' INFO NetworkManager: <info> domain name 'private.dns.zone' INFO NetworkManager: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS INFO dhclient : bound to 192.168.10.30 -- renew in 1092 seconds by the way, the same system works very well on RHEL5.5. i never encounter such problem. any suggestion will be greatly appreciated! -- Chunyang Liu

1 0

Fixing pyblock build and package issues
by Daniel Drake 09 Oct '11

09 Oct '11

Hi, python-pyblock fails to build on F15 and newer, and this minor issue has bitten the F15-on-ARM efforts: https://bugzilla.redhat.com/show_bug.cgi?id=715663 Fixed in: https://www.redhat.com/archives/anaconda-devel-list/2011-October/msg00050.h… https://www.redhat.com/archives/anaconda-devel-list/2011-October/msg00051.h… Actually, the version included in F15 is not the latest version. The latest version is only available in F14 and is marked as fixing the following bug which seems to have been treated with importance: https://bugzilla.redhat.com/show_bug.cgi?id=584328 However, the fixed version failed to build for F15 in Koji due to the build issue, leading to F14 updates being newer than F15 (and F16), and a likely regression on the original issue: https://bugzilla.redhat.com/show_bug.cgi?id=709161 I volunteer to fix this - if someone could merge the pyblock patches (or just one of them) and do a release, I'm happy to do the packaging and push it to F15 and F16 updates, closing #709161 and #715663, and adding a note to #584328. Then we can run the fixed build on ARM. cheers, Daniel

1 0

[PATCH pyblock] Fix Python object converter pyblock_TorLtoT
by Daniel Drake 09 Oct '11

09 Oct '11

gcc pointed out that 'result' is set but never used, and this has highlighted an oversight in how this Python object converter function is written. Fix it according to the Python documentation and using the implementation of PyUnicode_FSConverter() as a point of reference. Compile tested only. --- pyhelpers.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/pyhelpers.c b/pyhelpers.c index a050839..9e15ff3 100644 --- a/pyhelpers.c +++ b/pyhelpers.c @@ -157,7 +157,7 @@ pyblock_potoll(PyObject *obj, void *addr) int pyblock_TorLtoT(PyObject *obj, void *addr) { - PyObject *result = (PyObject *)addr; + PyObject **result = (PyObject **)addr; if (!obj) { if (!PyErr_Occurred()) @@ -166,16 +166,16 @@ pyblock_TorLtoT(PyObject *obj, void *addr) } if (PyTuple_Check(obj)) { - result = obj; + *result = obj; return 1; } if (PyList_Check(obj)) { - result = PyList_AsTuple(obj); + *result = PyList_AsTuple(obj); return 1; } - result = NULL; + *result = NULL; PyErr_BadArgument(); return 0; } -- 1.7.6.4

1 0

[PATCH pyblock] Don't build with -Werror
by Daniel Drake 09 Oct '11

09 Oct '11

This -Werror has caused https://bugzilla.redhat.com/show_bug.cgi?id=715663 and some confusion at https://bugzilla.redhat.com/show_bug.cgi?id=709161 because the equivalent F15 update build failed. In general it doesn't seem like a good idea to bail out on warnings as future versions of gcc will have a different idea of what should be warned about. On the other hand, this build failure actually found a real bug, so I may not be making a convincing case here. Thoughts? --- Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 3b8eb7b..d059ed1 100644 --- a/Makefile +++ b/Makefile @@ -5,7 +5,7 @@ DEBUGSRC := "/usr/src/debug" DEBUGLIB := "/usr/lib/debug" CC := gcc PYVER := $(shell python -c "import sys; print sys.version[0:3]") -CFLAGS := -g -I/usr/include/python$(PYVER) -Wall -Werror -fPIC $(OPTFLAGS) -fno-strict-aliasing +CFLAGS := -g -I/usr/include/python$(PYVER) -Wall -fPIC $(OPTFLAGS) -fno-strict-aliasing LDFLAGS := -shared VERSION := $(shell awk '/Version:/ { print $$2 }' python-pyblock.spec) -- 1.7.6.4

1 0

How are you?!
by nadeem lion 09 Oct '11

09 Oct '11

Hi there! I refused to keep living that way I took my chances with this now everyone recognizes me you have potential give it a try http://www.monalisahotels.com/redirect.php?tidid&zuwizyb=yahoo.com&wyzuja=a… see you later.

1 0

[rhel6-branch] fcoe: modprobe the VLAN layer module.
by Ales Kozumplik 07 Oct '11

07 Oct '11

Related: rhbz#641420 --- storage/fcoe.py | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/storage/fcoe.py b/storage/fcoe.py index c8b957d..568f55d 100644 --- a/storage/fcoe.py +++ b/storage/fcoe.py @@ -133,6 +133,9 @@ class fcoe(object): # Ideally, this should be done by checking a "AUTO_VLAN" parameter, # not bnx2x driver usage if 'bnx2x' in os.path.realpath('/sys/class/net/%s/device/driver' %(nic)): + # certain network configrations require the VLAN layer module: + iutil.execWithRedirect("modprobe", ["8021q"], + stdout = "/dev/tty5", stderr="/dev/tty5") iutil.execWithRedirect("fipvlan", ['-c', '-s', nic], stdout = "/dev/tty5", stderr="/dev/tty5") else: -- 1.7.6.4

2 1

[f16-branch] Pull grub-efi and efibootmgr into the package list as needed.
by Peter Jones 06 Oct '11

06 Oct '11

EFIGRUB needs to pull in the appropriate packages, which are grub-efi and efibootmgr. --- pyanaconda/bootloader.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/pyanaconda/bootloader.py b/pyanaconda/bootloader.py index f6d828f..ca43868 100644 --- a/pyanaconda/bootloader.py +++ b/pyanaconda/bootloader.py @@ -1345,6 +1345,7 @@ class GRUB(BootLoader): class EFIGRUB(GRUB): + packages = ["grub-efi", "efibootmgr"] can_dual_boot = False _config_dir = "efi/EFI/redhat" -- 1.7.6

2 2

[f16-branch 1/2] LANG_DEFAULT lives in lang.c.
by Ales Kozumplik 06 Oct '11

06 Oct '11

Related: rhbz#731356 --- loader/lang.c | 4 +++- loader/lang.h | 4 +++- loader/loader.c | 3 +-- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/loader/lang.c b/loader/lang.c index 24878a7..6b1fa8e 100644 --- a/loader/lang.c +++ b/loader/lang.c @@ -47,6 +47,8 @@ #include "../pyanaconda/isys/isys.h" #include "../pyanaconda/isys/log.h" +const char *LANG_DEFAULT = "en_US.UTF-8"; + /* boot flags */ extern uint64_t flags; @@ -368,7 +370,7 @@ static char * getLangNick(char * oldLang) { return lang; } -int setLanguage (char * key, int forced) { +int setLanguage (const char * key, int forced) { int i; if (!languages) loadLanguageList(); diff --git a/loader/lang.h b/loader/lang.h index d4b61dd..168ffa3 100644 --- a/loader/lang.h +++ b/loader/lang.h @@ -32,7 +32,9 @@ struct langInfo { int chooseLanguage(char ** lang); char * translateString(char * str); -int setLanguage (char * key, int forced); +int setLanguage (const char * key, int forced); int getLangInfo(struct langInfo **langs); +extern const char *LANG_DEFAULT; + #endif /* _LANG_H_ */ diff --git a/loader/loader.c b/loader/loader.c index 2c5eb51..eedf439 100644 --- a/loader/loader.c +++ b/loader/loader.c @@ -128,7 +128,6 @@ int num_link_checks = 5; int post_link_sleep = 0; static int init_sig = SIGUSR1; /* default to shutdown=halt */ -static const char *LANG_DEFAULT = "en_US.UTF-8"; static char *VIRTIO_PORT = "/dev/virtio-ports/org.fedoraproject.anaconda.log.0"; @@ -2059,7 +2058,7 @@ int main(int argc, char ** argv) { if (loaderData.lang && loaderData.lang_set == 1) { setLanguage(loaderData.lang, 1); } else { - setLanguage("en_US.UTF-8", 1); + setLanguage(LANG_DEFAULT, 1); } /* FIXME: this is a bit of a hack */ -- 1.7.6.4

3 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel October 2011