Re: updates
by Jef Spaleta
Michael Young wrote:
>I do understand the term "beta." But, I thought this beta was in feature
>freeze already, so it has a specific group of packages. Is my thinking
>incorrect? The process of getting packages to RHN is bound to be
>automated, so, why would it be so hard to populate the channel?
Question: is your thinking incorrect?
Answer: yes
Bound to be automated...hmmm yes...
automated QA testing...automated RH errata advisory writing...
yep I'm sure there isn't much in the way of human decision making as to
what is worth creating an errata notice for and then placing in the rhn
network channels.
I'm sure its not HARD to populate the channel..with a whole bunch of
broken packages picked up out of rawhide...but that sort of defeats the
point of the service rhn provides now doesn't it? We are really early
in the beta phase yet...why not just sit back and wait and see.
>Well, "waste" may have been a poor choice of words, but I try not to
>make a habbit of giving away my money without getting something in
>return.
So what yer saying is...you don't pay taxes on a regular basis?
-jef"reading the rhn faq(s), before you purchase of subscription
helps"spaleta
20 years, 9 months
Re: updates
by Jef Spaleta
Joel Young wrote:
>if I understand Michael right, what he wants is some consideration
>and/or comps since he purchased rhn entitlements which will
>expire and which he is unable to use while beta testing severn.
>Why is he unable to use them? Because the machine he was planning
>on using them on is now running severn.
Oh he can sure use the entitlement...if updates show up for the beta :->
The point is there is no garuntee or even a promise for updates for the
beta to show up in the beta rhn channel. If I were a betting man...i
would say that at some point in this beta cycle, the beta channel at rhn
will get a few updates...if only to test out rhn/up2date
connectivity/functionality during the beta (that will need testing too
before the next product release). You have to be willing to wait for
updates though. If they don't come...they don't come...no one in an
official position is going to promise that any updates will show up.
There are far too many day to day packaging updates that appear in
rawhide to create errata announcements for each and everyone, and place
them in the rhn system. And frankly doing something like that would
undermine the point of RHN, day to day rawhide changes can break as much
as they fix.
Here is another way of looking at it...lets say down the road when we
all install RHL 17, and somehow miraculously there are no security
vulnerabilities for the first 3 months after the release...the rhn
channel could easily be without updates for that 3 month period. Now..is
that channel going unused? Or is it in fact being used precisely how
it's suppose to be used...and there just aren't any critical security
updates to be provided. RHN is primarily used for critical security
updates. RHN is a security blanket..to make it easy for you to get
security updates(and more rarely bugfixes and rarer still
enhancements.) The intrinsic value of the service RHN provides is
drastically reduced during a beta. You'll have a hard time trying to
define what is worth creating an errata announcement for during a
beta...especially this early in the beta.
>Since he is performing a valuable service for RedHat, it would
>be apropos for RedHat to comp him with an entitlement extension
>for when he shifts out of beta testing mode
Oh yeah...that scales out nicely...lets all get an extention to our
entitlements for every beta phase...I'd never have to buy an entitlement
again...becuase id just keep extending it with beta phase usage. Nope,
sorry...this isn't going to happen. RHN explicitly states in their faq
that:
"Red Hat Network currently only supports versions of Red Hat Linux and
Red Hat Enterprise Linux that are still active (have not yet reached End
of Life status). For a list of currently maintained Red Hat versions,
please go to http://www.redhat.com/apps/support/errata/"
Don't buy rhn entitlements for beta systems...I don't think yer going to
find any official statement from any redhat employee saying this is a
good idea. It's not a good idea...there is in fact very little value in
it. During a beta you aren't promised one single security update...one
single bugfix update...one single enhancement update.
>...or to make those
>entitlements useful and worth using while in beta test mode.
It is useful...even with no packages. You watch the little update icon
and you wait...and wait and wait. Think of this as approximating how
rhn will handle a perfectly stable and secure linux distribution. It's
all in how you look at it.
-jef"my glass is half-empty of air..which makes it in fact a full
glass"spaleta
20 years, 9 months
error messages in log file - how serious are they?
by Elton Woo
I get error messages in my boot.log file:
Aug 4 12:25:35 dhcp-133-74 -- root[5042]: ROOT LOGIN ON tty1
Aug 4 12:26:10 dhcp-133-74 init: Switching to runlevel: 5
Aug 4 12:26:10 dhcp-133-74 sendmail: sendmail shutdown succeeded
Aug 4 12:26:11 dhcp-133-74 sendmail: sm-client shutdown succeeded
Aug 4 12:26:11 dhcp-133-74 irqbalance: irqbalance startup succeeded
Aug 4 12:26:11 dhcp-133-74 rc: Starting pcmcia: succeeded
Aug 4 12:26:11 dhcp-133-74 autofs: automount startup succeeded
Aug 4 12:26:11 dhcp-133-74 anacron: anacron startup succeeded
Aug 4 12:26:12 dhcp-133-74 modprobe: modprobe: Can't locate module
char-major-10-134
Aug 4 12:26:35 dhcp-133-74 gdm(pam_unix)[5283]: session opened for user abe
by (uid=0)
Aug 4 12:26:36 dhcp-133-74 gconfd (abe-5343): starting (version 2.2.1), pid
5343 user 'abe'
Aug 4 12:26:36 dhcp-133-74 gconfd (abe-5343): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at
position 0
Aug 4 12:26:36 dhcp-133-74 gconfd (abe-5343): Resolved address
"xml:readwrite:/home/abe/.gconf" to a writable config source at position 1
Aug 4 12:26:36 dhcp-133-74 gconfd (abe-5343): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at
position 2
Aug 4 12:26:37 dhcp-133-74 kernel: es1371: version v0.32 time 06:20:32 Jul 11
2003
Aug 4 12:26:37 dhcp-133-74 kernel: es1371: found chip, vendor id 0x1274
device id 0x1371 revision 0x08
Aug 4 12:26:37 dhcp-133-74 kernel: es1371: found es1371 rev 8 at io 0xa000
irq 10
Aug 4 12:26:37 dhcp-133-74 kernel: es1371: features: joystick 0x0
Aug 4 12:26:37 dhcp-133-74 kernel: ac97_codec: AC97 Audio codec, id: CRY19
(Cirrus Logic CS4297A rev A)
Aug 4 12:26:37 dhcp-133-74 modprobe: modprobe: Can't locate module
sound-service-0-3
Aug 4 12:26:47 dhcp-133-74 kernel: ide-floppy: hdb: I/O error, pc = 0, key =
2, asc = 3a, ascq = 0
Aug 4 12:26:47 dhcp-133-74 kernel: ide-floppy: hdb: I/O error, pc = 1b, key =
2, asc = 3a, ascq = 0
Aug 4 12:26:47 dhcp-133-74 kernel: hdb: No disk in drive
Aug 4 12:26:48 dhcp-133-74 kernel: cdrom: This disc doesn't have any tracks I
recognize!
Aug 4 12:32:11 dhcp-133-74 kernel: ide-floppy: hdb: I/O error, pc = 0, key =
2, asc = 3a, ascq = 0
Aug 4 12:32:11 dhcp-133-74 kernel: ide-floppy: hdb: I/O error, pc = 1b, key =
2, asc = 3a, ascq = 0
Aug 4 12:32:11 dhcp-133-74 kernel: hdb: No disk in drive
Aug 4 12:32:11 dhcp-133-74 kernel: ide-floppy: hdb: I/O error, pc = 0, key =
2, asc = 3a, ascq = 0
Aug 4 12:32:11 dhcp-133-74 kernel: ide-floppy: hdb: I/O error, pc = 1b, key =
2, asc = 3a, ascq = 0
Aug 4 12:32:11 dhcp-133-74 kernel: hdb: No disk in drive
Aug 4 12:33:59 dhcp-133-74 kernel: hdc: packet command error: status=0x51 {
DriveReady SeekComplete Error }
Aug 4 12:33:59 dhcp-133-74 kernel: hdc: packet command error: error=0x50
Aug 4 12:33:59 dhcp-133-74 kernel: ATAPI device hdc:
Aug 4 12:33:59 dhcp-133-74 kernel: Error: Illegal request -- (Sense
key=0x05)
Aug 4 12:33:59 dhcp-133-74 kernel: Cannot read medium - incompatible format
-- (asc=0x30, ascq=0x02)
Aug 4 12:33:59 dhcp-133-74 kernel: The failed "Send DVD Structure" packet
command was:
Aug 4 12:33:59 dhcp-133-74 kernel: "ad 00 00 00 00 00 00 01 00 08 00 00 "
Aug 4 12:33:59 dhcp-133-74 kernel: udf: registering filesystem
Aug 4 12:33:59 dhcp-133-74 kernel: UDF-fs: No VRS found
Aug 4 12:40:13 dhcp-133-74 kernel: hdc: packet command error: status=0x51 {
DriveReady SeekComplete Error }
Aug 4 12:40:13 dhcp-133-74 kernel: hdc: packet command error: error=0x50
Aug 4 12:40:13 dhcp-133-74 kernel: ATAPI device hdc:
Aug 4 12:40:13 dhcp-133-74 kernel: Error: Illegal request -- (Sense
key=0x05)
Aug 4 12:40:13 dhcp-133-74 kernel: Cannot read medium - incompatible format
-- (asc=0x30, ascq=0x02)
Aug 4 12:40:13 dhcp-133-74 kernel: The failed "Send DVD Structure" packet
command was:
Aug 4 12:40:13 dhcp-133-74 kernel: "ad 00 00 00 00 00 00 01 00 08 00 00 "
Aug 4 12:40:13 dhcp-133-74 kernel: UDF-fs: No VRS found
Aug 4 12:41:28 dhcp-133-74 userhelper: pam_timestamp: timestamp file
`/var/run/sudo/abe/unknown:root' is only 136 seconds old, allowing access to
redhat-install-packages for UID 500
Aug 4 12:42:14 dhcp-133-74 userhelper: pam_timestamp: timestamp file
`/var/run/sudo/abe/unknown:root' is only 46 seconds old, allowing access to
redhat-logviewer for UID 500
COMMENTS: There are no disks in the drives. /dev/hdb is my LS-120
diskette drive, /dev/hdc is my cdwriter, and /dev/hdd is my DVD reader.
Also, I do have sound. (Ensoniq 64).
QUESTONS:
(1) How concerned should I be about these error messages?
(2) Should I open a bug report, and if so under which component?
TIA,
Elton ;-)
--
http://setiathome.ssl.berkeley.edu/stats/team/team_4504.html
"You only live once, so let's make life EASIER for each other."
LINUX Registered User #193975. AMD-K7 ATHLON CPU power on board.
20 years, 9 months
2.6.0-test2-bk1 available, and ACPI config menu
by Robert P. J. Day
the first BK patch (bk1) is out for 2.6.0-test2 and seems
to work just fine. i wouldn't have expected something like
the first patch to suddenly break things, but i've been
wrong before.
also, in the long and hallowed tradition of brain-damaged,
ambiguous and just plain confusing menu configuration, anyone
who wants to play with ACPI should be aware that the Power
Management menu is, well, wrong. or at least hideously
misleading.
despite what the help screen states (and what any normal
human being would assume), you don't need to select "Power
Management support" to configure ACPI, despite its aesthetic
appearance as a dependent sub-menu. go figure.
however, if you *do* select Power Management support,
and further select "Software Suspend", this does offer
an additional option under ACPI -- "Sleep States".
again, go figure.
rday
20 years, 9 months
updates
by Michael Young
Please pardon me if I missed a thread about this, but, is everyone
updating out of rawhide? Is redhat planning to populate the rhn severn
channel with packages anytime in the near future? I feel like I'm
wasting my entitlements while running the beta.
TIA
--
Michael Young <betatest(a)gnucode.kicks-ass.net>
20 years, 9 months
Grub - request
by guran
Hi
I have just done an installation via bootdisk.img and my hd images of the
isos. Very nice.
As I have a bunch of other Linux' on this box and uses Grub. It would be nice
to have the possibility to install the RedHat Grub to the boot directory.
Then it would be easier for me to know what special requests that this
installation have, when I transfer the information to my own Grub.
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
Strange smart errors
by coomsie
Gidday Guys,
I have these strange errors in my daily email log watch
should i be worried?
i have a via motherboard .. i wondered if it wanst supported fully yet on 2.4
in this area?
Cheers
Coomsie :3)
--------------------- Smartd Begin ------------------------
/dev/hda :
3 Time(s): SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from
49 to 50
2 Time(s): SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from
50 to 49
4 Time(s): SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from
50 to 51
3 Time(s): SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from
51 to 50
2 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 33
to 34
1 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 33
to 35
1 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 34
to 33
4 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 34
to 35
1 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 34
to 36
2 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 35
to 33
4 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 35
to 34
2 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 35
to 36
3 Time(s): SMART Usage Attribute: 194 Temperature_Celsius changed from 36
to 35
3 Time(s): SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from
49 to 50
2 Time(s): SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from
50 to 49
4 Time(s): SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from
50 to 51
3 Time(s): SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from
51 to 50
---------------------- Smartd End -------------------------
20 years, 9 months
Re: rhn alert icon
by M A Young
> > > --> "1 pixel wide applet icon"
> >
> > Hum, it took me two attempts but I managed to reproduce this bug
> > for the first time !
>
> I decided to debug this today, and tried and retried the given
> recipe and could not get the problem to reproduce today :-(
> Tried 20 times and failed ... I still don't know how to reproduce this
I often notice this problem on my workstation (which is turned off over
night and at weekends) if I stop and restart X in a session. The one time
I tried to deliberately reproduce in the last few days it failed to fail,
but I am now wondering if the first session was long enough for the applet
to check in.
Michael Young
20 years, 9 months
rpm errors
by coomsie
Gidday Guys,
I am constantly getting frozen rpm installs .....
I have the fix ... [ rm __db* ] in the /var/lib/rpm/ directory,
Apparently this was an earlier bug in rpm, is this a bug in severn?
==============
Cheers
Coomsie :3)
20 years, 9 months