Fedora Core 3 Test Update: dos2unix-3.1-21.0.1
by Tim Waugh
---------------------------------------------------------------------
Fedora Test Update Notification
FEDORA-2005-399
2005-05-31
---------------------------------------------------------------------
Product : Fedora Core 3
Name : dos2unix
Version : 3.1
Release : 21.0.1
Summary : Text file format converter
Description :
Dos2unix converts DOS or MAC text files to UNIX format.
---------------------------------------------------------------------
Update Information:
This is a bug-fix release.
---------------------------------------------------------------------
* Wed Apr 13 2005 Tim Waugh <twaugh(a)redhat.com> 3.1-21.0.1
- Fixed tmppath patch (bug #150277).
---------------------------------------------------------------------
This update can be downloaded from:
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/3/
bc90ff489004dc80933878eee8233ed9 SRPMS/dos2unix-3.1-21.0.1.src.rpm
37dc4956cd2efe44c0823d458f430883 x86_64/dos2unix-3.1-21.0.1.x86_64.rpm
a996f68c9e5ba40b19bd70f2f38821c3 x86_64/debug/dos2unix-debuginfo-3.1-21.0.1.x86_64.rpm
e5c207ef1162f7272fec6a37787606a2 i386/dos2unix-3.1-21.0.1.i386.rpm
2cc788f6e39fdfaaf96352f121cdaf63 i386/debug/dos2unix-debuginfo-3.1-21.0.1.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://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/3...
---------------------------------------------------------------------
19 years, 1 month
rawhide report: 20050531 changes
by Build System
Updated Packages:
GFS-kernel-2.6.11.7-20050519.153509.FC4.9
-----------------------------------------
cman-kernel-2.6.11.4-20050517.141233.FC4.11
-------------------------------------------
dlm-kernel-2.6.11.4-20050517.141233.FC4.11
------------------------------------------
glibc-2.3.5-10
--------------
* Mon May 30 2005 Jakub Jelinek <jakub(a)redhat.com> 2.3.5-10
- fix LD_ASSUME_KERNEL (since 2.3.5-8 GLRO(dl_osversion)
has been always overwritten with the version of currently
running kernel)
- remove linuxthreads man pages other than those covered in
3p section, as 3p man pages are far better quality and describe
POSIX behaviour that NPTL implements (#159084)
gnbd-kernel-2.6.11.2-20050420.133124.FC4.33
-------------------------------------------
iptraf-2.7.0-15
---------------
* Tue May 17 2005 Karsten Hopp <karsten(a)redhat.de> 2.7.0-15
- move config file to %{_sysconfdir}/iptraf.cfg to prevent deletion at bootup (#157794)
* Tue May 10 2005 Karsten Hopp <karsten(a)redhat.de> 2.7.0-14
- enable debuginfo
kernel-2.6.11-1.1366_FC4
------------------------
* Sun May 29 2005 Dave Jones <davej(a)redhat.com>
- Fix slab corruption in firewire (#158424)
* Fri May 27 2005 Dave Jones <davej(a)redhat.com>
- remove non-cleanroom pwc driver compression.
- Fix unintialised value in single bit error detector. (#158825)
19 years, 1 month
External connections locked out after about a day
by Justin Cook
Hi there
Bit of a Linux noob here, so don't ask anything too technical. It's yer
own damn fault for making it so awesomely easy to install.
I'm running FC4T3 and I've noticed that after 20-24 hours the box starts
refusing external connections, specifically SSH and web (haven't tried
others). Duh, I forgot to check if it could connect to external sites
itself before rebooting it a few moments ago, but it'll connect to
localhost just fine.
Known issue? New one? How do I report this, what do I need to do?
Cheers
19 years, 1 month
any java expert on 64 bit ?
by korgull
Hi,
I'm trying to run xnap (http://xnap.sourceforge.net) on a FC4test3 system, but
it ends in :
java -jar xnap.jar
Could not read startup classpath from /root/.xnap/loader (/root/.xnap/loader
(No such file or directory))
Using default class path
Could not load XNap
java.lang.ClassNotFoundException: org.xnap.XNap not found in
org.xnap.loader.XNapClassLoader{urls=[file:/forms-1.0.2/forms-1.0.2.jar,file:/jh-1.1.3/jh-1.1.3.jar,file:/gnu.getopt-1.0.9/gnu.getopt-1.0.9.jar,file:/libreadline-java-0.8.0/libreadline-java-0.8.0.jar,file:/log4j-1.2.8/log4j-1.2.8.jar,file:/touchgraph-1.21/touchgraph-1.21.jar,file:/xnap-core-3.0-pre1/xnap-core-3.0-pre1.jar,file:/xnap-core-3.0-pre1/xnap-icons-1.jar,file:/kunststoff-2.0.1/kunststoff-2.0.1.jar],
parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:xnap.jar,file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}}
at java.net.URLClassLoader.findClass(java.lang.String)
(/usr/lib64/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(/usr/lib64/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String)
(/usr/lib64/libgcj.so.6.0.0)
at org.xnap.loader.XNapLoader.invoke(java.lang.String, boolean,
java.lang.String[]) (Unknown Source)
at org.xnap.loader.XNapLoader.main(java.lang.String[]) (Unknown Source)
at .main (/usr/lib64/libgij.so.6.0.0)
at .__libc_start_main (/lib64/libc-2.3.5.so)
Could not find suitable loader file, giving up
I'm no expert in java at all and have no clue where to look for a solution.
Besides that I think it may have something to do with this new 1.5.0 java or
the fact that I'm on a 64 bit system.
Anyone who can help me going with this ?
Thanks,
Marcel
19 years, 1 month
Re: <4> post_create: setxatter failed
by Russell Coker
On Thursday 26 May 2005 02:05, Hans Reiser <reiser(a)namesys.com> wrote:
> > Finally, are there still known situations where a corrupt ReiserFS file
> >
> >
> >They were reported years ago on the ReiserFS list. Hans didn't seem
> > inclined to fix them as fixing such bugs incurred a performance penalty.
> >
> >If that policy has changed in the ReiserFS development team then I'll
> > write some scripts to randomly corrupt ReiserFS file systems and try to
> > reproduce kernel bugs.
>
> I don't know which bugs you are referring to, and I don't remember
> saying what you ascribe to me. Perhaps you refer to my not fscking each
> node after it is read into memory before it is used by the filesystem.
> I don't think anybody does that, not just us. Some checks are made by
> us, but a complete and exhaustive check is not made by anyone that I
> know of. We could probably write a node plugin that would crc check
> after the node is read from disk. That would be reasonable, and I would
> accept a node plugin to do that.
I don't know the exact cause of the bug in terms of which part of the code was
responsible.
I reported a bug where I had a file system which if mounted would have a
"find /" operation cause a kernel Oops. As far as I am aware the bug in
question was never fixed.
It is my belief and the belief of many other people that a corrupted file
system should not be able to corrupt kernel memory, not even if the file
system is maliciously generated (think about the case of an attacker
inserting a CD or USB disk). I am not aware of any other Linux file system
for which a corrupted partition can cause kernel memory corruption (please
inform me if you know of one).
As for the "complete and exhaustive check", maybe this is an advantage for a
file system based on Inode tables as the data structures are simpler and
easier to check?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
19 years, 1 month
SELinux blocking EVERYTHING!
by Sean Earp
Hello All-
I haven't updated my FC4T2 installation for a week or so, and did last
night ran a yum update to get back on top of the latest releases.
Things went okay until I init 0'd to shut down my computer. At the
screen where all the processes get killed as Fedora goes down, I was
recieving tons of error messages that access to this file and that
file was blocked.
Today I booted up into Fedora, and I can not get to runlevel 5 as
SELinux is blocking EVERYTHING from running. I can not even "yum
update" as SELinux is blocking both the process as well as access to
the yum directory.
Is there anything I can do to 1) work around the problem, and 2) send
error logs of some sort to help track down the problem?
Any information would be greatly appreciated. Thanks,
-Sean
19 years, 1 month
Re: mkfs.ext3: Permission denied while trying to determine filesystem size
by Justin Conover
On 5/30/05, Valdis.Kletnieks(a)vt.edu <Valdis.Kletnieks(a)vt.edu> wrote:
> On Mon, 30 May 2005 11:33:28 CDT, Justin Conover said:
>
> OK, with this info, I'm convinced that (a) you're not nuts, (b) your system is
> labelled the way we told it to be labelled, and (c) we told it the wrong thing. ;)
>
Not so fast on "A" :D
> > # lvcreate -L2G -nLogVol10 VolGroup00
> > Logical volume "LogVol10" created
> >
> > # mkfs.ext3 /dev/VolGroup00/LogVol10
> > mke2fs 1.37 (21-Mar-2005)
> > Could not stat /dev/VolGroup00/LogVol10 --- Permission denied
>
> Could you do a 'ls -lZ /dev/VolGroup00'? I'd like to verify that lvcreate
> left LogVol10 labelled correctly - although I suspect that it got left what
> lvm thought it should be, and the policy wanted something else....
# ls -lZ /dev/VolGroup00
lrwxrwxrwx root root system_u:object_r:device_t
LogVol00 -> /dev/mapper/VolGroup00-LogVol00
lrwxrwxrwx root root system_u:object_r:device_t
LogVol01 -> /dev/mapper/VolGroup00-LogVol01
lrwxrwxrwx root root system_u:object_r:device_t
LogVol02 -> /dev/mapper/VolGroup00-LogVol02
lrwxrwxrwx root root system_u:object_r:device_t
LogVol03 -> /dev/mapper/VolGroup00-LogVol03
lrwxrwxrwx root root system_u:object_r:device_t
LogVol04 -> /dev/mapper/VolGroup00-LogVol04
lrwxrwxrwx root root system_u:object_r:device_t
LogVol05 -> /dev/mapper/VolGroup00-LogVol05
lrwxrwxrwx root root system_u:object_r:device_t
LogVol06 -> /dev/mapper/VolGroup00-LogVol06
lrwxrwxrwx root root system_u:object_r:device_t
LogVol07 -> /dev/mapper/VolGroup00-LogVol07
lrwxrwxrwx root root system_u:object_r:device_t
LogVol08 -> /dev/mapper/VolGroup00-LogVol08
lrwxrwxrwx root root system_u:object_r:device_t
LogVol10 -> /dev/mapper/VolGroup00-LogVol10
>
> > # grep mkfs audit/audit.log
> > type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr }
> > for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12
> > scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t
> > tclass=file
>
> This one looks like an attempt to scribble on a file called fedora.img -
> can you do a 'grep dm-7 /proc/mounts' and then do a 'find /filesys -name
> fedora.img -ls' and perhaps ls -lZ the file?
>
fedora.img is part of some Xen stuff I was doing, which initially
started this whole thing of mkfs not working.
> (Anybody recognize this one? I'm guessing it's a mkinitrd and dm-7 is /tmp...)
>
> > type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr }
> > for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12
> > scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t
> > tclass=file
>
> Another one of the same...
>
> > type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr }
> > for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs
> > ino=56551 scontext=root:system_r:fsadm_t
> > tcontext=root:object_r:device_t tclass=blk_file
>
> Here's the one that's causing yu the pain, and yes, it's borked up, and no,
> it doesn't apear to be your fault - the system (lvm in particular) could be
> doing a better job of labelling...
>
> Hmm.. I'll place bets that if you do a 'mkfs.ext3 /dev/dm-N' that it will work
> just fine, as they're created as fixed_disk_device_t. At least on my box, the
> symlink entries in /dev/VolGroup00 are being created as 'device_t' - and the
> targets in /dev/mapper are tmpfs_t (quite borked) of all things.
>
> Fortuitously, we have this in fsadm.te:
>
> # for /dev/shm
> allow fsadm_t tmpfs_t:dir { getattr search };
> allow fsadm_t tmpfs_t:file { read write };
>
> which seems to be likely to allow the access for all the wrong reasons.
>
> I'm thinking the symlinks in /dev/VolGroup00 should be fixed_disk_device_t rather
> than device_t - do others concur? And I'm suspecting the stuff in /dev/mapper
> needs to be set to fixed_disk_device_t as well - that way the /dev/dm-* and
> /dev/mapper/* entries for the same device are the same type (a nasty security
> exposure otherwise...)
>
> How do we get lvm to DTRT here? We can add a line to file_contexts/program/lvm.fc
> to fix the /dev/mapper entries:
>
> --- file_contexts/program/lvm.fc.dist 2005-05-20 14:53:12.000000000 -0400
> +++ file_contexts/program/lvm.fc 2005-05-30 13:10:03.000000000 -0400
> @@ -12,6 +12,7 @@
> /etc/lvm/lock(/.*)? system_u:object_r:lvm_lock_t
> /var/lock/lvm(/.*)? system_u:object_r:lvm_lock_t
> /dev/lvm -c system_u:object_r:fixed_disk_device_t
> +/dev/mapper/.* -c system_u:object_r:fixed_disk_device_t
> /dev/mapper/control -c system_u:object_r:lvm_control_t
> /lib/lvm-10/.* -- system_u:object_r:lvm_exec_t
> /lib/lvm-200/.* -- system_u:object_r:lvm_exec_t
>
> At least on my system, that leaves the /dev/mapper/* entries more sane....
>
> (Justin - the above patch won't fly unless you have policy-sources installed.
> If you're feeling brave, crazy, and adventurous, make a similar change to
> /etc/selinux/strict/contexts/files/file_contexts, and then do a
> 'restorecon -v -R /dev' - make sure to save a backup of file_contexts first.. ;)
>
> After that, you *should* be able to do a 'mkfs.ext3 /dev/mapper/VolGroup00-LogVol10'
>
> But that still leaves the symlinks in /dev/VolGroup00 set wrong. Do we need
> to add a 'follow symlink' in lvm.te? We can't fix this one in the file_contexts,
> because that dirname is essentially user-selected - on my system it's /dev/rootvg
> (guess who comes from an AIX background? ;)
>
> Or is there other borkedness here, and that it's the /dev/mapper/* that's causing
> Justin's indigestion, but we're reporting the context of the symlink rather than
> the target that's actually failing? (Anybody want to devise a quick test case
> for this one?)
>
I have no problem doing some of this if someone else chimes in too,
it's a new box I'm working on so there is nothing that a new install
wont cure for a borked system.
19 years, 1 month
Flash gone quiet
by Paul F. Johnson
Hi,
Not sure if this is an FC bug and if it is, what to file it under, but
flash games have gone totally silent!
Any ideas on this?
The sound system is working fine through XMMS, cdplayer and Xine.
TTFN
Paul
--
"Space", it says, "is big. Really big. You just won't believe how
vastly, hugely, mind-bogglingly big space really is. I mean, you may
think it's a long way down the road to the chemists, but that's just
*peanuts* compared to space, listen" - Hitch Hikers Guide to the Galaxy
19 years, 1 month
Re: mkfs.ext3: Permission denied while trying to determine filesystem size
by Justin Conover
On 5/30/05, Valdis.Kletnieks(a)vt.edu <Valdis.Kletnieks(a)vt.edu> wrote:
> On Mon, 30 May 2005 08:30:49 CDT, Justin Conover said:
>
> > Right, but why did it not let me created a file system with selinux=1?
> > I did a fresh install of fc4t3 on this box too, with the same
> > results.
>
> If you didn't already post the avc messages that mkfs generated (I've already
> deleted the first few msgs of this thread), could you do so? They'd be
> in /var/log/messages (if you have a default syslog config and aren't using
> auditd) or in /var/log/audit/audit.log if you have auditd running....
>
> Although I'm suspecting the problem is, as others have mentioned, that your
> system needs to be relabeled, and that an improper label on something broke
> the mkfs.
Ok, still have problems, set "enforcing=0" and relabeled and here is
all the bits.
# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 19
Policy from config file: targeted
<SNIP>
# mkdir /lvm_test_dir
# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 4
Metadata Sequence No 11
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 9
Open LV 9
Max PV 0
Cur PV 4
Act PV 4
VG Size 135.28 GB
PE Size 32.00 MB
Total PE 4329
Alloc PE / Size 1408 / 44.00 GB
Free PE / Size 2921 / 91.28 GB
VG UUID TxPt55-hDYK-lJmC-Aohb-LbGe-glnr-7046hW
# lvcreate -L2G -nLogVol10 VolGroup00
Logical volume "LogVol10" created
# mkfs.ext3 /dev/VolGroup00/LogVol10
mke2fs 1.37 (21-Mar-2005)
Could not stat /dev/VolGroup00/LogVol10 --- Permission denied
# grep mkfs audit/audit.log
type=SYSCALL msg=audit(1117397418.851:206892): arch=40000003
syscall=195 success=no exit=-13 a0=bf8aebdf a1=bf8605d8 a2=838ff4 a3=0
items=1 pid=2247 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3"
type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr }
for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12
scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t
tclass=file
type=SYSCALL msg=audit(1117397783.921:261196): arch=40000003
syscall=195 success=no exit=-13 a0=bf856bdf a1=bf7eed58 a2=bc7ff4 a3=0
items=1 pid=2308 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3"
type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr }
for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12
scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t
tclass=file
type=SYSCALL msg=audit(1117470602.109:1094349): arch=40000003
syscall=195 success=no exit=-13 a0=bf87fc52 a1=bf87e7a8 a2=a1dff4 a3=0
items=1 pid=4009 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3"
type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr }
for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs
ino=56551 scontext=root:system_r:fsadm_t
tcontext=root:object_r:device_t tclass=blk_file
19 years, 1 month
Re: Mono Stack on Fedora
by Teak Billard
Would Fedora Extras be the place to have Mono
available then or another repository such as Dag?
Teak
--- Dave Jones <davej(a)redhat.com> wrote:
> On Fri, May 27, 2005 at 05:16:19PM -0700, Teak
> Billard wrote:
> > Hello:
> >
> > I think the Mono stack has to be added to Fedora
> Core
> > 5. I've been trying out their Mono Live CD
> > <http://www.mono-live.com/> and it's great.
> > F-Spot/Beagle/Blam/Tomboy are all applications I
> would
> > like to use more often, outside of the few times
> I've
> > loaded up the mono live cd.
> >
> > I know that Red Hat has legal concerns over
> .NET/C#
> > but if that isn't the case with Fedora then
> Fedora
> > should go ahead and include Mono.
>
> It is the case with Fedora also. This has been
> beaten
> to death on the list numerous times.
>
> > I'm also talking about an inotify enabled kernel.
>
> Not until its accepted upstream.
>
> Dave
>
> --
> fedora-test-list mailing list
> fedora-test-list(a)redhat.com
> To unsubscribe:
>
http://www.redhat.com/mailman/listinfo/fedora-test-list
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
19 years, 1 month
