is yum's https proxy support broken? or am I doing this wrong?
in /etc/yum.conf , I've added this line
and when trying to yum from my https repo, I got "X-Squid-Error:
ERR_UNSUP_REQ 0" from the proxy..
[kagesenshi@Hikari ~]$ sudo yum install python-twisted
Loading "installonlyn" plugin
Setting up Install Process
Parsing package install arguments
[Errno 14] HTTP Error 400: Server: squid/2.5.STABLE11
Date: Tue, 24 Jul 2007 15:17:50 GMT
Expires: Tue, 24 Jul 2007 15:17:50 GMT
X-Squid-Error: ERR_UNSUP_REQ 0
X-Cache: MISS from Network-Box
My yum & urlgrabber version:
anybody can confirm whether this is a bug or not??
Mohd Izhar Firdaus Bin Ismail
天野晃 「あまの ひかる」
92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331
I'm thinking about the adding of some teletext viewer for Fedora (at
least for Gnome).
Most TV cards support teletext capturing, and this feature is demanded
Besides some very old implementations (gnometv, alevt), which seem
already stopped, I've found two possible variants:
- Enable "mtt" in the "xawtv" package (recently added to Fedora).
But enabling of "mtt" will require Motif...
- Package Zapping TV viewer (http://zapping.sf.net), which has an
advanced teletext viewer (Zapzilla).
But Zapping should be stripped first from any mpeg-patented-etc. stuff...
What is better? Or maybe something else?
I just did a clean install of Fedora 7 from the live CD onto my laptop,
which previously had a Fedora install upgraded from one of the F7 test
releases, partitioned as suggested by anaconda (LVM, one swap partition,
everything else under '/')
When reinstalling, I kept the partition layout and specifically told
Anaconda *not* to reformat / (having booted in rescue mode beforehand, and
removing everything but /home). Anaconda gave a warning that the leftover
files might interfere with the installed system, which gave the impression
that those files won't actually be removed during installation.
As it turns out, however, the old contents are completely gone (I'm trying
out different recovery tools now to see if I could rescue some of the data).
It's as if the live CD simply used dd to transfer the install image to the
hard drive (in which case, how does it actually handle different partition
layouts, e.g. /usr, /var, /home on separate partitions -- does it just move
the files afterwards?)
As it stands it seems that the Live CD is a very dangerous tool, at least as
1) the default behaviour of Anaconda is to put everything under /
2) it does not carry more warnings about what it will do to the / partition
Could someone let us know how the live CD actually performs its work? It
would aid tremendously in the data recovery part. Would 'dd'-ing the entire
partition to an external drive, and mounting it on a Windows computer (most
recovery tools are unfortunately for that platform) preserve all the data
required? I'm assuming that the new installation overwrote the same parts of
the disk that was used to hold the OS in the previous install.
Using rawhide as of July 28.
All of a sudden, my ethernet won't come up. No link lights. But this is
dual-boot machine, and networking works if I boot up Windows XP.
I've got a Realtek integrated card, and the kernel finds it:
02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Hewlett-Packard Company Unknown device 2a26
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 64 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at dc00 [size=256]
Region 1: Memory at fddff000 (32-bit, non-prefetchable) [size=256]
Capabilities:  Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
But no link light comes on at the linux machine, or at the router.
dmesg | grep eth0
eth0: RealTek RTL8139 at 0xffffc2000064a000, 00:15:f2:77:86:13, IRQ 21
eth0: Identified 8139 chip type 'RTL-8101'
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: no IPv6 routers present
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 10.
eth0: Tx queue start entry 4 dirty entry 0.
eth0: Tx descriptor 0 is 0008205a. (queue head)
eth0: Tx descriptor 1 is 0008205a.
eth0: Tx descriptor 2 is 00082156.
eth0: Tx descriptor 3 is 0008204e.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Windows gets the dhcp address from the router. Fedora times out. I've tried
setting Fedora to a static address, but then I still can't ping anything,
including the router. OTOH, fedora gives no error about ifup'ing eth0 with a
Completely puzzled. Don't know where or whether to file a bug report.
The following packages are installed in my x86_64 development mock root
by default but not in i386 (as part of the "update" step):
Can anyone else confirm this?
This is with mock 0.7.2-1.fc7 and yum-3.2.1-1.fc7 on x86_64
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
Due to an ongoing issue with booting many Dells (and some Toshiba)
systems via CD, we've had to delay the release of Test1. The good news
is that we've found a solution and a new kernel is building in koji as
I type this. The bad news is that there is not enough time to get the
output of that build and spin it into a set of trees for release on
Thursday. As such, we're slipping the release to Tuesday of next
week, August 7.
This gives us time to consume the kernel build and generate a release
candidate tree early tomorrow, and spend all day, and all of Thursday
beating on it for real blocker issues. Friday morning is our Go/No Go
point. If all things are Go, we'll be handing it off to mirrors and
giving them the weekend and Monday to sync up the release. If we're No
Go, we will determine then a new release date.
All the gory details can be found at
Release Engineer: Fedora
Fedora-devel-announce mailing list
While debugging an issue with the aic7xxx driver, I noticed that SCSI performance is quite poor for the current development kernel compared to release kernels.
For a U160 disk attached to a 2940UW controller, FAST-20 mode [which, btw, has to be forced manually, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171282] delivers more than 28 MB/s [hdparm -t /dev/sda] for the latest F7 update kernel 22.214.171.124-33.fc7 [compared to the nominal rate of 40 MB/s] whereas it drops by almost 30% to about 20 MB/s for rawhide kernel 2.6.23-0.49.rc1.git3.fc8 which is barely more than in FAST-10 mode. It this difference of the order one would expect?
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
I have the unfortunate luck of wanting to install Linux on a Dell optiplex
320. This machine seems to be as anti-linux as they come! Problems faced:
1- Sata disk not recognized
WorkAround: pass pci=nomsi, or all-generic-ide (depending on newer/older
2- Grub does not boot!!
WorkAround: Use lilo
3- Machine doesn't have PS2, only USB keyboard/mouse. USB does not work, the
following errors are generated
ohci_hcd 0000:00:13.2: OHCI Host Controller
ohci_hcd 0000:00:13.2: USB HC TakeOver failed!
ohci_hcd 0000:00:13.2: can't reset
ohci_hcd 0000:00:13.2: init 0000:00:13.2 fail, -1
ohci_hcd: probe of 0000:00:13.2 failed with error -1
I need to install RHEL4 (much better), or an older Fedora (4?). This is
because of the CAD software that will run on this machine. I have not found
any work-arounds for such problem (only one that uses ohci-hcd parameter
no_handshake, which is not understood by 2.6.9 kernel). If anyone is aware
of any un-official kernel patch that solves that issue, kindly let me know.