Re: Upgrade to fc2
by Jef Spaleta
Leonid Podolny wrote:
> Yes, but how do I upgrade FC1 to FC2 test? yum? ftp?
The better question to ask is... which upgrade method needs testing.
And the best answer is, whichever upgrade method do you need to have
working when you do a final upgrade from FC1 to FC2.
Under RHL, upgrades via anaconda were the only upgrade path that Red Hat
was going to even public pretend to make sure is working. yum was a
worksforme situation that yum developers and users tested seemingly
their own. For Fedora, I'm sure Red Hat's engineers are still focused
on getting anaconda working as the priority, but now that yum is inside
Core it's a little more difficult for me to tell people not to test the
yum upgrade path. So if you can...test both anaconda and yum as upgrade
paths.
-jef
20 years, 2 months
Re: Upgrade to fc2
by Jef Spaleta
Lamont R. Peterson wrote:
> Speaking of SELinux with FC2, I would like to see FC2 ship a 2.4
> kernel with enough SELinux support built in so as to not hose up
> the system for the installed 2.6 kernel(s).
> Personally, I do not plan on utilizing such a kernel, except during the
> test series of releases. However, I think there may be several people
> who would want to be able to run both 2.4 and 2.6 kernels during a
> "transition" period of their choosing.
----
This opinion about dual shipping 2.4 and 2.6 has been expressed
repeatedly, and personally i think at this point, its a dead horse.
Shipping 2 kernels greatly complicates ANY bugreporting and demands
on developer time after the release in terms of fixing problems. And
it's pointless to use the argument that Core developers should just
throw the community a bone, and ship a 2.4 kernel even if they don't
have the time to commit to keeping both kernels 'working' during the
lifetime of product. Shipping pieces of Core, without being able to
commit to keeping it updated through the Core release lifetime..is
frankly...irresponsible. Not shipping both kernels, is recognition of
the constraints on doing quality distro integration/maintenance. Core is
NOT a "throw it over the fence" collection of software.
And to think about it another way...for FC2 to ship with a 2.4
kernel..FC2 test releases would have to ship with a 2.4 kernel for
testing...if test releases ship with a 2.4 kernel..thats less testing
focus for the 2.6 kernel. Divided testing effort during the
releases..means more bugs and problems make it through to the release
for both kernels...everyone ends up unhappy.
Barring a serious meltdown...2.6 kernel is THE kernel for FC2, everyone
concerned about what that means in terms of moving systems over the FC2
better do all they can to use the test releases, every single one of
them, to find serious problems and report them. The earlier you find a
serious 2.6 kernel related bug, the quicker developers can work through
their priority list and get to it. Having a 2.4 kernel hanging around
for everyone to easily get at..is a distraction/drain to both testing
and to post release maintenance.
-jef"time to face the music...and buy a new crash helmet"spaleta
20 years, 2 months
Upgrade to fc2
by Leonid Podolny
Hi,
I currently run fc1 and would like to test current releases of fc2. What
is a right way to do that?
20 years, 2 months
Compiling x86 rpms on x86_64
by Mark Lane
I am finding some interesting problems trying to rebuild mozilla-1.6-0.i386 on
my x86_64 system. It seems that even if I tell it "rpmbuild -ba --target=i386
mozilla.spec", it still builds the 64Bit version. What am I missing?
I have already specifically set ${_libdir) to /usr/lib.
regards,
--
Mark Lane, CET mailto:mark@harddata.com
Hard Data Ltd. http://www.harddata.com
T: 01-780-456-9771 F: 01-780-456-9772
11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3
--> Ask me about our Excellent 1U Systems! <--
20 years, 2 months
Fedora Core 1 Test Update: gdm-2.4.4.5-1.2
by Warren Togami
---------------------------------------------------------------------
Fedora Core 1 Test Update Notification
FEDORA-2004-064
2004-02-05
---------------------------------------------------------------------
Name : gdm
Version : 2.4.4.5
Release : 1.2
Summary : The GNOME Display Manager.
Description :
Gdm (the GNOME Display Manager) is a highly configurable
reimplementation of xdm, the X Display Manager. Gdm allows you to log
into your system with the X Window System running and supports running
several different X sessions on your local machine at the same time.
---------------------------------------------------------------------
Update Information:
This is a bug fix update that resolves these three issues:
Bugzilla #110315 - GDM fails counting of XDMCP maximum sessions
This resolves the issue where XDMCP sessions would fail with
"Maximum number of open XDMCP sessions reached" due to problems
with the MaxSession counter. This issue has been problematic
especially for the K12LTSP community. K12LTSP expert
administrators are thus encouraged to thoroughly test this
update in production and report findings to the Bugzilla Tracking
Report below.
Bugzilla #113154 - GDM file descriptor leak
Also fixed by the same patch.
Bugzilla #113995 - GDM Japanese translations missing
Patch contributed by Jens Petersen.
Upgrade Note:
Due to past file format changes, gdm moves your existing gdm.conf
and possibly other gdm configuration files to .rpmsave and replaces it
with a pristine copy. Normal single desktop users probably do not
need to worry about this, but this can be problematic for LTSP or
VNC remote desktop users. It is recommended that these users review
changes between the .rpmsave and pristine config file, and reconfigure.
The 'gdmsetup' GUI config tool found in System Settings -> Login
Screen may be useful in configuration of gdm.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114986
Please discuss this test update on k12osn and fedora-test-list.
Report definite findings to this above Test Update Tracking report.
If no regressions are confirmed by February 16th, 2004 then this
update should become final.
---------------------------------------------------------------------
* Wed Feb 04 2004 Warren Togami <wtogami(a)redhat.com> 1:2.4.4.5-1.2
- renamed for FC1 update
* Tue Feb 03 2004 Warren Togami <wtogami(a)redhat.com> 1:2.4.4.5-9
- add two lines to match upstream CVS to xdmcp_sessions.patch
Fully resolves #110315 and #113154
* Sun Feb 01 2004 Warren Togami <wtogami(a)redhat.com> 1:2.4.4.5-8
- patch30 xdmcp_session counter fix from gdm-2.5.90.0 #110315
- automake14 really needed, not automake
- BR libcroco-devel, libcroco-devel, libattr-devel, gettext
- conditionally BR libselinux-devel
- explicit epoch in all deps
- make the ja.po time format change with a sed expression rather than
overwriting the whole file (Petersen #113995)
---------------------------------------------------------------------
This update can be downloaded from:
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/1/
61f2777a2984d1e6654a5016cd618d10 SRPMS/gdm-2.4.4.5-1.2.src.rpm
5bfc22d7aa5765240a474f4f35c1d3a1 i386/gdm-2.4.4.5-1.2.i386.rpm
57bcd986204d950b86c7865ee9e452b8
i386/debug/gdm-debuginfo-2.4.4.5-1.2.i386.rpm
This update can also be installed with the Update Agent; you can
launch the Update Agent with the 'up2date' command. You may
need to edit your up2date channels configuration. Within
/etc/sysconfig/rhn/sources enable the following line:
yum updates-testing http://fedora.redhat.com/updates/testing/fedora-core-1
---------------------------------------------------------------------
20 years, 2 months
AMD64 install failure on LSI Megaraid.
by Sam Varshavchik
I'm trying to install Fedora AMD64 0.96 onto a pair of disks in a RAID-1
configuration, using the Megaraid 320-1 card. When Anaconda begins
formatting partitions the cursor becomes very sluggish. The hourglass
animation goes at, maybe, one third its regular speed, and the pointer
noticably flickers.
tty4 is spitting out a bunch of "scsi disk error id=0 lun=0 error=40001",
while all of this is going on.
This continues through the format process, and somewhere in the middle of
copying the install image I get kicked back to the text mode. There are no
diagnostics or error message, except for a blank, generic "install exited
abnormally", and a shutdown.
Upon reboot both disks in the array are marked as bad. However the Megaraid
card shows no media errors on either drive.
If I bring up the disks manually, boot into rescue mode, and use dd
if=/dev/zero of=/dev/sda[123], I can essentially wipe the entire disk
without getting the disks flagged as bad. The physical disks are new, and
there's every indication that there's nothing wrong with the physical disk.
And I did test the burned Fedora CDs, they are good.
Anaconda automatically brings up the megaraid driver. I've tried noprobe
and manually selected megaraid2, with the same results.
The only other detail here is that the Megaraid card is in the 32 bit PCI
slot. For some reason I can't boot the machine with the Megaraid card in
the 64 bit slot.
I'm stumped. I can write to the entire RAID logical volume using dd, from
tty2. But as soon as Anaconda starts loading stuff, errors galore.
20 years, 2 months
Hello
by Alex Thomsen Leth
The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.
20 years, 2 months
Fedora for AMD64
by Shah Amit
Hi all,
Has anyone tried the Fedora Core 1 for Amd64 test1 release for the 64bit AMD
processor ?? I have an emachines laptop - 6805 which has the AMD64 ... I
want to try to install Fedora on this, but I dont know how good and stable
the Fedora AMD64 is ... .If anyone can give me some advise ... If not
Fedora, which distro would be the best for the 64 bit AMD ...
Thanks,
Amit
_________________________________________________________________
Find high-speed net deals comparison-shop your local providers here.
https://broadband.msn.com
20 years, 2 months
Kernel 2.6.x RPMs and vmlinux and third party modules
by Paul Bender
With the 2.6.x kernel RPMs, it appears that vmlinux has been moved to
the kernel-debuginfo RPM. Is there a reason that this was done?
The reason I ask is that some third party kernel modules require vmlinux
in order to build. During the build process, these modules use modpost,
which takes vmlinux as its first argument. As a result, these modules
cannot be built without installing the kernel-debuginfo package or
rebuilding the kernel.
Not having done any kernel module development, I am assuming that these
modules need to use modpost (and therefore vmlinux) during the build
process. If this is not the case, then could someone let me know so that
I can inform the module developers.
Anyway, since some third party modules require vmlinux to build, it
would seem more sensible to include vmlinux in an RPM other than the
kernel-debuginfo RPM. If a kernel-devel RPM existed, then it would make
sense to include it there. Since no kernel-devel RPM exists, I think
that vmlinuz should be included in the kernel RPM.
One example of modules that require vmlinux are the MADWIFI drivers
available at <http://sourceforge.net/projects/madwifi/>.
20 years, 2 months
OOPS when installing sapdb 0.74 on fc1-test1-amd64
by Ken Snider
Installing the 0.74 i386 RPM's from sabdb/maxdb produced the following dmesg
output when doing an rpm -ihv of sapdb-testdb74-7.4.3.30-1.i386.rpm:
general protection fault: 0000
CPU 1
Pid: 16297, comm: kernel Not tainted
RIP: 0010:[<ffffffff801c85b4>]{ia32_copy_siginfo_to_user+244}
RSP: 0000:00000100e55cde40 EFLAGS: 00010212
RAX: 0000000000000000 RBX: 0000000059374710 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000100e55cdf38 RDI: 00000000593747a0
RBP: 0000000000000000 R08: 00000100e61b9f60 R09: 0000000000000000
R10: ffffffff8013db71 R11: 0000000000010283 R12: 00000100e55cdf58
R13: 00000100f7cd86e8 R14: 0000000000000020 R15: 00000100e55cca58
FS: 0000002a9555c6c0(0000) GS:ffffffff80574dc0(005b) knlGS:0000000059374bb0
CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 00000000ffffcef8 CR3: 00000000066a8000 CR4: 00000000000006e0
Process kernel (pid: 16297, stackpage=100e55cd000)
Stack: 00000100e55cde40 0000000000000000 5557ed68801c918e 0000000400000000
59374bb000000000 0000000100000000 0000008000000000 00003fa900000000
ffffffff00000000 802c4c44ffffffff 00000010ffffffff 0001028300000000
Call Trace: [<ffffffff801101ce>]{do_signal+158}
[<ffffffff802c4c44>]{bad_get_user+0}
[<ffffffff8013db71>]{compat_sys_sched_setaffinity+17}
[<ffffffff8011061b>]{intret_signal+45}
Code: c3 66 66 66 90 66 66 66 90 66 66 90 48 83 ec 18 48 81 e2 ff
RIP [<ffffffff801c85b4>]{ia32_copy_siginfo_to_user+244} RSP <00000100e55cde40>
CPU 1
Pid: 16297, comm: kernel Not tainted
RIP: 0010:[<ffffffff801c85b4>]{ia32_copy_siginfo_to_user+244}
RSP: 0000:00000100e55cde40 EFLAGS: 00010212
RAX: 0000000000000000 RBX: 0000000059374710 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000100e55cdf38 RDI: 00000000593747a0
RBP: 0000000000000000 R08: 00000100e61b9f60 R09: 0000000000000000
R10: ffffffff8013db71 R11: 0000000000010283 R12: 00000100e55cdf58
R13: 00000100f7cd86e8 R14: 0000000000000020 R15: 00000100e55cca58
FS: 0000002a9555c6c0(0000) GS:ffffffff80574dc0(005b) knlGS:0000000059374bb0
CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 00000000ffffcef8 CR3: 00000000066a8000 CR4: 00000000000006e0
Process kernel (pid: 16297, stackpage=100e55cd000)
Stack: 00000100e55cde40 0000000000000000 5557ed68801c918e 0000000400000000
59374bb000000000 0000000100000000 0000008000000000 00003fa900000000
ffffffff00000000 802c4c44ffffffff 00000010ffffffff 0001028300000000
Call Trace: [<ffffffff801101ce>]{do_signal+158}
[<ffffffff802c4c44>]{bad_get_user+0}
[<ffffffff8013db71>]{compat_sys_sched_setaffinity+17}
[<ffffffff8011061b>]{intret_signal+45}
Code: c3 66 66 66 90 66 66 66 90 66 66 90 48 83 ec 18 48 81 e2 ff
This is on a dual-processor Opteron rig with 4GB of RAM.
--
Ken Snider
20 years, 2 months