Re: Fedora Core 2 Distribution Size
by Bill Nottingham
Peter Robinson (peterr(a)opensystems.net.au) said:
> Is it possible to put all the gnome stuff on 1 cd and all the kde stuff
> on another
No. What packages are on what CDs is done via dependency ordering.
Bill
20 years, 4 months
Re: 2.6 kernel on devel
by Alan Cox
On Sat, Jan 03, 2004 at 01:35:09PM +0800, Peter Robinson wrote:
> The couple of problems I've run into is support for a Stallion Multiport serial card.
> Are there any plans to compile the drivers for the not so standard multiport boards
> into the FC2 kernel? We have a large number of customers that still use systems with
Most of the old old multiport card drivers have yet to be ported to 2.6
> seem to recover. The monitor has suspend on the LCD and I can't seem to wake it up.
> Its a reasonably oldish board and hence on boot the kernel states that due to bios
> age that ACPI is disabled. I'm not really sure how to go about testing this.
Can you disable apm as well out of curiosity
20 years, 4 months
Proposal: Discourage rpmbuild --sign
by Warren Togami
Proposal
========
rpm-4.2.2 in rawhide and all future versions should discourage the use
of rpmbuild --sign. Perhaps this can be done effectively by adding a
large and annoying warning message and 15 second delay. Or disable it
completely. I don't care how, just discouragement should be done.
Why?
By allowing rpmbuild --sign to be not annoying, then people tend to
think that it is the proper way to build and sign packages. This is
totally not the case for one key reason: Safety.
It is possible, however unlikely, that trojans hiding within SRPMS that
you build could steal your GPG keys since they are running as the same
user as the GPG signing keys. They have access to memory used by gnupg,
as well as access to the files in ~/.gnupg. The passphrases can be
stolen, or the files themselves stolen and passphrase cracked. (It is a
lot easier to crack a passphrase when you have both the private and
public key.)
When a user attempts rpmbuild --sign, the warning message should
indicate that it is bad, and to read a webpage at rpm.org for more
information. That webpage should explain in detail why it is a bad
practice, and the following proper safer procedure.
1) rpmbuild as non-root user foo.
2) Copy the packages to non-root user foobar.
3) Use rpm --addsign to sign packages as non-root user foobar.
Protection of GPG keys must be of the highest importance, and I know for
a fact that some of the popular 3rd party repositories are still using
rpmbuild --sign. The risk to the community is just too great, and the
mitigating fix for this is exceedingly simple.
Sane idea?
Warren Togami
warren(a)togami.com
20 years, 4 months
2.6 kernel on devel
by Peter Robinson
Hi All,
I've been playing around with the current devel/rawhide on a spare build box I have
lying around and have a few queries. In general quiet impressesed with it especially
for an alpha stage distro.
The box I have is a pretty generic PIII 800 coppermine with a aic7xxx SCSI card and
disk, intel pro 100 nic and a radeon 7200 AGP video card. All work nicely.
The couple of problems I've run into is support for a Stallion Multiport serial card.
Are there any plans to compile the drivers for the not so standard multiport boards
into the FC2 kernel? We have a large number of customers that still use systems with
either stallion or specialix boards with terminals printers or modems attached for
things ranging from faxing to dialup to pos systems that are either running on RHL
or that other x86 unix that we're planning on moving to RHEL or Fedora (most cases
will probably be fedora) that will needing these drivers and I'd prefer not to have
to compile custom kernels.
The other problem I seem to be having with this machine with the FC2 devel is that
when I walk away from it for extended periods (over night) it suspends and doesn't
seem to recover. The monitor has suspend on the LCD and I can't seem to wake it up.
Its a reasonably oldish board and hence on boot the kernel states that due to bios
age that ACPI is disabled. I'm not really sure how to go about testing this.
Peter
20 years, 4 months
Grub size problem
by Cal
I'm trying to create a boot floppy to switch between hda and sda. But it
won't fit on a floppy and it seems to be the same problem when I try to
put the boot loader on the HD also because when I reboot I get:
GRUB GRUB GRUB (and it hangs).
Advice pls......
Tks
Chuck
20 years, 4 months
Re: Fedora Core 2 Distribution Size
by Jef Spaleta
Florian La Roche wrote:
> I would find such a live-cd very useful for many things. From hardware
> testing, beta testing new apps, etc.
> (And I don't see why this would be again a discussion point to add things
> Red Hat cannot put up for redistribution.)
I cringe at the thought...of an official live cd meant for beta testing
of specific applications. Dear god, fedora would have to re-roll a new
livecd image EVERY DAY during the beta testing phase...so you could
download a new livecd image EVERY DAY to incoporate the new package
updates that come out EVERY DAY. Dear god! that would complicate the
beta testing matrix a great deal. Are you seriously saying that you'd
burn a new livecd image EVERY day, in order to beta test applications?
What a horrible horrible idea. It might SEEM like it would make testing
easier for the tester...but I can't see it doing anything but
complicating the process of actually dealing with bug reports.
A livecd SOLELY for the purpose of testing...seems ill-fated a reason to
have a livecd. considering the fact that a livecd image is bound to have
its own bugs and errors that might not be in a normal install...seems a
bit circular to say the purpose of the official livecd is to test the
livecd.
-jef
20 years, 4 months
boot.iso not booting
by Martin
I'm trying to use the latest boot.iso in the Fedora Core development
tree, and it's not getting very far in boot. I've tired it on 3
systems, 2 of which fail early in boot, though with a bit different
messages. the Sony Vaio Z1RA dies very shortly after uncompressing
the kernel with this call trace:
inode_alloc_security
alloc_inode
init_file
__pnp_bios_get_dev_node
pnp_bios_get_dev_node
build_devlist
pnpbios_init
do_initcalls
init_workqueues
init
init
kernel_thread_helper
Code: Bad EIP value
any ideas?
martin
20 years, 4 months
Re: Fedora Core 2 Distribution Size
by Jef Spaleta
Maurice F. Piller wrote:
> I would like to see more of an emphasis on the "Core" part of the
> project, it would be nice if Fedora Core 2 could be released with just
> 1 or 2 installation CD images.
I seriously doubt you could drop 650 Megs worth of packages out of Core
without seriously pissing off a sizable part of the current userbase.
I'm sure you could probably find some reasonable agreement about
specific crufty redundant packages that 90%+ of the userbase don't care
about...but thats not going to add up to a cd's worth of data.
And frankly... until there is an official Fedora Extras/Alternatives up
and running ANY disccussion about wholesale redistribution of the
distribution is a bit premature.
Want to work towards a more realistic goal? How about you gather up all
the people who keep trying to stitch together the idea of making the
concept of refining a 'minimal' install via a better organization of the
comps file. That thread comes up again and again...and seems to go
nowhere. I've still not seem a community submitted comps file show up on
this list that I can test by rerolling iso images.
> Any interest in producing a live CD version a la Knoppix?
Yes there is interest....but the question of the usefulness of an
official Fedora live cd is a question. An official fedora livecd MUST be
made up of only official bits and pieces. No ntfs support for example.
In fact, Dirk Westfal is already working on an un-official derivative
livecd based on fedora:
http://www.redhat.com/archives/fedora-devel-list/2003-December/msg00002.html
Ive said this before...I'd personally rather see work on in-distro tools
to help people create their own live cds based on fedora, then an
official fedora livecd. I'm sure an official fedora livecd could be
built, but frankly I really don't know what people would use it for,
instead of using knoppix/gnoppix or Dirk's livecd. Considering the
non-technical constraints fedora has to live under, an official fedora
livecd couldn't have the same level of functionality out of the box that
other livecds have (multimedia support and ntfs being the primary usage
issues.) I'd rather see work on an easy to use tool, for people to
create their own customized livecds from a master fedora install...that
seems to me to be the best way to encourage usage and experimentation.
-jef
20 years, 4 months
LVM causes kernel 2.6.0 panic
by Gregory Petit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I was setting up a test pc to check if I finally could get my USB2 Iomega HD
working under linux. Unfortunatly I couldn't and I was wondering if it should
work after installing kernel-2.6.0-1.21.i686.rpm.
(from
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/...)
After a reboot, I got the following message:
VFS: mounted root (ext2 filesystem)
Red Hat nash version 3.5.14 starting
Loading jbd.ko module
Loading ext3.ko module
mounting /proc filesystem
creating block devices
scanning logical volumes
vgscan -- LVM driver(module not loaded?)
I haven't posted it yet on bugzilla, because I'm not sure if I did it the good
way. I configured my hd with LVM, installed the Severn beta (so not core 1!)
and then I downloaded and installed that kernel rpm.
Was this the good way (if so, then I'll submit a bugreport), or did I also had
to install some other components that should let LVM works?
Best regards,
Gregory
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/8vvuIXdlaijlOucRAjq5AJ4pD4ldWi/0r0CL/9oj0bV7Vv415wCfTL5x
amtgEYngL6yNZkbv0TESnOw=
=vloz
-----END PGP SIGNATURE-----
20 years, 4 months
