Re: RHN Updates
by Jef Spaleta
Gilles J. Seguin wrote, somewhere in the digest:
>The third item require that peoples with a minimum of training
>be able to install and play with a package.
Yes i understand that submitting useful bugreports doesnt take much in
the way of training...neither does breaking a working system, without
fully understanding the consquences of your actions :->
But I'm more concerned about getting into a situation where the
convience tools...the point and click tools like up2date...start getting
features where people can easily install 'testing' packages on top of
full releases..without having to stop and think about what they are
doing...when they have no intention of actually being a part of the
testing process...and don't have a clue about how to recover if the
testing packags are broken.
I firmly believe a large segment of the user population do not read
documentation before they start pointing and clicking their way through
applications...and a lot of those people are download junkies....there
is a kneejerk reaction to upgrade when a version number higher than what
you have installed is available. You give people some form of easy to
use 'expert' or 'testing' options to up2date and rhn, and a lot of them
will assume they know enough to use these option and will just point and
click their way to a broken/insecure system ..without making any attempt
to understand what 'testing' really means. I think this ultimately
undermines the service rhn provides...but that's my opinion, luckily I
don't have to make business decisions for Red Hat...how i balance the
trade-offs in service rhn provides is thankfully not what people base a
business model on.
This is one of those trade-off things. If you give rhn options to
provide 'testing' packages on top of a normal release, sure this will be
marginally more convient for the people who want help test packages. But
it also provides a mechanism where less technically competent people can
easily install things that break their systems..and these less
technically competent people, might not understand their system's deep
dark underbelly(commandline) well enough to make a recovery attempt if
things break. Its a convience..versus risk tradeoff. I'm inclined to
think that if you are running testing packages...you should be familiar
enough with the commandline to use rpm/yum/apt at the commandline to
download testing packages, so that if things break down, you are
competent enough to make a stab at fixing things. Its not in everyone's
best interest to run testing packages, and i think having testing
packages for full releases in rhn would end up encouraging people to do
things, not in their best interest...degrading the trust and service rhn
provides to a large segment of the rhn userbase.
Its one think to provide a clear beta release with a separate isoset
with a seperate rhn beta channel. Providing 'testing' updates in rhn as
an options for a full release...is something different..and makes it
really easy for people to get into situations where they screw up
running systems just because they wanted the latest and greatest version
number.
-jef"rolling releases are to avoided...on pain of death"spaleta
20 years, 9 months
Experiences with severn and 2.6 kernel on a dell laptop.
by Laur Ivan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
First of all, although in beta stages, Severn is a nice distribution. I like
the laptop stuff in it (really nice).
A brief description of the hardware: Dell X200, A07 bios update, 640MB ram,
1150 minipci wireless, firewire cdrw/dvd.
First install:
I had SuSE previously installed on it with a brief attempt on getting RH 9.0
prior the that. I downloaded the Severn CDs, plugged the first one in the
firewire cdrom, and poof, stopped in "loading sbp2". so, for the lack of
better option and time, left SuSE on. ...but lasted only one day.
After reading more on the net (sbp2 had a hack which if loaded, removed and
loaded again would make everything work nicely) and submitting a bug on
redhat's bugzilla (which was linked to an internal bug in the meantime), I
decided to try again. this time with no probing devices. poof again in the
same spot. Subsequently I tried the *extreme method*: let the initial image
load and remove the firewire connection while starting the installer. ..and
voila! it worked. Of course, it wouldn't load the sbp2 module (hang again),
but I decided I could live without for the install time. So off I went with
the network install...
The install worked like a charm, the system rebooted and I was pleasantly
surprised by the graphical boot. By that time, I knew that reiser is not a
"supported" fs and it's in a separate RPM, so I went to install it and my
home dir could be mounted OK. A note is that I'd prefere that redhat's tool
for viewing partitions to actually list all the mountable partitions in the
local disk, not only the entries in fstab (especially when logged as root).
Notes on "services"
The sound is OK. The sound applications are not. I understand that there are
issues with licensing various codecs (mp3), but one should be provided with
some lines: "we don't have it, but you can get it here and compile it
yourself". IMHO, xmms is rather useless without mp3 support since most
windows tools rip to MP3 instead of ogg. The same story for video.
Fortunately, these days one can get xine or mplayer and have a fully featured
media player (I wish some would make a functional skin for xine where I could
easily browse for files and add/dnd them...). Which leads me to the graphics:
i830 is not what you call a gaming GPU, but it plays videos & stuff pretty
well via SDL.
I pleasantly was surprised vile testing a divx to find out that the CPU was
only at 40% usage... and it's only a p3/800.
The network: at installation level, I was really disappointed that I could
not load the wireless to do the install (that would have been cool), but no
one died of fatigue while plugging in a network cable (..?). After the
install, wow! I got the wireless up & running in no time and the gnome applet
is really cute :). So off I went with rawhide updates and what not. But about
this, later.
Power management: well, I'm impressed again. I managed to get the battery
lasting more that 2 hours while configuring stuff & compiling the 2.6 kernel.
The next test I guess would be to check a dvd/divx. Few minuses though:
- when I launched the battery applet (gnome), it crashed with no explanation.
KDE would have displayed "battery/power info not available" and the crossed
battery icon in the tray. Loaded the acpi modules, and got the applet running
with the exclamation mark and red battery (unavailable). No big surprise here
because I had to patch the Suse kernel with a custom DSDT.
- acpid doesn't load anything useful (ac, battery, processor etc). One has to
get those loaded by hand. Rather unpleasant, especially since a fix would be
quite easy via shell...
Otherwise, the system looked quite stable (except for mc segfaulting now and
then)
V2. The 2.6 odyssey
As I mentioned before, my old Suse had the acpi patch for forcing the kernel
to load a custom DSDT table. So I tried to do the same thing to my 2.4.21
nptl kernel. no luck. The addresses in the DSDT table I had were messed up
(prolly because of my buils update) so I had to rebuild the table. a big
difference from my experiences with the SuSE kernel is the raw (default)
configuration of the kernel, fhich does not reflect at all the contents of
the compiled RPMs. later I found out that there's a configs directory with
custom configurations which can be loaded and subsequently altered. Also, in
SuSE, I could just change bits in the config, do a make modules
modules_install, and everything would be OK. big no-no in severn. The source
rpm installes itself as 2.4.21...nptl, but the makefile has a "custom"
appended. So, whatever you build from now on it's going to be another kernel
altogether. I can understand it as safety feature for dummies along the lines
"don't delete the default kernel". But one should make a note somewhere..
As my 2.4.21 was a very frustrating experience (hundreds of warnings about
multiple defined macros and what not) ending in errors and everyone on the
lis was teribly excited about 2.6, I said to myself "why not?". Therefore,
deciding to live on the bleeding edge's bleeding edge, I got arjan's 2.6
rpms. And here is where my problems start and end...
First, no graphical boot. Well, no big deal, in fact it's better I ran into
it now, not after compiling a kernel. I patched the kernel with a custom dsdt
for acpi and went to compiling the kernel. Few warnings and everything
compiled fine. make modules_install created the "custom" set of modules, and
make install generated the initrd and grub entry nicely. Reboot... bummer! no
graphical boot (again). then no X/gdm. figured out that it was the mouse
missing. so i loaded mousedev. X started, the cursor was fixed smack in the
middle of the screen. I had a doc telling me to look in /proc on input
devices and note the handler of the synaptics device (eventX). Found the
device, but no handler. My first thought was: silly me, must be a param
somewhere... after a lot of debug messages and other things in the psmouse
module, i loaded (more by accident) the event module, and voila, the
synaptics device had a handler. After this, the mouse works nicely (still
have to tinker with my settings a bit). One should document that you actually
need the event module with a ps2 mouse.
Another thing is my wifi has to be loaded now with a "ifup eth1" (previously
the init sequence would start it), but I can live with it
That's how far I've got. I still have some issues: I get all the modules
loading ok, but I can't access my firewire cdrom. Do I need some special
config/module? Where should I look? I had a look in the kernel docs with no
luck.. :(
All in all, a nice, stable system (no data loss, no hard locks although the
shutdown produces a sad system beep in 2.6 which wasn't there in 2.4).
Cheers,
Laur
- --
Laur Ivan Tel : +353-1-6674336
Software Design Engineer eMail: laur.ivan(a)corvil.com
Corvil Ltd.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
iD8DBQE/L5lyrIaFaLsloSMRAiubAJsF3tU6BGNcJVLYBdp6TwLBKe8Q6ACfXgQk
z6xfNjPr1Prh9el6/3+JVeE=
=r1gY
-----END PGP SIGNATURE-----
20 years, 9 months
Kudzu in hiding during boot?
by guran
Hi
I am having some problem with my old ISA SB soundcard so I was trying to
understand from messages what went on during installation.
When during boot, in terminal by Ctrl-Alt-F5 I found that part of the duration
in boot was kudzu showing its messages about printer and soundcard which were
never shown in that fancy graphics.
How do I shut off the graphic shit?
regards
guran
--
Red Hat Linux Beta 9.0.93 kernel-2.4.21-20.1.2024.2.1.nptl
Only in a society that has 'a priori' defined what is true
can the result from the evolution of life be defined false.
20 years, 9 months
USB mice in Severn?
by Jason Longland
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm just wondering about how to get my USB intellimouse explorer working in
Severn? it used to work flawlessly in RH9 but since I just installed Severn
any time I try to boot the USB mouse gets switched off and Severn refuses to
detect otherwise. Just on a slightly related side note, will Severn support
Bluetooth input devices such as M$'s bluetooth kb+mouse or bluetooth
intellimouse explorer?
Jason Longland
*********************************************************************
All messages originating from me are digitally signed to
ensure authenticity.
If any message is not signed it could be due to one of the following to
reasons:
1. my email client isn't working and I've had to use the web browser
2. it isn't from me and could be a virus
All content contained herein is copyright (or copyleft...) of the sender.
All messages are scanned using the latest virus definitions
for Norton Antivirus 2003 prior to sending.
*********************************************************************
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
iQA/AwUBPy7zLE9XUfpwf1ScEQK+pACffW0AuzfQ0hGEC9NY4eCR0Tf8YbkAoPYC
EScyofQH9B9EPNGMihh2mkxn
=SpMy
-----END PGP SIGNATURE-----
20 years, 9 months
Re: RHN Updates
by Jef Spaleta
Matthew Winter wrote:
>I would like to see RedHat enhance the RHN into a subscription based
>Package Install / Update / Search system.
I think redhat is going to have to enhance rhn in someways...for the
idea of the RHL-project to take off...where you really can get 3rd party
addons from something like fedora or freshrpms (or horrors of horrors
proprietary addons) for the rhl releases. How exactly the full catelog
of rhl project packages and related 3rd party addons like fedora will be
accessible is probably still very much an open development question. But
if the idea of RHL as project is really going to blossom, then how the
tools in the rhl releases interacts with community contributed packages
is going to have to be expanded for sure.
>I for one would subscribe to such a service, to guarentee that packages
>have been properly compiled for a specific release of RHL, and tested.
Now this is the problem...redhat can't really garuntee that additional
stuff is going to be able to work. For example...we as experienced users
trust freshrpms and fedora to a great extent to provide quality add-on
packages. But the problem comes with poeple want redhat to 'garuntee'
that such addon packages will work. Redhat doesn't have the manhours to
garuntee and test the full range of what could potentially be considered
rhl community contributed packages. One of the points of switching to
this project idea, is to try to address this problem, by shifting some
of the burden of package maintance to the community's shoulders. If we
are going to ask redhat to garuntee that packages work...then redhat is
stuck providing a base number of packages that they have the manhours to
support. But if we no longer expect redhat to garuntee every package we
get from rhn...then that opens up the idea of 'partner channel' like a
channel for fedora or freshrpms. RedHat can't garuntee anything from a
fedora channel will definitely work...but if Redhat can tie the
community developers more directly into the rhl development process and
the rhn process...then we as users can work with the fedora or freshrpms
packagers or whomever to provide something close to that garuntee you
want.
But i think there is a lot of ground work that needs to be laid before
we can talk seriously about rhn offering 'partner channels.' A lot of
the mechanics of how community developers from outside of redhat can
interact with the rhl development process..a lot of new policy
groundwork here...some of it has been touch on here in this list
already, and I'd imagine there other rhl lists are discussing this in
more detail. But i would say that one of the longterm goals of rhl ehas
got to be easy to use support throughout all the rhl tools (up2date and
r-c-packages included...maybe even the installer) to get access to a
whole ecosystem of community support packages that go beyond the base
distro that redhat has the manhours to support directly. A serious
desktop product will have to have easy to use access to a wealth
additional software that redhat can't garuntee directly...but software
provided from 3rd parties that we has a community of users have grown to
trust.
>I also think that the software should allow you to choose from Stable
>and Test releases. Allowing a user to decide what they want to install.
That im not so sure about....that making it too easy for people who
don't know better to do things they think should work better but don't.
People equate an increase in version number with 'better' far too much
for their own good. Did you miss the thread about the removal of
'expert' mode from the installer?
I don't think its wise to encourage the average user to run testing
software as an option to stable software...i think a clear distinction
between what is a stable release and what is in testing is very
important to make sure people don't idly start chewing on experimental
packages. If the goals of the point and click tools is to provide a set
of tools the average users can rely on to give them trusted updates.
Given those same users the option to pull test packages with those same
convience tools...undermines the point of the tools...to keep things
running smoothly for the average user. Out of the total number of
redhat users out there, what percentage really should be consuming test
packages? Should this project be designing convience tools around the
needs of the testers? Or should this project focus on the needs of the
stable package users? I think one of the largest needs of a stable
system is to make sure the easy to use tools...aren't so easy to use,
that it makes it easy to fubar yer own system. That's what commandline
tools are for.
-jef"sadly, my crystal ball comes with a NDA, so I can't tell you what i
see happening with RHL 2 years from now"spaleta
20 years, 9 months
USB 2.0 IDE drives - dropped to shell when in fstab ... rc.local OK
by Jim Cornette
I bought an USB Interface Book drive to use a 2.5" IDE drive from my
older laptop in. The model of the book drive is ST-2211B2.
My computer is an HP ze4315us.
I tried to add the drive to the fstab file and upon reboot, it dropped
me to the "Enter root password, to fix problem" shell.
After thinking that the problem was on my end, I fscked the three
partitions aqnd no problem was found. I even tried other measures to see
if the entries would stop dropping me to the init 1 shell.
I then removed the entries and then rebooted. Everything came up
alright. Since they worked after the OS loaded and I was logged on. I
added the entries to the rc.local file and they worked with that method.
My main question is regarding where the entries should be entered? Are
there any plans to load the USB drivers before the /etc/ftab is read?
I would like USB recognized, sda device recognized, then fstab read. If
no plans, the files to change the order in would be appreciated.
Thanks,
Jim
--
One small step for man, one giant stumble for mankind.
20 years, 9 months
Upgrade crashes on kdebase-3.1.2-13 install
by Terry Linhardt
Scenario:
I am attempting to upgrade from RedHat 9 --> 9.0.93. I have 3 good CDs
(verified, and also used on a prior install). The upgrade consistently
fails when trying to upgrade kdebase-3.1.2-13. This occurs about 30
seconds after installing disk #2.
The upgrade aborts with a message of possible media failure, possible
disk space problem and possible hardware problem. I believe all three of
these "possibilities" to be incorrect. The media has been verified and
used on a prior install. Just to be sure, I re-burned a copy of disk #2.
Space... well, I have about 2.4 gig free when I start the install.
However, I evern removed several meg of files, and the "crash" still
occurs at the same place. Hardware...I have nothing else happening to
indicate this is hardware.
I am puzzled as to why it's trying to do an upgrade of kdebase. I'm
"pretty sure" I never installed KDE to begin with...I'm not a KDE user.
I also did an rpm query of installed packages, and found NO references
to kdebase.
At this point, I have a "partial" install of 9.0.93. In fact, my system
thinks it is now a 9.0.93 system. But, I know that quite a few packages
were never installed after the abort.
Thoughts or ideas would be appreciated. I can consistently duplicate
this failure on this particular machine...but not sure if anyone else
has seen this.
Thanks...Terry
--
Terry R Linhardt <linhardt(a)swbell.net>
20 years, 9 months
console.perms + <xconsole> + init 3 problem
by Peter Backlund
(I'm on RH 9 right now, so this might not be the case in Severn. If so, please
disregard.)
/etc/makedev.d/linux-2.4.x contains device nodes for /dev/nvidia*, which are
created with $CONSOLE as permission. But /dev/nvidia* fall under the <dri>
category in console.perms, and <dri> is only modified when a user logs in via
<xconsole>, which to me seems to be a display manager.
The problem arises when you boot to init 3, log in on ttyX, and run startx.
/dev/nvidia* stay 0600 root:root, and openGL apps don't run.
There is an easy workaround, namely remove the x from <xconsole> to make
nvidia devices fall under the <console> category, but there might be
downsides to that, or a better, more general approach (I'm no expert on pam).
I've tried fiddling with the globs for <console> and <xconsole>, adding
pts/[0-9] and so on, but to no avail. Anyone good with PAM configuration that
have a suggestion?
/Peter
20 years, 9 months
