Re: camera revisited

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday 14 May 2004 12:55, Andy Green wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Friday 14 May 2004 17:35, Gene Heskett wrote:
>> Yes, I ran down anything that looked like an executable and nuked
>> it. Before I did that, the bootup hung for serveral minutes, and
>> generated megabytes of logging about stuff it couldn't find, or
>> even hung the boot completely.  That was at least 6 months back up
>> the log, maybe 8 or 9.
>
>You need hotplug working to do what you are trying to do with the
> camera.  So nothing will work on that front until you have hotplug
> happy again.
>
I've been doing a "mount -t vfat /dev/sda1 /mnt/camera" since forever 
on rh8.0.  Whats so different about that in FC1?

>> Now, I've reinstalled hotplug-2004_01_05-1.noarch.rpm and
>> hotplug-base-2004_01_05-1.noarch.rpm, and the boot is stalling on
>> "Starting hotplug" for about a minute now, much faster than
>> before, and my logs are filled with messages about not finding
>> ide_probe_mod and ide_probe.  Now, the interesting thing is that
>> in my updated modprobe.conf, those module aliases are listed as
>> ide-probe and ide-probe-mod, note switch from underscore to dash
>> as separators????
>
>I don't know what these modules do, but I think you can get around
> the errors by adding
>
>install ide-probe /bin/true
>install ide-probe-mod /bin/true
>
>in /etc/modprobe.conf.
>
>Actually, that might not be the best advice, read on.
>
>> May 14 08:01:28 coyote kernel: usb 3-2.2: new full speed USB
>> device using address 6 May 14 08:01:28 coyote kernel: scsi1 : SCSI
>> emulation for USB Mass Storage devices May 14 08:01:28 coyote
>> kernel:   Vendor: OLYMPUS Model: C-3020ZOOM(U)     Rev: 1.00 May
>> 14 08:01:28 coyote kernel:   Type: Direct-Access                  
>>    ANSI SCSI revision: 02 May 14 08:01:28 coyote kernel: Attached
>> scsi generic sg2 at scsi1, channel 0, id 0, lun 0, type 0 May 14
>> 08:01:28 coyote scsi.agent[3039]: disk at
>> /devices/pci0000:00/0000:00:11.4/usb3/3-2/3-2.2/3-2.2:1.0/host1/1:
>>0:0:0 May 14 08:01:28 coyote modprobe: FATAL: Module sd_mod not
>> found.
>
>This looks bad.  USB storage devices pretend to be SCSI.  It looks
> like your kernel config does not have [some kind of] SCSI support
> selected as a module. Possibly your config lacks some kind of IDE
> support as a module too, which would explain the other errors.
>
>You have two choices as I see it.  First, instead of using a random
> "Gene" kernel config, use the one from Redhat.  If you look inside
> a Redhat 2.6 kernel RPM, you will see a /boot/config-<version> file
> which is the kernel .config that the Redhat kernel was compiled
> with.  Copy this to be .config in your kernel tree and make
> oldconfig (I think that will do).
>
>Second, why do you need a custom kernel?  Why not use a Redhat
> RPM-packaged one.  All this pain will just go away.  New pain may
> come, but less than this toothache.
>
>> Call me puzzled, a whole lot...
>
>UR a whole lot Puzzled.
>
Yup, that I am.  IF, and I wish I could underline that, all the module 
loading stuff worked, I wouldn't have to build a custom kernel with 
all this built in.  I even upgraded a semi-working rh8 install with 
all updates applied to FC1 thinking that would fix some pango/gtk 
related problems I'd developed about 2 months ago.  It didn't fix a 
thing, and broke a lot of things that were working just fine.  I even 
tried to build all the dependencies for the newer gtk+-2.4.0, 
surprise surprise, all the stuff built except gtk+-2.4.0, which still 
wouldn't even configure.

All of my problems actually started with a failed make of the new 
X.org X11R6.7.  Following their instructions to the letter, I started 
the make in the build dir, dirlinked to the sc dir in the same tree.  
It errored out about halfway thru the make, and my system has been 
screwed ever since.

I didn't get that pango problem fixed until I hand carved a .pangorc 
file.  None of the rpms available for pango and gtk are actually 
capable of restoreing a broken system even when you use --force and 
--nodeps to install them.  My contention is that if you want us to 
use rpms, then fix the obviously broken rpms, particularly the pango 
related ones.

I can edit a grub.conf with the average kernel install, and make it 
work on the first pass.  If I'm to install one of your rpm kernels, 
how can I make it understand there are maybe 16 other kernels already 
in the listing instead of wipeing out all the stuff I can fall back 
to?  One time it even wiped my /boot partition, leaving only itself!  
Thats a windows attitude I can do without.  Yeah, I know, make a 
copy...

It seems the last 6 months everything I fix breaks at least 3 other 
things.

>- -Andy
>
>- --
>Automatic actions for USB cameras, cardreaders, memory sticks, MP3
> players http://warmcat.com/usbautocam
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>
>iD8DBQFApPoUjKeDCxMJCTIRAiUCAJ99xIOXabtcdzRDC7OrxKKtf2BiNACfdiUR
>LYLaTLPNm5JcP1XKtPJQ428=
>=SqI6
>-----END PGP SIGNATURE-----

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux