pc hangs when I exit X after yesterdays rawhide update
by Jason Dravet
Ever since I updated to yesterdays rawhide (Feb 9th) I cannot logout of X
windows without my PC stopping to respond. When I exit X I get a black
screen, but I cannot type anything. The only two things that work are the
power button and CTRL-ALT-Delete. If I press the power button the PC shuts
down like it should, if I CTRL-ALT-Delete the PC reboots. I would open a
bugzilla about this but to which package would I assign it? I have a tyan
tiger 100 motherboard (S1832), P3 850Mhz CPU, 384MB RAM, Adaptec 2930U2 scsi
card with 2 western digital 9GB scsi hard drives, 1 ide cdrom burner, a
number 9 Revolution IV video card with 32MB of RAM, and a SGI 1600SW LCD
panel. As I said eariler this started with yesterdays rawhide update and
todays rawhide does not fix the problem. What can I do to give you enough
information to fix the problem?
Thanks,
Jason
18 years, 3 months
Linux-HA?
by Naoki
Hey all,
Does Fedora plan on shipping Linux-HA ( heartbeat )? Or is there a
replacement / similar package which is otherwise recommended ?
18 years, 3 months
No rawhide release just yet
by Jesse Keating
There is an error in the run, and since I'm rebuilding a lot of packages
I want to wait until the packages are done before manually running the
rawhide release. Sorry for the delay.
--
Jesse Keating
Release Engineer: Fedora
18 years, 3 months
caution with latest kernel + glibc
by Ulrich Drepper
Those who are running the current rawhide kernel and glibc (and
coreutils or those trying to compile glibc for themselves) might find
that their kernel locks up. One bug in this area (I think there is more
than one) is fixed by the patch in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178558
The 1909 kernel and later will likely have the patch. For now it might
be best to use glibc-2.3.90-30 and nothing later or alternatively live
with the lockups for today. The fixed kernel is hopefully in tomorrow's
rawhide.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
18 years, 3 months
JOnAS on FC5
by Andrew Haley
JOnAS works well on FC5 test 2 w/updates.
The bottom line:
Tests Failures Errors Success rate Time
1837 29 9 97.93% 1565.078
(The best set of results we've ever had, AFAIK)
The conformance test results are at
http://people.redhat.com/aph/current-jonas-on-gcj-conformance-test-result....
The only thing I changed in the default setup was the stack size. (We
must get this change in the RPM!)
I had planned to work on this a few days, but Building JOnAS on an FC5
test box turned out to be no big deal at all!
The only real problem I had was with medor and jorm, which seem to
depend on each other. So, I downloaded the following packages from
devserv.devel and rebuilt both:
jorm-2.4.3-1jpp_2fc.1.noarch.rpm
jorm-javadoc-2.4.3-1jpp_2fc.1.noarch.rpm
medor-1.4.4-1jpp_3fc.noarch.rpm
medor-expression-1.4.2-1jpp_3fc.noarch.rpm
medor-expression-javadoc-1.4.2-1jpp_3fc.noarch.rpm
medor-javadoc-1.4.4-1jpp_3fc.noarch.rpm
I also had to install there FC5 packages:
tomcat5-servlet-2.4-api.i386 5.0.30-8jpp_9fc
jdom.noarch 1.0-1jpp_2fc.1
werken.xpath.noarch 0.9.4-0.beta.9jpp_2fc
velocity.noarch 1.4-3jpp_3fc
struts.i386 1.2.4-2jpp_5fc
tomcat5-jasper.i386 5.0.30-8jpp_9fc
tomcat5.i386 5.0.30-8jpp_9fc
jrefactory.noarch 2.8.9-3jpp_1fc.1.1
xjavadoc.noarch 1.1-1jpp_3fc
adaptx.noarch 0.9.6-1jpp_2fc.1.1
mockobjects.noarch 0.09-12jpp_4fc
concurrent.noarch 1.3.2-2jpp_1fc.1
tomcat5-webapps.i386 5.0.30-8jpp_9fc
jgroups.noarch 2.2.6-1jpp_3fc
classpathx-mail-monolithic.noarch 1.0-4jpp_4fc
castor.noarch 0.9.5-1jpp_1fc.1.1
tomcat5-admin-webapps.i386 5.0.30-8jpp_9fc
xdoclet.noarch 1.2.2-2jpp_4fc
tanukiwrapper.i386 3.1.1-4jpp_3fc.2
jakarta-commons-cli.i386 1.0-6jpp_5.fc5
And the progress of rebuilding JOnAS and all of its dependencies went
like this:
15:18 monolog
15:25 dtdparser
15:26 objectweb-deploysched
15:26 asm
15:27 fractal
15:28 perseus-cache
15:30 perseus-dependency
15:32 perseus-distribution
15:32 perseus-concurrency
15:58 nanoxml
16:00 oldkilim
16:02 jonathan-core
16:17 jacorb
16:22 jonathan-jeremie
16:24 carol
16:25 howl-logger
16:27 joram
16:41 perseus-pool
16:42 perseus-fos
16:43 jorm
16:44 medor
16:45 medor-expression
16:46 jotm
16:47 jorm-rdb-adapter
16:47 objectweb-anttask
16:48 perseus-persistence
16:49 p6spy
16:50 jonathan-rmi
16:50 gif89encoder
18:24 jonas
Andrew.
18 years, 3 months
Massive rebuild in progress
by Jesse Keating
After a late night of staging, I have 900~ packages queued up to rebuild
for the gcc4.1 snapshot and glibc changes. These will be submitted to
our build system throughout the day as low priority jobs. Some will be
finished for tonight's rawhide push, but not all of them. There are
still some packages that should be rebuilt that are not in my list, but
those package maintainer's have expressed desire to bump their packages
themselves. Over the next couple days I'll be checking package
timestamps and keeping an eye on what else needs to build. Please bear
with the churn and the very lengthy rawhide reports.
--
Jesse Keating
Release Engineer: Fedora
18 years, 3 months
XGL
by Benjy Grogan
I hear that in a week or so Novell will be releasing the source code to XGL
for X11 7.0. Will it be possible to have XGL available in Extras for FC5?
I'm guessing it's one of those new X11 modules that v7.0 is all about. But
I know little about XGL and would like to test it out to know more. It's
going to be in NLD 10 in a few months.
Benji
18 years, 3 months
New printer admin tool design for comments
by Tim Waugh
I sent a previous draft of this to fedora-maintainers. Having updated
it from the very useful feedback I received, I'm now sending this to a
wider audience for more review.
(Also: anyone who feels like helping to implement any of this, speak
up!)
Tim.
*/
A NEW PRINTER ADMINISTRATION TOOL
=================================
Draft 3, Feb 10th 2006
Tim Waugh
1. PROBLEMS
--------
1.1. Alchemist
---------
There are various reasons for redesigning the current
system-config-printer configuration tool. A brief summary is:
* the XML file format it uses is inflexible
* the configuration options are limited to those common to both
spoolers we were shipping at the time the XML format was decided
* it is VERY SLOW: you can't *modify* configuration, only write out
entirely new configurations (i.e. trigger the back-end)
* again, due to the XML format chosen, we are tied to the foomatic
database in such as way that we absolutely require foomatic to know
about the printer before we can configure it.
Even if you have the manufacturer's PPD file, there is very little
you can do to get your printer working.
* changes made using the CUPS configuration interface
(http://localhost:631/), or any other method external to
system-config-printer, are not reflected in the XML file and so
cannot be modified and often get overwritten.
* new CUPS backends such as hpfax or cups-pdf cannot be used without
patching system-config-printer.
1.2. Stateless Linux
---------------
An extra consideration to take into account when re-designing the
administration tool is Stateless Linux. The requirement from that
project is that users may specify their own (private) queues for
submitting jobs to.
For example, a particular user may want to print to an SMB printer,
with certain default settings such as which input tray to use. With
Stateless Linux, this queue definition will be tied to the user's home
directory so that they can log in on any stateless workstation and be
able to print to their queue.
2. SOLUTIONS
---------
2.1. Stateless Linux
---------------
A Stateless Linux configuration has /etc read-only. This causes a
problem with local printers: automatic detection of a local printer
needs to add a queue. This runtime configuration means that the CUPS
configuration files, currently stored in /etc/cups, should be moved to
/var/run. Since /var/run does not preserve data over a reboot, this
should only be done for stateless configurations. One possible
trigger for this special stateless behaviour would be for CUPS to
detect that /etc is read-only -- or else, it could be a configuration
option.
2.1.2. (intentionally left blank)
2.1.3. Per-user queues in system CUPS daemon
-------------------------------------
At session start, for each per-user queue defined by the user, the
CUPS daemon is notified that a per-user queue needs to be created (if
it does not already exist). This could be done using D-BUS.
Firstly, the CUPS daemon is told to remove all per-user queues for
this user IF they are not processing jobs. Then, for each per-user
queue the CUPS daemon is given the PPD file from the user's home
directory, and the URI for the printer, as well as the queue name.
Given this information, the CUPS daemon will then:
* copy the PPD into its ppd directory
* set up a queue if it does not already exist
This new queue will NOT be advertised in IPP "browse" broadcasts.
Jobs may only be submitted to this queue by the owning user at the
local machine, i.e.:
cupsd.conf: -----------
| Allow from localhost |
| AuthClass Basic |
----------------------
printers.conf: ------
| AllowUser the_user |
--------------------
In addition to the current "certificates" method of
avoiding the need to type in a password when submitting jobs, we could
patch CUPS to use D-BUS for the same purpose.
REMAINING QUESTIONS:
Should steps be taken to avoid accidentally forming round-robin
classes with other per-user or remote queues of the same name as the
user-defined queue? One suggestion is to use 'user-$uid-$queue' as
the real name, but present it to the user as '$queue'.
2.2. Better configuration method
---------------------------
It will solve many of the configuration issues mentioned in 1.1 if a
new printer administration tool would configure CUPS directly rather
than maintaining a separate configuration file. There are two main
ways of doing this:
* using the command-line tools such as lpadmin and lpoptions
* using IPP to communicate with the CUPS daemon directly
Using IPP directly will offer more flexibility. Some of the more
subtle changes we will need to make may not be possible using
command-line tools alone. Additionally, using IPP for configuration
allows the possibility of configuring remote CUPS instances using the
graphical tool, and this will be important for print servers that do
not have a full graphical interface installed.
Additionally, the user interface must provide a method for the
administrator to enable and disable queues. Some queues can get
disabled as a result of an error detected by the backend, and there is
currently no means of re-enabling the queue using the existing
graphical interface.
2.2.1. Configuration items not possible using IPP
------------------------------------------
In order to configure items in /etc/cups/cupsd.conf, the file must be
altered and the CUPS daemon told to re-read its configuration. The
IPP interface does not offer any way of configuring settings in this
file -- since the ability to use the IPP interface at all is part of
that configuration.
Things that the administration tool may need to change that reside in
cupsd.conf:
* access controls for each local queue
* whether to enable CUPS browsing (both listening and broadcasting)
* what network interfaces to listen on
Previously these settings were stored in alchemist and written out to
cupsd.conf, over-writing any previous conflicting settings. It is
very important that cupsd.conf be the canonical place for these
settings. The existing settings should be shown to the user so that
they can be modified. Editing cupsd.conf by hand must not cause any
problems with the administration tool.
2.3. IPP authentication
------------------
There are two options:
* The admin tool runs with user privileges. An authentication dialog
box will appear when configuring the CUPS daemon using IPP. Some
mechanism similar to consolehelper needs to be devised in order to
avoid the need to keep asking for passwords. (This is my preferred
alternative.)
-or-
* The admin tool uses consolehelper as before, but can run in
unprivileged mode in order to configure only per-user queues.
2.4. Modifying PPD options
---------------------
The new printer administration tool will be responsible for providing
a graphical interface for changing the "InstallableOptions" (such as
whether a duplexer is installed) and the default queue options such as
duplexing, page size, and print quality. All of these options are
stored in the PPD file representing the queue, and this is modified by
the CUPS daemon when it receives the IPP request to do so.
The GTK+ print dialog will also allow these settings (except those in
the InstallableOptions group) to be over-ridden on a per-job basis.
The user interface will be largely the same, and there is opportunity
for code-sharing here. Some aspects of PPD option representation
(such as grouping and constraints) require careful implementation in
the user interface, and so it would be better not to duplicate this
work.
2.5. Page size as a special case
---------------------------
When adding a new queue for an automatically detected printer, an
appropriate default page size should be chosen based on the system
locale.
CUPS will already do this for us when a new queue is created, so there
is no action to be taken.
2.6. Persistent settings
-------------------
Unplugging a USB printer and re-attaching it must retain the settings
it had prior to unplugging. This needs to be handled by HAL.
2.6.1. Simple persistence
------------------
One easy method is to avoid automatically removing queues at all.
Instead, the queue could be disabled (i.e. cupsdisable) when the
device is unplugged, and enabled when inserted.
For this to be feasible, it must be possible to identify a
newly-inserted printer as being the same one that had been unplugged
previously. Many USB printers provide a serial number in their IEEE
1284 Device ID string which can be used for this purpose.
If there is no serial number available, the manufacturer and model
strings could be used to identify the correct queue to act upon.
If there is no (disabled) queue identified, a new queue would be
created as in 2.7 "Automatic detection", below.
The proposal that persistent settings be handled by simply
disabling/enabling queues rather than removing queues altogether means
that persistent settings can be managed entirely by HAL.
2.6.2. More advanced persistence
-------------------------
Once the new administration tool works well, the persistent settings
idea could be made more advanced. See 2.10.3 "More advanced
persistence" for how this could work.
2.7. Automatic detection
-------------------
A local printer will be automatically detected by HAL and an
appropriate queue created for it.
2.7.2. Remote discovery
----------------
For remote printers, the common types are: SMB, JetDirect, and
IPP/CUPS. IPP/CUPS instances can broadcast browse packets to
facilitate automatic detection for clients. We already make use of
this.
For JetDirect printers there is no way of automatically finding them
other than probing each address on the subnet.
For SMB printers there may very well be a means of actively
discovering remote queues automatically, perhaps by querying the
domain server and then each named SMB host in turn. However, I think
authentication details (such as username/password) need to be
configured when you create a queue, rather than when a job is
submitted -- the information is placed into the URI for the queue.
I am not aware of a passive discovery method for SMB.
It has been suggested that UPnP could be used for remote discovery of
some newer network printers.
2.7.1. Method for creating a queue
---------------------------
The vast majority of printers provide IEEE 1284 Device ID strings to
identify themselves. These strings provide: manufacturer name, model
name, description, and command sets understood by the device. For
example:
MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus Photo
830U;CLS:PRINTER;DES:EPSON Stylus Photo 830U;
or:
MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,PCLXL,POSTSCRIPT;MDL:HP LaserJet
1200;CLS:PRINTER;DES:Hewlett-Packard LaserJet 1200;MEM:8MB
The foomatic RPM package provides a database of printers and printer
drivers. It stores IEEE 1284 Device ID strings for a large number of
printers. It also stores information about which drivers may be used
with a given device, and which of those is recommended.
When a local printer is detected, its IEEE 1284 Device ID string
should be retrieved. For parallel port printers,
/proc/sys/dev/parport/*/autoprobe provides this; for USB printers,
/sys/devices/*/*/usb*/*/*/ieee1284_id provides it in newer kernels (>=
2.6.15-1.1826.2.6.FC5).
The foomatic database should then be consulted to look up a printer
model based on the manufacturer and model IEEE 1284 Device ID
fields. (NB: printconf currently uses some tricks to match printer
models for those whose IEEE 1284 Device IDs are not known to
foomatic).
If no printer is found, the command set field should be examined. If
"POSTSCRIPT" is found, the generic PostScript driver can be used. If
"PCLXL" is found, the generic PCL 6/PCL XL driver can be used. If
"PCL" is found, the generic PCL 3 driver can be used. Otherwise, a
manufacturer's PPD is required from the user.
If the printer was found, and there is a manufacturer-provided PPD
available for the recommended driver for it (a PPD is specific to a
printer model and driver combination), the queue is set up
automatically and needs no user intervention.
If there was no manufacturer-provided PPD (including the case where
the printer was not found in the database), the user should be asked
to see if they have a manufacturer-provided PPD file.
On creating the queue, the page size needs to be adjusted
appropriately for the locale.
2.7.2. Code sharing
------------
IEEE 1284 Device ID strings may also be provided by remote printers
that are SNMP-capable. There are some subtleties in creating a new
queue, such as altering the page size.
As a result, the mechanism for creating a queue outlined in 2.7.1
needs to be used for:
a) automatically detected printers
b) adding printers using the admin tool
c) adding per-user remote queues
2.8. Admin tool for creating system queues and per-user queues
---------------------------------------------------------
If it makes sense from a user interface perspective, it would be
useful to combine the facility for creating and editing per-user
queues into the admin tool, since a lot of the same functionality is
needed.
Additionally, in order to keep the queue creation logic in one place,
it might very well make sense for HAL to hand off the IEEE 1284
information from a detected local printer to the admin tool rather
than trying to configure a queue on its own.
(NB: This bit needs someone with some user interface sense:)
Perhaps the interface could have two tabs, one for "System print
queues" and another for "My print queues". Browsed queues would not
be shown.
For each tab, the queues could be listed exactly as they are in the
GTK+ print dialog (including number of jobs in queue, and the
location).
Queue sharing will be allowed for "System queues" (as currently) but
not for "My queues".
Editing a queue will allow the same things to be edited as currently:
which driver to use; driver options; queue options such as banner
pages.
This combined printer administration tool would be launched by the
GTK+ print dialog's "Add printer" button.
2.8.1. Ability to specify queue URI
----------------------------
The new administration tool must allow the user to specify a queue URI
in the same manner as the http://localhost:631/ interface does. In
other words, a list of possible URIs obtained using the IPP equivalent
of '/usr/sbin/lpinfo -v', with the possibility of editing the URI.
2.9. Error handling
--------------
The foomatic we are shipping for Fedora Core 5 provides a special CUPS
backend: beh (backend error handler). It allows the administrator to
modify the behaviour of the backends when errors are encountered:
whether to try again, how many times to do that, and so on.
It would be useful to be able to offer this in a user interface. The
per-user queues would mean that an unprivileged user would even be
able to modify error handling for their own jobs.
2.10. Future directions
-----------------
The main aim is to re-implement the current limited functionality of
system-config-printer in such a way that it is no longer tied to
alchemist. Having an administration tool which can configure CUPS
directly and interact with queues created by other means (such as
http://localhost:631/ or the lpadmin command) will allow future
enhancements.
Some such enhancements are listed below.
2.10.1. Ink levels and maintenance functions
------------------------------------
Although there is no unified way of doing so yet, a future enhancement
to the administration tool would be to allow the administrator to
check ink levels and perform functions like aligning/changing
cartridges, for printers that have such a facility.
2.10.2. Classes
-------
Once the new administration tool works well, support could be added
for configuring collections of printers (CUPS classes), where a job
sent to a class is directed to the first available printer in that
class.
2.10.3. More advanced persistence
-------------------------
HAL could (call a program which would) maintain a simple database
mapping printer models to PPDs.
When a printer is unplugged, the associated queue would be located and
the PPD retrieved from the CUPS daemon. The manufacturer and model
would be remembered and stored with the PPD.
When a printer of the same manufacturer and model is inserted at a
later time, the remembered PPD would be used rather than consulting
foomatic (see 2.7.1 "Method for creating a queue").
This will preserve:
* which driver to use
* the default values for options
* the InstallableOptions (such as whether a duplexer is available)
2.11. Beyond scope
------------
There are other things that need fixing with printing, such as status
feedback to find out if the ink has hit the paper. These are beyond
the scope of the administration tool.
18 years, 3 months
artifacts in gtk apps and slowness updating
by Peter Robinson
Hi All,
Is it just me seeing artifacts in various gtk components on rawhide
with all updates? Its been there a while. I'm seeing it in things like
progess bars and the forward and back buttons on firefox. Also when I
switch to a terminal window it seems to take forever to refresh and
show the contents of the window.
Peter
18 years, 3 months
dmraid comments and a warning
by Dax Kelson
It is understood that 'real' hardware RAID controllers are better than
'fake' RAID controllers commonly built into motherboards and cheap PCI
cards.
However, the 'fake' RAID is *extremely* common and is often used by
someone already running Windows who then wants to free up some room to
install and dual boot Linux.
The (single?) advantage of the 'fake' RAID over Linux software RAID is
no effort redundancy in booting because of the RAID BIOS integration.
==The Issue==
Once a RAID1 (mirror) is has been defined and built inside of the BIOS
the utility you *never ever* want to boot to half of the RAID. If you
do, and you go back to booting to whole activated RAID, you get massive
file corruption.
Currently it is very easy for this to happen.
I have been testing the dmraid support out on a test box with onboard
Nvidia "nforce4" RAID and two mirrored drives. Twice I've gotten
completely scrambled data and had to re-install from scratch.
--Event One--
I installed rawhide a few weeks ago. Anaconda automatically activated
the motherboard RAID. Cool! Inside of Anaconda's disk druid I elected to
go the manual route and not setup LVM. Instead I defined:
/dev/mapper/nvidia_foo1 -- /boot
/dev/mapper/nvidia_foo2 -- swap
/dev/mapper/nvidia_foo3 -- /
GRUB installed fine, and all the packages installed OK. It rebooted OK,
and I did a 'yum -y upgrade'. So far so good (or so it seemed).
The standard root=LABEL=/ was used on the kernel command line and what
happened is that it booted up to one side of the mirror. All the updates
and new packages (including a new kernel install which modified the
grub.conf) activity just happened on that one side of the mirror.
When I rebooted, GRUB read a garbled grub.conf because at that stage ist
*is* using a 'activated' RAID (via the RAID BIOS support). I couldn't
boot.
So I booted to the rescue environment, which did the right thing and
activated the RAID and it even mounted the filesystems. When I went and
inspected the files though, anything that got touched while it booted to
the one side of the mirror was trashed.
Result = dead Linux system
--Event Two--
With the benefit of the experience of event one. I did a new install,
but this time I let Anaconda's disk druid do the "auto setup" thing and
create a LVM. I figured that LVM using device mapper and dmraid would
always "do the right thing" in regards to *always* using the activated
RAID partitions as the PVs.
This seemed to be the case. I installed and booted OK. I verified that I
was using LVM and inspected the physical volumes using 'pvdisplay'.
I was greeted with:
# pvdisplay
--- Physical volume ---
PV Name /dev/dm-1
[snip]
Looks good! Seeing /dev/dm-1 instead of /dev/mapper was a surprise, but
I agree with the idea.
This was two or three weeks ago and I have been using the system and
doing daily 'yum -y upgrade'.
Yesterday or the day before I did the 'yum -y upgrade' and rebooted. On
the GRUB screen it would not boot to the first listed kernel, with a
read error on the kernel binary. Looking at the GRUB menu, I noticed
some missing boot options (I had previously added memtest86 and there
was a menu item to boot a Windows Partition). I was able to get a boot
going choosing one of the older kernels.
On bootup I noticed an error flash by something to the effect of "LVM
ignoring duplicate PV".
I ran pvdisplay and saw:
# pvdisplay
--- Physical volume ---
PV Name /dev/sda1
[snip]
It booted off one half of the mirror. It must have done the same on some
previous boot.
For fun (the Linux install was dead now of course, it just didn't know
it) I ran a 'yum -y upgrade'.
On a reboot GRUB listed 3 kernel choices, all of them gave read errors.
Result (a) = dead Linux system
Result (b) = inaccessible Windows system (if you don't know how to use
the GRUB command line)
==Comments==
There needs to be more checks in place to prevent booting off of one
half of the mirror, or at a minimum only allowing a read-only boot on
one side of the mirror. Dead systems are no fun. Loosing your personal
data is hell.
This isn't purely a Linux problem. Any operating system using fake RAID1
needs to be robust in this regard. I saw a Windows box using 'fake'
motherboard RAID and the motherboard BIOS got flashed which reset the
"Use RAID" setting to 'off'. Then Windows booted off of half the RAID.
This was noticed and the BIOS setting was turned back on and a boot
attempted. Massive corruption and a dead Windows system was the result.
To Window's credit I haven't seen it accidentally boot off of half the
RAID as long as the BIOS RAID was turned on and the drivers installed.
The rules are:
1. Don't boot off half of the RAID1 in read-write mode
2. If rule 1 is violated, don't ever again boot using the RAID1
- If you can abide by rule 2, you can do so indefinitely
3. There is no way to recover from a violated rule 1 without
reinstalling.
Dax Kelson
Guru Labs
18 years, 3 months