Stateless kickstart problem
by Christopher Hotchkiss
I got back to work trying to get this up and running today. I ran into
the following problem, I needed a proxy to download the stateless
packages properly, the section of the kickstart is below.
f.close()
def do_chroot (commands):
quoted = re.sub ("'", "'\\''", commands)
os.system ("chroot /mnt/sysimage sh -c '%s'" % quoted)
do_chroot ("http_proxy=\"http://192.168.0.246:3128\" yum -c
/tmp/stateless.yum.conf install stateless-client")
### Now launch the real bootstrap
sys.path.append ('/mnt/sysimage/usr/share/stateless/')
import bootstrap
bootstrap.run('aware-of-vacuity.boston.redhat.com', 'Test42')
Is this correct? Secondly, what I replace the boston.redhat.com line with?
--
Christopher Hotchkiss
(813)960-9273
http://www.post227.org
19 years, 4 months
konsole/gnome-terminal/xterm, UTF-8 and backspace
by Doncho N. Gunchev
Hello,
when a shell/python script reads input from the user in konsole and
gnome-terminal it I enter non-ascii characters (ex: "Проба", "Test" in
English) backspace does not work correct. For example:
--- cut ---
$ echo -n "Test: "; read a; echo "[$a]"
Test: Проба
[ You can paste this, then hit backspace 4 times to get the next line ]
Test: П
[ Press Enter here and you get ]
[Про]
$ _
--- cut ---
If I erase one character I get '[Проб�'
Text editing in bash and mc works, but in python 'starts to erase'
the '>>> ' prompt. In xterm instead of cyrilic letters I get spaces.
I wanted to enter a bug, but I don't know against what to. Looks like
backspace erases single bytes, while these letters consist of 2. Can
someone direct me and confirm it?
--
Regards,
Doncho N. Gunchev Registered Linux User #291323 at counter.li.org
GPG-Key-ID: 1024D/DA454F79 http://pgp.mit.edu
Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79
19 years, 5 months
Elektrified X.org released (was: X configuration paradigm, and a proposal)
by Avi Alkalay
For people that still don't know the Elektra Project
(http://elektra.sourceforge.net), it provides an alternative back-end
for text configuration files. So instead, for example, the
human-readable-only xorg.conf file, we'll have a hierarchy of
key/value pairs easily and precisely accessible by X.org and also any
other programs through an API or command, and human beings too.
Same concept as GConf, but designed for system-wide use.
We've been working on X.org source code to do exactly what we just
described above. And it is ready for use, tested even with very
complex X.org configurations. A patched X server will convert your
xorg.conf file automatically, even the most complex ones, including
non-documented parameters.
It is available at
http://sourceforge.net/project/showfiles.php?group_id=117521
http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=1...
You'll find there the patch against X.org source, the patch against
Fedora Core 3 RPM spec file (to see how to build it), and the README
file, which is pasted in this e-mail bellow.
We'll write patches for other software, and everybody is invited to
join this integration effort.
Thank you,
Avi Alkalay
Elektra Project <http://elektra.sf.net>
----------------------README-------------------------
ELEKTRIFIED X.ORG: PRECISE AND PROGRAMATICALY EASY X CONFIGURATION
Your X server has to work with your installed video card, monitor, find
your font server and dirs, modules, extensions, drivers, plugins.
You have to tell him how to integrate it all through its xorg.conf file.
If you need to change something, you start a text editor and use your
human brain and eyes to find the correct line, understand it, have the
skills to change it, and change it in order to work.
This is good for advanced technical guys, but very bad for people that
don't have this skills, and in fact, don't really want to. He just
wants to change the screen resolution to make that projector work with his
laptop, and go ahead with his sales presentation. This is just an example.
The point is: it is very difficult to make simple programs or scripts
that make simple changes to X configuration. Another example is a monitor
vendor that wants to support X, and for this he'd like to provide easy
installation of his product, without having to ask his user to read
documentation about horizontal Sync, and vertical refresh rates. For him
again is difficult to write some simple software that preciselly changes X
configuration to work correctly with his product.
The xorg.conf file (as most Unix configuration files) was designed for
human beings.
The Elektra Project (http://elektra.sourceforge.net) introduces a new way
to handle configurations through a clean API (or command line
tool) that accesses atomic configuration data, into a standarized
hierarchycal tree of key-value pairs. It is similar to GConf, but
designed for system-wide use, which also implies it does not have
dependencies.
And this is what this patch is about: to make the X server look for its
configurations into a machine-ready tree of key-value pairs, instead of
the human-ready xorg.conf.
So where you had to look for "Device radeon" into a "Section Device",
with the key/value tree, X and other programs can look for it
preciselly at
system/sw/xorg/current/Devices/Videocard0/Driver = radeon
Where you once had to "vi" your "Section Monitor", now X and other
programs can do it accessing the keys:
system/sw/xorg/current/Monitors/Monitor0/HorizSync = 31.5 - 48.5
system/sw/xorg/current/Monitors/Monitor0/VertRefresh = 40.0 - 70.0
system/sw/xorg/current/Monitors/Monitor0/ModelName = IBM T40 LCD Panel
system/sw/xorg/current/Monitors/Monitor0/VendorName = IBM
system/sw/xorg/current/Monitors/Monitor0/Options/dpms
Where once the salesman above had to "vi" the Screen Section to change
the resolution, color depth, etc, a program can help him accessing:
system/sw/xorg/current/Screens/Screen0/Displays/00/Depth=24
system/sw/xorg/current/Screens/Screen0/Displays/00/Modes=1024x768
And so on....
We believe an elektrified X server can leverage more plug-and-play
configurations, providing configuration power to HW vendors in a
very simple way, and making users experience less painfull.
BEHAVIOR OF AN ELEKTRIFIED X SERVER
A patched X server will look for its configuration keys under the
namespace:
system/sw/xorg/current first, then if not found it tries
system/sw/xorg
If not found, it will default to some xorg.conf file, parse it, and store
in its internal structures, then convert and commit it to a set of
keys under system/sw/xorg/current, and reload these keys.
So you get automatic one-time conversion from xorg.conf to the
hierarchycal configuration key/value pairs
Very complex examples of xorg.conf files were tested for conversion. Even
undocumented configuration parameters (because the original source was
used as the reference).
The Elektrifyied X server also works for the Red Hat Graphical Boot,
where you still don't have mounted partitions, network, etc.
ELEKTRIFING X.ORG
You'll need the elektra-devel package installed in order to build X with
Elektra support.
1. Download and unpack X.org source code from
2. Download the xorg-x11-6.8.1-elektra.patch file from
http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=1...
3. Apply it:
~/src/xc$ cd ..
~/src$ patch -p0 < xorg-x11-6.8.1-elektra.patch
~/src$ cd xc
~/src/xc$ # ...configure your build in host.def
4. Enable the patch:
~/src/xc$ echo "#define UseElektra" >> config/cf/host.def
5. Build X.Org
You'll find the new X server as file xc/programs/Xserver/Xorg .
The patch will add the following files:
xc/programs/Xserver/hw/xfree86/parser/
elektra.h (exported methods)
elektra.c (key fetching and X structs integration business logic)
xorg-example.conf (a very complex conf file to test conversion)
xelektrify.c (cmd to convert xorg.conf->keys and vice-versa)
README.Elektra (this file)
And it will instrument
xc/programs/Xserver/hw/xfree86/common/xf86Config.c::xf86HandleConfigFile()
to trigger the one-time conversion, and key fetching logic.
And instrument the Imakefiles for correct builds:
xc/programs/Xserver/hw/xfree86/parser/Imakefile
xc/programs/Xserver/hw/xfree86/common/Imakefile
xc/programs/Xserver/Imakefile
If "#define UseElektra" is not present in host.def, the patch is
completelly disabled, and you'll get a binary-identicall built as before
applying the patch. All patched code are surrounded by #ifdefs.
ELEKTRA MEETS X.ORG SOURCE CODE
or how we wrote the patch....
X.org has an xorg.conf parser that takes this steps to handle
configuration:
1. Lexically parse the xorg.conf file
2. Put each Section info in an equivalent struct
3. Encapsulate all structs together and pass them to a validator
4. Use structs to define X behavior
This process is triggered by the xf86HandleConfigFile() method from
xc/programs/Xserver/hw/xfree86/common/xf86Config.c
Each xorg.conf Section has an equivalent structure defined in
xc/programs/Xserver/hw/xfree86/parser/xf86Parser.h
and the lexycall analyzer code to parse each Section is under
xc/programs/Xserver/hw/xfree86/parser/
A fully parsed file has its equivalent structures encapsulated in a
parent XF86Config struct. We have:
struct XF86ConfModuleRec for the "Section Modules"
struct XF86ConfMonitorRec for the "Section Monitor"
struct XF86ConfDeviceRec for the "Section Device"
etc...
These structs are a pure computer representation of the text in each
Section, so the methods under "parser/" convert text to structs, and
the structs to text. This is how original X.org source handles xorg.conf.
The Elektrification add methods that act in steps 1 and 2 above. And also
include methods to convert each struct to a KeySet. Both old (xorg.conf)
and new (Elektra) ways to get configuration information can live together
and they are actually used to automatically convert xorg.conf to keys. So
at the first time you'll run your elektrified X server, it will:
1. Not find configuration keys (because it is the first time)
2. Parse xorg.conf into structs
3. Convert structs to Keys
4. Commit the keys to key database
5. Reload configurations from the key database
See the behavior in the previous section.
After assembling the XF86Config C structure, X will decode all its info
into more practicall parameters for its further operation.
As a side note, with a key/value pair configuration hierarchy paradigm,
the XF86Config assembling code (the parser) could be avoided, making X
look for its configurations in a programatically easier, yet
human-readable, configuration organization.
We worked at the parser level to keep compatibility and to not go too
deep in X.org source code.
http://elektra.sourceforge.net
The Elektra Project
Avi Alkalay
November 2004
19 years, 5 months
rawhide report: 20041208 changes
by Build System
New package slib
platform independent library for scheme
Updated Packages:
a2ps-4.13b-42
-------------
* Tue Dec 07 2004 Tim Waugh <twaugh(a)redhat.com> 4.13b-42
- Fixed configure.in.
- Fixed m4 files.
- Apply patch from bug #122699 to fix "too many includes" error.
ethereal-0.10.7-2
-----------------
* Tue Dec 07 2004 Radek Vokal <rvokal(a)redhat.com> 0.10.7-2
- changed mozilla default browser to htmlview (#142107)
- warning: update doesn't overwrite default preferences in ~/.ethereal/preferences
evolution-data-server-1.0.2-6
-----------------------------
* Tue Dec 07 2004 David Malcolm <dmalcolm(a)redhat.com> - 1.0.2-6
- Amortize writes to a local cache of a webcal calendar, fixing further aspect of #141283 (upstream bugzilla #70267), as posted to mailing list here:
http://lists.ximian.com/archives/public/evolution-patches/2004-December/0...
(The groupwise part of that patch did not cleanly apply, so I removed it).
ftp-0.17-23
-----------
* Tue Dec 07 2004 Thomas Woerner <twoerner(a)redhat.com> 0.17-23
- fixed mget with runique (#79367)
gcc4-4.0.0-0.14
---------------
* Tue Dec 07 2004 Jakub Jelinek <jakub(a)redhat.com> 4.0.0-0.14
- update from trunk
- fix DEPENDENCIES_OUTPUT handling (#140921)
- fix libstdc++.so symlinks (#141985)
- make sure target's LOAD_EXTEND_OP or lack thereof doesn't influence
gcj -C output (#141730)
gnome-bluetooth-0.5.1-8
-----------------------
* Tue Dec 07 2004 Harald Hoyer <harald(a)redhat.com> - 0.5.1-8
- added requires for python-abi
* Tue Dec 07 2004 Harald Hoyer <harald(a)redhat.com> - 0.5.1-7
- split package into app, libs and devel
iputils-20020927-19
-------------------
* Tue Dec 07 2004 Radek Vokal <rvokal(a)redhat.com> 20020927-19
- return values fixed - patch from suse.de
kernel-2.6.9-1.1020_FC4
-----------------------
* Mon Dec 06 2004 Rik van Riel <riel(a)redhat.com>
- apparently Xen works better without serial drivers in domain0 (#141497)
libgnomedb-1:1.0.4-4
--------------------
* Tue Dec 07 2004 Caolan McNamara <caolanm(a)redhat.com> 1.0.4-4
- #rh142098# missing return
python-2.4-2
------------
* Mon Dec 06 2004 Jeff Johnson <jbj(a)jbj.org> 2.4-2
- db-4.3.21 returns DB_BUFFER_SMALL rather than ENOMEM (#141994).
- add Provide: python(abi) = 2.4
- include msgfmt/pygettext *.pyc and *.pyo from brp-python-bytecompile.
rpmdb-fedora-1:4-0.20041208
---------------------------
selinux-policy-strict-1.19.11-1
-------------------------------
* Fri Dec 03 2004 Dan Walsh <dwalsh(a)redhat.com> 1.19-11-1
- Merge with upstream
selinux-policy-targeted-1.19.11-1
---------------------------------
* Fri Dec 03 2004 Dan Walsh <dwalsh(a)redhat.com> 1.19-11-1
- Merge with upstream
shadow-utils-2:4.0.3-56
-----------------------
* Fri Dec 03 2004 Adrian Havill <havill(a)redhat.com> 2:4.0.3-56
- tweak max allowed length of user/group names to sizeof(ut_user)-1
to allow for '\0' termination
- add lastlog support for >4gb (#125445)
* Tue Nov 23 2004 Bill Nottingham <notting(a)redhat.com>
- ghost lastlog here (#139539)
* Tue Nov 16 2004 Adrian Havill <havill(a)redhat.com> 2:4.0.3-42
- change MAXMEM static limit on group count to dynamic (#125510)
- re-allow "$" as last char for the sake of samba (#132782)
- don't strip binaries for debuginfo
util-linux-2.12a-20
-------------------
* Tue Dec 07 2004 Steve Dickson <SteveD(a)RedHat.com> 2.12a-20
- Corrected a buffer overflow problem with nfs mounts.
(bz# 141733)
* Wed Dec 01 2004 Elliot Lee <sopwith(a)redhat.com> 2.12a-19
- Patches for various bugs.
* Mon Nov 29 2004 Steve Dickson <SteveD(a)RedHat.com> 2.12a-18
- Made NFS mounts adhere to the IP protocol if specified on
command line as well as made NFS umounts adhere to the
current IP protocol. Fix #140016
19 years, 5 months
Kudzu and automatic detection
by Kjetil Nygård
In my office I have a printer which I don't have at home. And everytime
I come to the office, kudzu want to "configure" the printer. And when I
come home, it want to remove the printer again.
I also noticed that if I plugged the printer after starting the machine,
and kudzu has not configured my printer, the printer works just fine.
So I wonder if this is an unnecessary kudzu-configuration which should
be fixed?
My printer is a HP laserjet 2200dn connected through USB. I run Fedora
Core 3, and of cause CUPS is the printer daemon.
--
Kjetil Nygård
Tlf: +47 41 47 43 37
19 years, 5 months
HELP!!! hda error!!!
by Giovanni Alzetta
Well, one my friend have 2 hard disk. So I installed fedora linux on the
second. Now when I start fedora I see a hda system control than an error and
something like this:
"enter root password"
"or type ctrl+d"
if I press ctrl+d I reboot the computer. If I enter the root password I'm in a
"read only" file system, so I can't do anything.
I do that: install fedora, at the start I saw a hda control, but nothing of
strange, than copy some files from windows to fedora and erase those files in
windows. Than I reboot the computer and BOOM!!! The error come.
So I tried with knoppix to copy files from fedora to windows, but I can't go
in the home, I just can't read files from that home.
So there are two solutions:
-how to read files with knoppix?
- how to erase the error with fedora
Thanks for help!!!!!! (please answer!)
bye bye
P.S. I think that the hard disk of the my friend don't work very well, because
windows become crazy every 2-3 months. (and sorry for my bad English)
19 years, 5 months
adventures in booting
by David Zeuthen
Hey,
So, I've looked a bit more into the booting process and how to optimize
it. Mostly based on the discussion triggered by Owen's boot poster
challenge, here
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00447.html
and also some experiments that I did - basically replacing rhgb with gdm
as described here
http://www.redhat.com/archives/fedora-desktop-list/2004-November/msg00066...
What I've done is a bit crude - I've replaced init(1) with a shell
script based on /etc/rc.d/rc.sysinit and tried to optimize specifically
for my system: IBM Thinkpad T41 laptop with a Pentium M processor at
1600MHz along with 512MB of RAM.
The results are pretty good I think, here is the general time line made
with a wallclock
00: exit grub; start booting the kernel
04: kernel prints audit()
11: initrd is mounted; Red Hat nash visible
mount / ro (normal initrd procedure)
13: start bootchart logging; start readahead of approx 193MB files
sleep until readahead is complete
24: readahead done; now
create /dev and modprobe (in background)
mount / rw, enable swap
start xfs
startx as user davidz in background
start messagebus
start hald
start acpid
start NetworkManager
32: X claims the display
34: GNOME desktop banner
40: GNOME desktop is usable (Nautilus desktop, panel fully populated)
Here is a bootchart made with the bootchart software from Ziga Mahkovec:
http://people.redhat.com/davidz/bootchart.png
You may notice that I also start firefox after login and it starts very
very fast - that's because readahead loads all files used by Firefox -
in earlier experiments I've also added files from OpenOffice.org to
readahead and that meant I could start up OpenOffice.org Writer in about
three seconds. More below.
I've made the following observations
1. The kernel patch, linux-2.6.3-printopen.patch, wasn't really working
well for me - it reported far to few files - instead I added a
printk() to fs/namei.c:link_path_walk()
(disclaimer: I don't know much about the kernel so there may be a
better solution than this).
2. The data captured from link_path_walk() was massaged into a list
of unique files to preload and sorted on sectors.
3. While capturing the data link_path_walk() and before processing
I went through all the menus in the GNOME desktop (to make sure
their icon and desktop files would be added to the list) as well as
loading Firefox. The list contains 5189 unique files - 231 of these
from my home directory - 103 of these from gconf in my home
directory and 302 from gconf in /etc. 2267 were .png files and
814 of them were .desktop files. 488 files had ".so" in their name.
There was a total of 193MB of files (which says something about
the footprint of the GNOME desktop on Fedora :-/)
4. Doing the readahead really helped the time from startx till a
usable desktop - less than 10 seconds!
5. Doing readahead on the 5189 files took about 45 seconds on my
system, mostly because the files were scattered around the disk.
Since I had a spare partition 17GB partition, I did this:
a. format spare partition as ext3
b. copy all readahead files to spare partition (193MB)
c. copy rest of files from main partition to spare partition
(about 9GB)
Now the readahead is down to 11 seconds which averages out to
be 18MB/s. On the other hand, I can still see (using fileblock)
that the files in the readahead is still scattered out and hdparm
says I should be able to get 33.87 MB/sec with no seeks.
6. I made a hack to cache /dev (a dev.tar file) and the list of modules
to load. This could be used in production if the kernel could give
us basically a hash value for the kobject hierarchy representing
the hardware (perhaps even a 'tree /sys |md5sum' would suffice).
This shaved some seconds of as well.
7. A number of things was started in parallel - I found that doing
readahead while running modprobe wasn't helping anything; in fact
it contributed negatively to performance (a bit to my surprise, I
guess because the kernel was busy).
8. readahead on the right files is A Good Thing(tm). Booting my system
without readahead on the partition with the readahead files scattered
took 58 seconds (compared to 39 with readahead on the optimized
partition)
http://people.redhat.com/davidz/bootchart-without-readahead-scattered.png
and without readahead on on the optimized partition it took 43
seconds
http://people.redhat.com/davidz/bootchart-without-readahead-nonscattered.png
again compared to 39 seconds. As an added bonus, the readahead
makes sure that e.g Firefox loads fast; all .png and .desktop files
are in place for when using the menus. As mentioned, one could put
very big apps like e.g. OO.o in the readahead set.
So, I think these numbers are good and there's still some room for
improvement; e.g. it takes ten seconds from grub to when the initrd is
mounted - surely the kernel can boot faster? It's after all 25% of the
time spent from grub until I have usable desktop.
The bad thing is that this approach is highly specific to my system (and
thus why I'm not posting an RPM with it :-), however I think it clearly
shows where improvements should be made; here are some random thoughts
a. We should keep track of files being loaded and maintain the
readahead fileset as appropriate. printk() doesn't seem like the
right solution; perhaps a system daemon using inotify or the
kernel events layer is the road ahead? This would enable us to
readahead the KDE stuff if the user is e.g. using KDE a lot.
b. ext3 should support operations for moving blocks around; e.g.
optimize around the readahead fileset - when idle the system should
rearrange the files to facilitate faster booting
c. the start_udev and kmodule process could be cached as I did above
d. The whole init(1) procedure seems dated; perhaps something more
modern built on top of D-BUS is the right choice - SystemServices
by Seth Nickell comes to mind [1]. Ideally services to be started
would have dependencies such as 1) don't start the gdm service
before /usr/bin/gdm is available; 2) the SSH service would only
be active when NetworkManager says there is a network connection;
/usr from LABEL=/usr would only be mounted when there is a volume
with that label and so forth. Also, such a system would of course
have support for LSB init scripts.
(This is probably a whole project on it's own so I'm omitting
detailed thinking on it for now)
Thanks a lot to Ziga Mahkovec for the bootchart software - it's been
very useful.
Have fun,
David
[1] : http://www.osnews.com/story.php?news_id=4711
http://www.gnome.org/~seth/blog/2003/Sep/27
19 years, 5 months
Re: Stale NFS Filehandles and Permission Denied
by Hugh Caley
BTW, upgrading to 2.6.9-1.6_FC2smp seems to have fixed our stale NFS
Filehandle problem.
Hugh
--
Hugh Caley | Unix Systems Administrator | CIS
AFFYMETRIX, INC. | 6550 Vallejo St. Ste 100 | Emeryville, CA 94608
Tel: 510-428-8537 | Hugh_Caley(a)affymetrix.com
19 years, 5 months
mplayer
by Si Jones
Hi,
I was trying to package mplayer on amd64.
I have downloaded all the deps etc, but when i do rpmbuild -
bb /usr/src/redhat/specs/mplayer.spec etc.
I get an error of X11 not found.
Is this because I use to have nvidia drivers in and i have removed
them??
If it is, is there anyway of repairing this?
Cheers,
Si
19 years, 5 months
