After playing around with hal and usb automounting, a guy at RH named
David Zeuthen fixed it. Good job! (And that goes to everybody else
involved in pumping out the fedora releases - they are relly great! Good
But there is another thing i wonder if will be fixed in fc3 - mounting
of USB mass storage multiple card cardreaders. I guess i mean those who
use multiple LUNS...
Will those nifty little devices be supported for FC3? If not - why?
Anything i can do to help?
On Mon, Sep 27, 2004 at 10:15:17AM -0700, shane geeklords org wrote:
> Can this be done with up2date in FC3? up2date --showall does not report
> any package that contains kernel source, noarch included.
Can I suggest that the removal of kernel-source be mentioned in the
On Sat, 2004-09-25 at 16:06 +0100, Timothy Murphy wrote:
> Just got caught again by this LABEL nonsense.
> I was mounting my laptop hard disk on my desktop -
> both running Fedora-
> and the whole thing was thrown into confusion
> because there were two partitions LABELed "/",
> on my desktop hard disk and on the laptop hard disk.
> I had to start again in single mode,
> and change all the entries in /etc/fstab and /etc/grub.conf .
That's a common problem when adding hdd's with other fedora installs.
How about generating a random integer at install time, and use it to
label partitions like
and reference these in fstab / grub.conf? Could this create problems?
Galuna - Solutii Linux in Romania
Can this be done with up2date in FC3? up2date --showall does not report
any package that contains kernel source, noarch included.
"Given enough time, all legal battles in the tech industry will invoke the
DMCA. This generally means that all constructive arguments have ended."
in theory we compile all of fedora core with -mtune=i686 (or
-mtune=pentium4 nowadays). however that only actually happens if
packages propagate the RPM_OPT_FLAGS into the CFLAGS properly; almost
all but not quite not all packages actually do this.
The script at
can be used to check if a shared libary is compiled with -mtune=i386 or
-mtune=i686. If it detects i386 then most likely there is a packaging
bug with not propagating the compiler flags properly.
Usage is like this:
objdump -d sharelibraryfilename.so | perl detecti686.pl
If a shared library is really small with say only 1 function, it is
possible that the heuristics fail.
Arjan van de Ven
Will there be a real print dialog (one which do allow you to select
printers) in FC3? - it is no such thing (as far as i can see - i havent
ran yum update due to that i am on an ISDN dialup, and the volume is...
enormous) in test 2, but ive heard some rumours of it in desktop-list.
Not having support for multiple printers (unless you know the syntax of
lpr) is really a huge handicap for end-user-friendlyness IMO
Just being curious - why is not the default paper size matched with what
is most common in the country you select in timezone setup? Ex. in
Norway, Letter is something only known from the "select paper size" in
printer drivers - A4 is the _only_ format used. And as default paper
setting in many programs - such as firefox - while ex. OpenOffice uses
A4. Why is there no common setting of this - one file where all programs
read what the standard papersize/orientation etc should be?
Having it wrong is bad, but inconsistent is almost worse...
Before I think about filing a bug I'd though I would start a
discussion on this. EFI GUID Partition support is currently only
supported on IA-64. Intel is eventually supposed to support this on
future platforms. But today it is causing havoc, and I would very much
like this off in FC3.
The Apple Ipod (4th Generation) , Ipod Mini, as well as some USB and
Firewire drives are no longer mountable under Linux with this option
on. The 37th post at this link gives a good explination.
Seeing how nothing today or foreseeable in the next year is using
this, I don't see why this cannot be cut off for both the X86, X86_64,
and PPC kernels.
Just in case the link breaks here is cut and paste job of the post below:
Okay, I've been following this thread and I've been having the same
problem. I have a mini iPod. It works really well with my desktop
maching running redhat-9 (2.4 kernel). I recently got a new laptop
running SUSE 9.1 (2.6 kernel) and on the laptop I have the problem
described by others in the thread: when plugged-in the kernel will
find the device but quickly have an I/O error and the device is
unreadable at that point:
Sep 24 21:14:26 t42p kernel: usb 4-3: new high speed USB device using address 4
Sep 24 21:14:26 t42p kernel: usb 4-3: Product: iPod mini
Sep 24 21:14:26 t42p kernel: usb 4-3: Manufacturer: Apple
Sep 24 21:14:26 t42p kernel: usb 4-3: SerialNumber: 0000008638BA
Sep 24 21:14:26 t42p kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Sep 24 21:14:26 t42p kernel: Vendor: Apple Model: iPod
Sep 24 21:14:26 t42p kernel: Type: Direct-Access
ANSI SCSI revision: 02
Sep 24 21:14:27 t42p kernel: SCSI device sda: 7999488 512-byte hdwr
sectors (4096 MB)
Sep 24 21:14:27 t42p kernel: sda: assuming Write Enabled
Sep 24 21:14:27 t42p kernel: sda: assuming drive cache: write through
Sep 24 21:14:27 t42p kernel: sda:end_request: I/O error, dev sda,
Sep 24 21:14:27 t42p kernel: Buffer I/O error on device sda, logical
Sep 24 21:14:27 t42p kernel: end_request: I/O error, dev sda, sector 7999480
Sep 24 21:14:27 t42p kernel: Buffer I/O error on device sda, logical
Sep 24 21:14:27 t42p kernel: sda1 sda2
Sep 24 21:14:27 t42p kernel: Attached scsi generic sg0 at scsi2,
channel 0, id 0, lun 0, type 0
Sep 24 21:14:27 t42p kernel: USB Mass Storage device found at 4
In my case I'm using a mini iPod with USB2, but the same problem (and
solution) probably applies to the firewire interface or newer
generation large iPods, but I don't have either of these to test.
To make a long story short, you can solve the problem by disabling the
feature CONFIG_EFI_PARTITION in your kernel and rebuilding the kernel.
This problem could potentially happen with both 2.4 and 2.6 kernels.
A longer story follows and perhaps someone can come up with a more
sensible solution for the long run.
The iPod looks like a removable disk drive to the host computer. When
it is attached to the computer, the mini iPod reports a capacity of
7999488 512-byte sectors (or about 4GB). This turns out to be wrong
for whatever reason. The mini iPod only really has 7999376 sectors and
it exaggerates by 112 sectors. The other quality of the iPod is that
if the computer attempts to read a sector greater than the actual
capacity but less than the reported capacity, the iPod will dutifully
report an I/O error, but it won't respond to any future requests until
you unplug/plug the iPod.
This creates a fragile situation where the host computer can croak the
iPod by reading one of these 112 tacitly illegal sectors. If you ask
me, this is an Apple bug (or maybe a bug of their disk supplier or
firewire/USB interface supplier), but a bug nonetheless.
So, when a new disk is presented to the linux kernel, linux first goes
out and tries to find the partition table for the disk. Usually this
is the first sectors of the disk (traditional microsoft partition
table we've been using for 20 years), but there are also a number of
other types of partition tables. The kernel uses a heuristic to look
for different types of partition tables and the kernel configuration
specifies which partition types are attempted.
The "EFI" partition table is a new type of partition table that is
part of the "extensible firmware initiative", this is a good thing for
the future. I don't know anything about EFI partition tables, except
that as part of looking for an EFI table linux goes out and reads the
last few sectors of the disk (sector 7999480 in the case of a mini
iPod). The kernel looks for an EFI partition before looking for an old
fashioned MSDOS partition table and this croaks the iPod. If you
disable support for EFI partition tables (CONFIG_EFI_PARTITION) the
mini iPod will work fine. I don't know of a quick fix short of
rebuilding the kernel.
Of course, once it's working, previous advice about setting up hotplug
correctly and having the right /etc/fstab entries and such apply, but
the iPod is just great under linux and gtkpod is a fantastic program
for managing the iPod.