upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
1 year, 4 months
autoconf breakage on x86_64.
by Sam Varshavchik
I don't know the right way to fix this, but something is definitely broken;
and something needs to be fixed, one way or the other. The question is what
exactly needs to be fixed.
Consider something like this:
LIBS="-lresolv $LIBS"
AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no))
Here's what happens on x86_64:
gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5
/tmp/ccW7EeDX.o(.text+0x7): In function `main':
/home/mrsam/src/courier/authlib/configure:5160: undefined reference to
`res_query'
collect2: ld returned 1 exit status
configure:5147: $? = 1
configure: failed program was:
[ blah blah blah ]
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char res_query ();
| int
| main ()
| {
| res_query ();
| ;
| return 0;
| }
The same exact test on FC1 x86 will work.
The reason appears to be that you have to #include <resolv.conf> on x86_64
in order to succesfully pull res_query() out of libresolv.so. You don't
need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC
does not include any headers, but uses a manual prototype.
So, what now?
16 years, 8 months
DMRaid in Fedora devel
by Mark Wormgoor
Hi,
Attached are three patches that I made to get Fedora-devel to install on
a bios sata raid-0 system (Sil 3112 on Abit AN7). It uses Heinz
Mauelshagen's dmraid for detecting the disks.
The first patch is against Anaconda. It removes the raid disks from the
isys disklist and replaces them with the mapper device. The patch
requires the full (not enable-mini) dmraid binary in the stage 2 image.
I tested the patched Anaconda in install, upgrade and rescue mode (text
and gui) and had no problems on my system.
The second patch is against mkinitrd. It adds /sbin/dmraid.static to
the initrd if necessary and updates the initscript. The
/sbin/dmraid.static binary is not yet a part of the current dmraid rpm,
so you need to provide your own.
The third patch is against rc.sysinit so that dmraid.static is run at
boot. Again, you need the full dmraid binary under /sbin/dmraid.static
(not enable-mini) because the rc.sysinit script uses the testmode first
before enabling the mapper devices.
I now have a Fedora-devel system booting from my two raid-0 disks.
Unfortunately, there is no bootloader for /dev/mapper devices. There is
a patch against lilo to make it work on devmapper devices here
(http://www.saout.de/misc/) and Eric Agsjö has a patch to make it work
with raid-1 devices here
(https://www.redhat.com/archives/ataraid-list/2004-October/msg00007.html). I am still using lilo under FC1 (using the medley.o module) and that works for me.
I hope someone finds these patches useful; it would be very nice if FC4
would install on and boot from these bios ide raid devices without too
much hacking.
Kind regards,
Mark Wormgoor
--
***************************************************************
* |\ /| | /| / Mark Wormgoor *
* | \ / | | / | / mailto:mark@wormgoor.com *
* | \/ |ark |/ |/ormgoor http://www.wormgoor.com/mark/ *
***************************************************************
18 years, 1 month
Emacs cvs snapshot packages available
by Jens-Ulrik Petersen
I finally got round to packaging a snapshot of current
development Emacs from CVS. Noone knows when the next
actual release of Emacs will be, but there are many
new features and changes: improved utf-8
and gtk2 support in particular.
See
http://people.redhat.com/petersen/emacs/
for more details.
Enjoy and please report any problems directly to me
(ie not to bugzilla or the emacs-devel list:),
Jens
18 years, 2 months
Improving security
by Hans de Goede
Hi,
I just read this interesting article on lwn:
http://lwn.net/Articles/106214/
(lwn subscriber only)
This talks about things like:
1 Stack Smash Protection
2 PAX (alternative Exec Shield)
3 Position Independent Executables.
Stack Smash Protection sounds like a cool feature to me. I don't know
what the performance impact is, but as a developer even if it is to slow
to use by default I would love to have it intergrated into the gcc
shipped by Fedora to make debugging easier.
PAX uses tricks to get a non executable stack, and assignes random
addresses to PIE executables, which Fedora already has in the form of
Exec Shield, good! But if I undertand it correctly PAX does more for
example also make data pages non executable, this might be something
worth looking into.
PIE we already have, good!
Regards,
Hans
18 years, 4 months
ia32e, er EM64T that is...
by Jesse Keating
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What are the chances of getting an ia32e specific kernel in the x86_64
version of Fedora Core 3? We're starting to ship Nacona based systems,
and we have always done Fedora Core pre-installs. While the x86_64
kernel of FC2 works now, I thought it was in some sort of 'compatible
64bit' mode rather than ia32e or em64t specific mode.
I guess a better question: With kernel 2.6, is there any need to have a
specific ia32e vs amd64 kernel? Are all the differences worked out at
runtime and thus a non-issue? Thanks.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBPJpX4v2HLvE71NURAgLOAJ41i+nTykxeQlOs+SG0Lxu297RM/gCfQ30X
DzP7D/wWGZN0T8LiXAlZFpY=
=7oGl
-----END PGP SIGNATURE-----
18 years, 5 months
Some encryption-related projects
by W. Michael Petullo
I have several encryption-related projects that I like to advertise
on this list every once in a while in hopes of attracting interested
developers or testers. Since we are just beginning work on Fedora Core
4, now seemed like a good time to mention them.
1. Encrypted swap.
This is a prerequisite for many different disk encryption techniques.
See [1] for a good example of why this is necessary (potential shortcoming
of Apple's FileVault). See Red Hat bug #127378 for some discussion about
this, including a proposed patch for initscripts. The patch has not been
scrutinized very much yet, so is only meant to encourage discussion at
this point.
2. Encrypted root filesystem.
Red Hat Bug #182479 discusses adding support for an encrypted root
filesystem to Fedora. The bug contains a patch for mkinird that
facilitates this. Eventually it would be nice to see support in anaconda
for this, but #182479 is the first step.
3. Pam-keyring.
The pam-keyring PAM module unlocks a GNOME keyring for a user using that
user's login password. The idea behind pam-keyring is to make using
GNOME keyrings as transparent as possible. Pam-keyring is available
at http://flyn.org/projects/pam_keyring/index.html.
4. Command line gnome-keyring tool.
GNOME bug #155681 proposes an addition to gnome-keyring. The
gnome-keyringtool utility is a program that manipulates keyrings from
the command line. I originally wrote gnome-keyringtool so that it could
be assigned SELinux privileges and used by pam-keyring. This avoids
assigning additional privileges to various login programs.
5. Automounting encrypted removable filesystems.
I would like to see encrypted removable filesystems handled as
transparently as other removable media. Red Hat bug #133461
discusses this a bit. I have done some experimentation with
this and have a prototype working. However, my work contains
a large kludge to get HAL to acknowledge dm-crypt filesystems
properly. Documentation of this shortcoming may be found at
http://freedesktop.org/pipermail/hal/2004-September/001051.html and
http://marc.theaimsgroup.com/?l=linux-kernel&m=109937418210973&w=2.
[1] Archive of bugtraq mailing list message:
http://securityfocus.com/archive/1/367116/2004-06-24/2004-06-30/0
Date: 06/25/2004
Subject: Mac OS X stores login/Keychain/FileVault passwords on disk
Author: Matt Johnston
--
Mike
:wq
18 years, 6 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
18 years, 6 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
18 years, 6 months
