Replacing the boot kernel in the installer
by Bill Crawford
I successfully installed F8 at home, but I've been unable to get the
installer to run on my Aspire here at work. It fails due a problem
with the sata_sis driver, which is fixed in the latest F7 kernel
update so I assume the current F8 kernel is fine too. Is it possible
to simply boot from a different kernel (and update the modules in the
initrd, of course) and run the installer? Or, if I need to update the
stage 2 image as well, how do I point at the updated stage 2, and can
I do so while still proceeding to fetch the install packages off the
network?
16 years, 4 months
RFE: prevent broken rawhide network install due to repo change
by Andrew Farris
RFE: prevent broken rawhide network install due to repo change
Problem: network installs will currently fail if the repository changes during
the installation, which can take 2-4 hours or more, and changed files are
removed from the repo, making anaconda fail to download the expected version of
that changed file
If a user has started a network install then any change in files not yet
downloaded will completely break that install. The user will see anaconda fail
to get the file 10 times, then suggest rebooting and starting the install again.
This wastes time and network traffic, since the repository could have only
changed the last file that installer needed... and they will subsequently
download them all again (this time hopefully missing the period the repo changes).
To solve the problem all that is necessary is for the repo to hold all changed
files for a period (probably 3-4 hours for the typical install time) so that any
installs that have begun before the changes to the repo data can finish. The
depsolving in anaconda does not recognize a change in the repodata and attempt
to resume the install with the new data, so either 1) that needs implemented, or
2) the mirrors need to hold the files for awhile even though the repodata no
longer has them included.
Would it be possible for the repository data to be created while excluding any
files that were updated during that build, leaving the old files out of
listings, but actually leave the file present and accessible by direct request?
This would improve the network install experience because it is difficult to
anticipate when the repo changes will break the install process for \insert
random mirror\.
The caveat to the solution is that the repository needs to be cleaned some time
later by another process which would know which files are now old (not included
in the repo data) and delete them. In the meantime (again suggesting 3-4 hour
overlap) there will be a slightly larger disk space needed because of the
duplication.
Any mirrors that sync to rawhide while there are duplicated files should have
those files already (from the day before) and would only fetch the new files.
Those mirrors could either 1) keep the duplicate files all day until the next
sync, or 2) have their own cleaning process such as a cron job. In either case,
anyone requesting an installation while the duplicates are there would not be
effected.
I've run into this problem several times when doing network rawhide installs,
especially if started late night in California (meaning the repo build and
mirror syncs are likely to overlap the install).
I am unaware obviously of where the infrastructure would need to be changed to
handle this, though I assume a combination of koji and elsewhere (both in
building the repo data and afterward in deleting the temporarily remaining files).
If there is anything already in place to solve/work on this issue point me in
the right direction, because its not working. ;)
Also I think this is only an issue with rawhide since the release mirrors keep
the original released files and then updates go elsewhere. Development on the
other hand has issues with the changes because files disappear.
I'd be happy to move this suggestion to where it belongs (bugzilla against ?)
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
16 years, 4 months
Why does gdb now give lots of warnings?
by Neal Becker
Here is an example:
Starting program: /usr/bin/python
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/e8/abaa654dc4b17b75c06c866898a17ea06f2bcf.debug
[Thread debugging using libthread_db enabled]
[New process 16964]
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/96/c005fcc474ab8b0d1aa41267111de2f0b647b0.debug
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/cd/19bdc5e57f1a00b2c7b4d6c6d1e3882d199ef9.debug
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/72/0ad477c75be7d7cbc97c0a6f443746dda98341.debug
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/ea/5b2fb654311e2dc8beacf2f19c1c6d172ba93d.debug
Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
[New Thread 46912496361856 (LWP 16964)]
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/c2/9e344ac739785880a9e002d775c40d812ce16e.debug
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/e0/db9d3ab515cf9c9b43b4aab98441eb0c5834f4.debug
warning: Missing the separate debug info file: /usr/lib/debug/.build-id/07/4b927efdfa0dbc5902b22369afae444d4f8c4f.debug
16 years, 4 months
FESCo Meeting Summary for 2008-01-24
by Brian Pepple
= Members Present =
* Brian Pepple (bpepple)
* Jason Tibbitts (tibbs)
* Dennis Gilmore (dgilmore)
* Bill Nottingham (notting)
* Warren Togami (warren)
* Kevin Fenzi (nirik)
* Tom Callaway (spot)
* Josh Boyer (jwb)
* Jesse Keating (f13)
* Christian Iseli (c4chris)
= Absent =
* Christopher Aillon (caillon)
* David Woodhouse (dwmw2)
* Jeremy Katz (jeremy)
== Summary ==
=== Bug Work-flow Proposal ===
* FESCo approved Jon Stanley's bug work-flow proposal, although
with a change to item #7 in the life-cycle of a bug section.
Instead of setting NEEDINFO in some cases, all bugs that are
pushed to stable will be closed. Luke Macken will be removing
the ability to not close a bug on stable push in bodhi.
=== FedoraBugs Group ===
* Long discussion on what to require, and who sponsors people to
the fedorabugs group. For now, it was decided that cla_done
would be required, and that Jon Stanley & John Poelstra will
handle the sponsoring. Once the Fedora Account System2 is
implemented this will be revisited, since most of this could be
automated.
=== F9 Feature Process ===
* FESCo approved the following feature for F9:
* http://fedoraproject.org/wiki/Features/Upstart
* http://fedoraproject.org/wiki/Features/GCC4.3
IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-01-24.html
Later,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
16 years, 4 months
Live images and fonts
by Sebastian Vahl
Hi.
After some time I've done a new test spin of my kde live images today. What
I've experienced is that most of the former installed fonts are missing. A
diff between my released rawhide live image for KDE 4 and my current one is:
baekmuk-ttf-fonts-common
baekmuk-ttf-fonts-gulim
cjkunifonts-uming
dejavu-lgc-fonts
jomolhari-fonts
kacst-fonts
liberation-fonts
lohit-fonts-bengali
lohit-fonts-gujarati
lohit-fonts-hindi
lohit-fonts-kannada
lohit-fonts-oriya
lohit-fonts-punjabi
lohit-fonts-tamil
lohit-fonts-telugu
paktype-fonts
sazanami-fonts-gothic
The full diff is available here: http://pastebin.org/16733
In the past they were pulled in from comps.xml (or
livecd-fedora-base-desktop.ks). So my question here is: Is this intended?
My full package list of my current live image:
http://fedoraproject.org/wiki/SebastianVahl/CurrentPackageList
For the record: I'm using this comps version:
http://ftp.tu-chemnitz.de/pub/linux/fedora-enchilada/linux/development/i3...
Sebastian
16 years, 4 months
Re: Yum, Proxy Cache Safety, Storage Backend
by chasd
Les Mikesell wrote:
> I'm missing something here. A cache is only going to resend what
> it got
> the first time. If the first user got the right thing, so will the
> second. If the first user got something wrong, don't blame the cache
> for it.
There can be a problem when the cache holds on to the "bad" data for
too long, serving that to other clients that ask for it later. The
way things are now, a cache has a good reason _not_ to look for fresh
data when the end users would like it to. In that case, some blame is
on the cache, and every once in a while I have to kick squid in the
butt because of that. Adjusting the tools used to update machines and
to create the repos in order to help the cache make better decisions
is a Good Thing.
General comments about this thread :
The default update scheme is to use multiple mirrors managed by an
intelligent script. Works for a lot of people, but not everyone.
I think there needs to be an assumption that some kind of
administrator is going to have to opt out of that default and opt
into any caching scheme. At that point the issue is how easy do we
make it for the administrator to do that ? What kind of changes need
to be made on the clients, and what additional infrastructure changes
need to be made ?
Instant Mirror is very easy right now, at least if you have any chops
as an admin. Install a rpm, twiddle the config, set up a host in DNS,
distribute a repo file for the clients. My view on the intent of Mr.
Togami's OP is to accept that level of ease-a-tude-inosity and make
the solution less error prone. Making the opt-in easier would only be
a bonus.
The way I use and configure squid for general web access caching
would not make it a good cache for updates. I would rather have a
separate update caching mechanism rather than try to make our squid
cache do double duty. I would want more control over that update
cache than whatever squid would supply automatically.
Charles Dostale
16 years, 4 months
Re: InstantMirror needs a rethink
by chasd
> Today InstantMirror is pretty useful for home and small office
> mirrors,
> but its limitations make it unsustainable without manual
> intervention of
> the sysadmin.
I am using it now so our ~20 systems don't waste T-1 bandwidth.
> - Synchronization/locking of multiple connections downloading the same
> file is awkward and broken.
My use is low enough volume I haven't run into that.
> - There is no good way to clean up aborted tmp files.
Haven't had any.
> - There is no good way to know what are old files that need pruning.
With disk space relatively cheap here in the USA, and a new Fedora
every ~6 months, I just rm -rf the old release directories after I
migrate to the new version. I don't worry about multiple updates to
the same package, except for giant ones like OOo.
Another outgrowth of the Fedora release cycle is I usually only apply
security updates, or updates that fix specific problems I experience.
There is no sense for me to download and apply updates for hardware I
don't use, for example. I figure I'll pick up application updates in
6 months when the next release drops, I usually don't need the update
_right now_.
I don't need a rsync of a mirror, just a cache of the updates I
choose to apply because those specific updates will be applied across
multiple machines.
> - There is no good way of keeping track of the "Big Picture" of its
> own
> cache, "least recently used" knowing what files were unpopular locally
> and should be pruned.
I don't have a need for that functionality with my usage.
> Any thoughts?
Ignoring the temp file and multiple connection issues, the
synchronization part could be solved by InstantMirror writing some
type of log file or access popularity file. A separate cron script
could read in that data and prune the unpopular / duplicate files.
From a separate message :
> 1) Origin HTTP mirrors can be configured to serve "Cache-Control:
> max-age=0" in HTTP headers whenever they serve repodata/* files. This
> can become a standard recommendation for all Fedora mirrors. Does
> anyone know how to configure Apache to do this?
<Directory /var/ftp/pub/fedora/linux/releases/8/Everything/x86_64/os/
repodata>
Header always set Cache-Control: max-age=0
</Directory>
Probably the best way would be to put this in a .htaccess file for
each repodata directory as that directory is created. The .htaccess
file would have a local directory directive instead of a full path
( createrepo ? ). Otherwise the main apache config ( or a file in
conf.d ) would need to be updated / added each time a release is made
( or an arch is added).
> 2) Squid refresh_pattern can use a regex to override max-age=0 for
> repodata/* files. I haven't figured out exactly what the syntax is
> for
> this. Anybody know squid.conf?
refresh_pattern \/repodata\/.* 0 0% 0
> <hno> Apache do not have this same abstract internal layer, and
> writing
> a mod_disk_cache replacement which keeps a mirror type file structure
> should be pretty easy thing to do.
This seems to best leverage existing code / apps, although I am not
in a position to help here.
Charles Dostale
System Admin - Silver Oaks Communications
http://www.silveroaks.com/
824 17th Street, Moline IL 61265
16 years, 4 months
gnome jhbuild trouble
by Dr. Michael J. Chudobiak
I can't get gnome jhbuild to install on F8:
$ jhbuild sanitycheck
Could not find DocBook XSL Stylesheets in XML catalog
How can I fix that? An earlier version of jhbuild worked, and I believe
I have all the required packages installed...
- Mike
16 years, 4 months
kernel update not updating grup.conf correctly
by Richard Hally
Is this a bug? When updating the kernel on my rawhide installation
yum/rpm adds the stanza to the grub.conf file but does not copy the
root=LABEL=/1 parameter correctly as shown below. What could be wrong?
Richard
title Fedora (2.6.24-0.167.rc8.git4.fc9)
root (hd0,5)
kernel /vmlinuz-2.6.24-0.167.rc8.git4.fc9 ro root=LABEL=/
initrd /initrd-2.6.24-0.167.rc8.git4.fc9.img
title Fedora (2.6.24-0.164.rc8.git4.fc9)
root (hd0,5)
kernel /vmlinuz-2.6.24-0.164.rc8.git4.fc9 ro root=LABEL=/1
initrd /initrd-2.6.24-0.164.rc8.git4.fc9.img
16 years, 4 months
