I have been happily running Fedora Core 2 for a year.
I just tried to install Fedora Core 4T3, but it fails with: ------------------------------------- There was an error installing cracklib-dicts-2.8.2-1. This can indicate media failure, lack of disk space, and/or hardware problems. This is a fatal error and your install will be aborted. -------------------------------------
If I switch over to F3, I see: ------------------------------------- Setting file_context_path to /etc/selinux/targeted/contexts/file_contexts -------------------------------------
F4 shows: ------------------------------------- <6>SELinux: initialized (dev hda3, type xfs), uses xattr <4>post_create: setxatter failed, rc=1 (dev=hda7 ino=16449) -------------------------------------
My partion layout is:
hda1: /boot (ext3) hda2: swap hda3: /home (xfs) hda4: extended hda5: / (Fedora core 2) (ext3) hda6: / (alternate root) (jfs) hda7: / (Fedora core 4T3) (jfs)
I booted off the DVD with "linux jfs", so it would allow me to format the root partion with jfs. I told it not to install SELinux.
I did test the media, and it is fine. Pretty sure my hardware is okay, since Fedora Core 2 is quite happy running on it.
Any other information I can provide to help track this problem down?
Thanks,
John
On Sunday 22 May 2005 04:58, John P Poet jppoet@gmail.com wrote:
I just tried to install Fedora Core 4T3, but it fails with:
There was an error installing cracklib-dicts-2.8.2-1. This can indicate media failure, lack of disk space, and/or hardware problems. This is a fatal error and your install will be aborted.
I booted off the DVD with "linux jfs", so it would allow me to format the root partion with jfs.
There will be errors setting XATTRs when disk space runs out. Setting an XATTR to a value that hasn't previously been used or setting an instance of an xattr name/value combination that is congruent to 0 mod 1024 will result in allocating a new disk block and will fail if there is no free block.
Anaconda is supposed to calculate the space needed for installation and refuse to install a combination of packages that will exceed the space. Maybe anaconda has the wrong idea about the amount of disk space required for JFS meta-data and will allow you to install what it thinks is 99% space usage which is really >100%.
I told it not to install SELinux.
This is a bug then. If you tell it not to install SE Linux then it shouldn't set any xattrs. Did you tell it via "selinux=0" or via the GUI in anaconda?
On 5/22/05, Russell Coker russell@coker.com.au wrote:
On Sunday 22 May 2005 04:58, John P Poet jppoet@gmail.com wrote:
I just tried to install Fedora Core 4T3, but it fails with:
There was an error installing cracklib-dicts-2.8.2-1. This can indicate media failure, lack of disk space, and/or hardware problems. This is a fatal error and your install will be aborted.
I booted off the DVD with "linux jfs", so it would allow me to format the root partion with jfs.
There will be errors setting XATTRs when disk space runs out. Setting an XATTR to a value that hasn't previously been used or setting an instance of an xattr name/value combination that is congruent to 0 mod 1024 will result in allocating a new disk block and will fail if there is no free block.
Anaconda is supposed to calculate the space needed for installation and refuse to install a combination of packages that will exceed the space. Maybe anaconda has the wrong idea about the amount of disk space required for JFS meta-data and will allow you to install what it thinks is 99% space usage which is really >100%.
I told it to format the "root" partition with JFS. The partition in question is 10gig, so it should have had plenty of space. That also seemed to be the first package it tried to install.
I told it not to install SELinux.
This is a bug then. If you tell it not to install SE Linux then it shouldn't set any xattrs. Did you tell it via "selinux=0" or via the GUI in anaconda?
Using the GUI in anaconda.
I reproduced the problem three times before posting. I finally told it to format the root partition with XFS instead of JFS, and then it worked fine.
It looks to me like there is a problem using JFS with Fedora Core 4T3.
John
On 5/22/05, Arjan van de Ven arjanv@redhat.com wrote:
I booted off the DVD with "linux jfs", so it would allow me to format the root partion with jfs.
please consider not using jfs instead.
Indeed, XFS works fine. Is it documented somewhere that JFS does not work with Fedora Core? Maybe installing/booting with "linux jfs" should be disabled?
Thanks,
John
On Sun, May 22, 2005 at 04:15:16PM -0600, John P Poet wrote:
On 5/22/05, Arjan van de Ven arjanv@redhat.com wrote:
I booted off the DVD with "linux jfs", so it would allow me to format the root partion with jfs.
please consider not using jfs instead.
Indeed, XFS works fine. Is it documented somewhere that JFS does not work with Fedora Core? Maybe installing/booting with "linux jfs" should be disabled?
"linux jfs" isn't documented afaik.
The simple situation is that ext3 is basically all we really support and test, the rest may or may not work. Is there a reason you want to use JFS ? (ext3 in fc3/fc4 is pretty competative with any of the other filesystems on just about every workload performance wise... the benchmarks I've seen from others hardly ever put JFS on top for anything nowadays so JFS strikes me as a bit of an odd choice)
On Mon, 23 May 2005, Arjan van de Ven wrote:
"linux jfs" isn't documented afaik.
The simple situation is that ext3 is basically all we really support and test, the rest may or may not work. Is there a reason you want to use JFS ? (ext3 in fc3/fc4 is pretty competative with any of the other filesystems on just about every workload performance wise... the benchmarks I've seen from others hardly ever put JFS on top for anything nowadays so JFS strikes me as a bit of an odd choice)
xfs and reiserfs are _huge_ wins over ext3 for news servers.
Any even for large ISP mailservers xfs and reiserfs are still huge wins over ext3.
Also our 'totally corrupt filesystems' statistics are much higher on ext3 than reiserfs so given all the above we've stopped deploying ext3 in new servers and only deploy reiserfs in new servers now.
A pity selinux doesnt work on reiserfs yet, but selinux has serious growing pains atm so we will wait for selinux to stabilize before we worry about that.
ext3 might be just dandy for desktops which I expect is the primary target market for fc3/fc4 but reiserfs/xfs are much better for typical ISP workloads.
-Dan
On Sun, 2005-05-22 at 23:50 -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
"linux jfs" isn't documented afaik.
The simple situation is that ext3 is basically all we really support and test, the rest may or may not work. Is there a reason you want to use JFS ? (ext3 in fc3/fc4 is pretty competative with any of the other filesystems on just about every workload performance wise... the benchmarks I've seen from others hardly ever put JFS on top for anything nowadays so JFS strikes me as a bit of an odd choice)
xfs and reiserfs are _huge_ wins over ext3 for news servers.
1) Did you try this on 2.4 or 2.6? 2.6 ext3 (with htree and reservations) is like a 3x improvement over the 2.4 ext3 in many workloads and is sometimes even slightly better than reiserfs in the "milions of files in a directory" scenario.
2) Did you set the ext3 journalling mode to be on par with reiserfs/xfs? (By default ext3 uses a more strict journalling mode to increase data integrity but that costs some performance vs reiserfs and xfs that don't have this extra protection)
On Mon, 23 May 2005, Arjan van de Ven wrote:
On Sun, 2005-05-22 at 23:50 -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
"linux jfs" isn't documented afaik. The simple situation is that ext3 is basically all we really support and test, the rest may or may not work. Is there a reason you want to use JFS ? (ext3 in fc3/fc4 is pretty competative with any of the other filesystems on just about every workload performance wise... the benchmarks I've seen from others hardly ever put JFS on top for anything nowadays so JFS strikes me as a bit of an odd choice)
xfs and reiserfs are _huge_ wins over ext3 for news servers.
- Did you try this on 2.4 or 2.6? 2.6 ext3 (with htree and
reservations) is like a 3x improvement over the 2.4 ext3 in many workloads and is sometimes even slightly better than reiserfs in the "milions of files in a directory" scenario.
Both.
Its not just for large directories, reiserfs did much better with many small files too (typical of news and mailservers). Note that reiserfs wins _big_ in this case performance wise if you turn off tailmerging. In my tests reiserfs lost vs ext3 on many-small-files-writing if you had tailmerging on, but this was a tradeoff for ~10% or more extra storage space you got from tailmerging.
- Did you set the ext3 journalling mode to be on par with reiserfs/xfs?
(By default ext3 uses a more strict journalling mode to increase data integrity but that costs some performance vs reiserfs and xfs that don't have this extra protection)
I tried all available ext3 journalling modes, it was never faster and often many times slower.
But even with non-strict journaling we got some total filesystem failures with ext3 where we did not with reiserfs and xfs on identical systems with identical hardware and identical workloads.
We still have a few ext3 machines about but they are being phased out and replaced with reiserfs as we get the chance.
-Dan
On Mon, May 23, 2005 at 12:24:55AM -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
On Sun, 2005-05-22 at 23:50 -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
"linux jfs" isn't documented afaik. The simple situation is that ext3 is basically all we really support and test, the rest may or may not work. Is there a reason you want to use JFS ? (ext3 in fc3/fc4 is pretty competative with any of the other filesystems on just about every workload performance wise... the benchmarks I've seen from others hardly ever put JFS on top for anything nowadays so JFS strikes me as a bit of an odd choice)
xfs and reiserfs are _huge_ wins over ext3 for news servers.
- Did you try this on 2.4 or 2.6? 2.6 ext3 (with htree and
reservations) is like a 3x improvement over the 2.4 ext3 in many workloads and is sometimes even slightly better than reiserfs in the "milions of files in a directory" scenario.
Both.
Its not just for large directories, reiserfs did much better with many small files too (typical of news and mailservers).
Hmm. that surprises me for htree enabled filesystems (note that if you create an FS with an old distro and then put 2.6 on it it doesn't use htree)
Arjan van de Ven wrote: ...
Hmm. that surprises me for htree enabled filesystems (note that if you create an FS with an old distro and then put 2.6 on it it doesn't use htree)
How can I check if an ext3 filesystem uses htree?
Mogens
On Mon, 23 May 2005, Mogens Kjaer wrote:
Arjan van de Ven wrote: ...
Hmm. that surprises me for htree enabled filesystems (note that if you create an FS with an old distro and then put 2.6 on it it doesn't use htree)
How can I check if an ext3 filesystem uses htree?
dumpe2fs -h <partition> | grep features
If dir_index is in the list of filesystem features then htree is used.
- Panu -
Panu Matilainen wrote: ...
dumpe2fs -h <partition> | grep features
If dir_index is in the list of filesystem features then htree is used.
Hm, most of my FC3 systems doesn't have this feature enabled.
I guess they have either been upgraded, or at some time backed up & restored.
I'll fix this in rescue mode:
tune2fs -Odir_index <partition> e2fsck -f -D <partition>
Wouldn't it be a good thing to include this automatically during an upgrade?
Mogens
On Mon, 23 May 2005, Arjan van de Ven wrote:
Both. Its not just for large directories, reiserfs did much better with many small files too (typical of news and mailservers).
Hmm. that surprises me for htree enabled filesystems (note that if you create an FS with an old distro and then put 2.6 on it it doesn't use htree)
Remember reiserfs was designed from the bottom up to work quickly with lots of _small files_. So it does what it was designed to do well. That this happens to be the typical workload of news servers and mailservers is a happy coincidence.
Remember this is _not_ purely about directory sizes.
-Dan
On Mon, May 23, 2005 at 03:02:23AM -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
Both. Its not just for large directories, reiserfs did much better with many small files too (typical of news and mailservers).
Hmm. that surprises me for htree enabled filesystems (note that if you create an FS with an old distro and then put 2.6 on it it doesn't use htree)
Remember reiserfs was designed from the bottom up to work quickly with lots of _small files_. So it does what it was designed to do well. That this happens to be the typical workload of news servers and mailservers is a happy coincidence.
yet a design goal leads to a technological implementation, and I'm wondering what is a causing factor for ext3 to not be roughly equally fast. ext3 with htree should in principle not be bad at lots of small files. at all. There is no inherent bias in ext3 towards bigger files (well except when you count not having tail merging; tail merging will give you gain in the case of a read-mostly lots-of-small-files case)
On Mon, 23 May 2005, Arjan van de Ven wrote:
On Mon, May 23, 2005 at 03:02:23AM -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
Both. Its not just for large directories, reiserfs did much better with many small files too (typical of news and mailservers).
Hmm. that surprises me for htree enabled filesystems (note that if you create an FS with an old distro and then put 2.6 on it it doesn't use htree)
Remember reiserfs was designed from the bottom up to work quickly with lots of _small files_. So it does what it was designed to do well. That this happens to be the typical workload of news servers and mailservers is a happy coincidence.
yet a design goal leads to a technological implementation, and I'm wondering what is a causing factor for ext3 to not be roughly equally fast. ext3 with htree should in principle not be bad at lots of small files. at all. There is no inherent bias in ext3 towards bigger files (well except when you count not having tail merging; tail merging will give you gain in the case of a read-mostly lots-of-small-files case)
I think some of this has to do with the fact that ext3 is fundamentally a very, very, very old filesystem. Its some of the oldest code still in the kernel iirc. Some of the assumptions made in the original design may no longer be so relevant over a decade later. ext2 was in use when everyone was still on PIO and C/H/S :-) reiserfs by comparison is brand spanking new.
I recall hearing something about a tailmerging patch for ext2/3 somewhere. What happened to that?
-Dan
On Mon, May 23, 2005 at 03:22:37AM -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
On Mon, May 23, 2005 at 03:02:23AM -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
Both. Its not just for large directories, reiserfs did much better with many small files too (typical of news and mailservers).
Hmm. that surprises me for htree enabled filesystems (note that if you create an FS with an old distro and then put 2.6 on it it doesn't use htree)
Remember reiserfs was designed from the bottom up to work quickly with lots of _small files_. So it does what it was designed to do well. That this happens to be the typical workload of news servers and mailservers is a happy coincidence.
yet a design goal leads to a technological implementation, and I'm wondering what is a causing factor for ext3 to not be roughly equally fast. ext3 with htree should in principle not be bad at lots of small files. at all. There is no inherent bias in ext3 towards bigger files (well except when you count not having tail merging; tail merging will give you gain in the case of a read-mostly lots-of-small-files case)
I think some of this has to do with the fact that ext3 is fundamentally a very, very, very old filesystem. Its some of the oldest code still in the kernel iirc.
By no means true.
Some of the assumptions made in the original design may no longer be so relevant over a decade later. ext2 was in use when everyone was still on PIO and C/H/S :-)
actually that isn't the case. sure there was an ext2 way back. But it moved forward quite a bit (htree is an example of that).
reiserfs by comparison is brand spanking new.
reiserfs3 isn't so new though, it is like 6 years old. reiserfs4 is entirely unrelated to reiserfs3.
The biggest difference between reiserfs3 and ext3 is that reiserfs3 is more tree based on disk and ext3 uses blockgroups on disk. For directories they nowadays both uses trees (since ext3 grew htrees). I haven't seen conclusive evidence either way which is architectually better; trees tend to be a bit more fragile but can do certain things better (but other things really poor, if the tree has to rebalance all the time, in addition trees tend to cause more fragementation longer term). Also there is a difference between the on disk storage of metadata and the in memory one.
If you want to use reiserfs, by all means be my guest. Some people only think they have performance gains with it, others really do. Reiserfs in fedora tends to be "lightly tested" at best though, so make sure you test it hard yourself before going into production.
On Mon, 23 May 2005, Arjan van de Ven wrote:
If you want to use reiserfs, by all means be my guest. Some people only think they have performance gains with it, others really do. Reiserfs in fedora tends to be "lightly tested" at best though, so make sure you test it hard yourself before going into production.
For us its not a question of 'only thinking'. We actually tested it and got clear performance wins.
We tested ext3, jfs, xfs, and reiserfs.
For us reiserfs is the clear winner for ISP workloads.
Its been heavily tested and works fine for us, thanks :-)
Our reiserfs results interested a business partner of ours who used to swear by ext3. They also found out reiserfs was better all round for them so they are also switching.
The only real caveat for reiserfs at the moment is the lack of selinux support.
Oh yes, I also use reiserfs at home on the desktop with tailmerging enabled. An extra 10% diskspace is significant especially when its 200gb partitions :-)
-Dan
On Monday 23 May 2005 20:58, Dan Hollis goemon@anime.net wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
If you want to use reiserfs, by all means be my guest. Some people only think they have performance gains with it, others really do. Reiserfs in fedora tends to be "lightly tested" at best though, so make sure you test it hard yourself before going into production.
For us its not a question of 'only thinking'. We actually tested it and got clear performance wins.
We tested ext3, jfs, xfs, and reiserfs.
For us reiserfs is the clear winner for ISP workloads.
Does it work correctly as a root file system?
The following extract from reiserfsck(8) indicates that it won't:
--rebuild-tree This option rebuilds the entire filesystem tree using leaf nodes found on the device. Normally you only need this option if the reiserfsck --check reports "Running with --rebuild-tree is required". You are strongly encouraged to make a backup copy of the whole partition before attempting the --rebuild-tree option. Once reiserfsck --rebuild-tree is started it must finish its work (and you should not interrupt it), otherwise the filesystem will be left in the unmountable state to avoid subsequent data corruptions.
Our reiserfs results interested a business partner of ours who used to swear by ext3. They also found out reiserfs was better all round for them so they are also switching.
Unless of course they want to do some common file system recovery options such as putting an image of a file system on another file system. The last reports were that if you put a Reiser3 image as a regular file in a Reiser3 file system then fsck would really mess things up.
The only real caveat for reiserfs at the moment is the lack of selinux support.
How is it lacking? In a quick test it seems to work.
On Wed, 25 May 2005, Russell Coker wrote:
On Monday 23 May 2005 20:58, Dan Hollis goemon@anime.net wrote:
For us reiserfs is the clear winner for ISP workloads.
Does it work correctly as a root file system?
Yes.
The following extract from reiserfsck(8) indicates that it won't: --rebuild-tree This option rebuilds the entire filesystem tree using leaf nodes found on the device. Normally you only need this option if the reiserfsck --check reports "Running with --rebuild-tree is required". You are strongly encouraged to make a backup copy of the whole partition before attempting the --rebuild-tree option. Once reiserfsck --rebuild-tree is started it must finish its work (and you should not interrupt it), otherwise the filesystem will be left in the unmountable state to avoid subsequent data corruptions.
Why does that indicate reiserfs won't function as a root file system?
Our reiserfs results interested a business partner of ours who used to swear by ext3. They also found out reiserfs was better all round for them so they are also switching.
Unless of course they want to do some common file system recovery options such as putting an image of a file system on another file system. The last reports were that if you put a Reiser3 image as a regular file in a Reiser3 file system then fsck would really mess things up.
Er. This is true of _any_ journaled filesystem on top of an journaled filesystem (xfs, jfs, and iirc ext3) due to bad interactions with linux's caching. The general wisdom is to not do this, no matter what filesystem.
Alternatively you could put a reiser3 image on ext2 if you really want to do that. It's not hard.
The only real caveat for reiserfs at the moment is the lack of selinux support.
How is it lacking? In a quick test it seems to work.
reiserfs (at least up to 2.6.11.10) doesnt have working support for selinux attributes.
this is in fact a very well known problem[1]. though supposedly 2.6.12 is supposed to fix this[2].
-Dan
[1]http://www.fedorafaq.org/#reiserjfs [2]http://www.livejournal.com/users/james_morris/3580.html
On Wednesday 25 May 2005 21:01, Dan Hollis goemon@anime.net wrote:
The following extract from reiserfsck(8) indicates that it won't: --rebuild-tree This option rebuilds the entire filesystem tree using leaf nodes found on the device. Normally you only need this option if the reiserfsck --check reports "Running with --rebuild-tree is required". You are strongly encouraged to make a backup copy of the whole partition before attempting the --rebuild-tree option. Once reiserfsck --rebuild-tree is started it must finish its work (and you should not interrupt it), otherwise the filesystem will be left in the unmountable state to avoid subsequent data corruptions.
Why does that indicate reiserfs won't function as a root file system?
When (not if) the root file system needs a thorough fsck any interruption (such as power failure) will result in a non-bootable system.
But it's still a significant improvement, it used to be that --rebuild-tree was not permitted on a ro mounted file system so booting from an install CD was necessary to check the root fs.
Our reiserfs results interested a business partner of ours who used to swear by ext3. They also found out reiserfs was better all round for them so they are also switching.
Unless of course they want to do some common file system recovery options such as putting an image of a file system on another file system. The last reports were that if you put a Reiser3 image as a regular file in a Reiser3 file system then fsck would really mess things up.
Er. This is true of _any_ journaled filesystem on top of an journaled filesystem (xfs, jfs, and iirc ext3) due to bad interactions with linux's caching. The general wisdom is to not do this, no matter what filesystem.
No it's not. Put an ext3 image inside an ext3 file system and try to reproduce the problem. You will discover that ext3 is not vulnerable to this. Also try it on HPFS (non-journalled file system used by OS/2) and you will discover similar problems.
It's nothing to do with journalling. It's a problem of recognising metadata, file systems which have fixed locations for metadata have a much easier time of this.
Alternatively you could put a reiser3 image on ext2 if you really want to do that. It's not hard.
Sure it's not hard. That's nice to know AFTER you've done it and had your data corrupted (as has happened to several people).
This is also a security issue. For example you might be able to put a file in your home directory which contains a ReiserFS image of a file system containing a SUID file and then have a fsck make it a regular file owned by root with the SUID bit set which would allow taking over the machine.
In a quick test I managed to create a SUID root file in such a manner, but it seemed corrupted and could not be executed.
Hopefully Reiser4 will solve this issue.
The only real caveat for reiserfs at the moment is the lack of selinux support.
How is it lacking? In a quick test it seems to work.
reiserfs (at least up to 2.6.11.10) doesnt have working support for selinux attributes.
The latest rawhide kernel seems to have it. Did you do any tests?
Finally, are there still known situations where a corrupt ReiserFS file system could corrupt kernel memory? This was the bug that got me to convert the root file systems of machines I own to use Ext2/3.
On Wed, 25 May 2005, Russell Coker wrote:
On Wednesday 25 May 2005 21:01, Dan Hollis goemon@anime.net wrote:
Why does that indicate reiserfs won't function as a root file system?
When (not if) the root file system needs a thorough fsck any interruption (such as power failure) will result in a non-bootable system. But it's still a significant improvement, it used to be that --rebuild-tree was not permitted on a ro mounted file system so booting from an install CD was necessary to check the root fs.
Note that XFS won't let you fsck a readonly-mounted fs _at all_. Even a non destructive read-only check. I've argued with the XFS developers about this and they stated they don't see this as a problem and they're not going to fix it. I have no idea why they think this is a good idea.
Alternatively you could put a reiser3 image on ext2 if you really want to do that. It's not hard.
Sure it's not hard. That's nice to know AFTER you've done it and had your data corrupted (as has happened to several people).
Who?
The only real caveat for reiserfs at the moment is the lack of selinux support.
How is it lacking? In a quick test it seems to work.
reiserfs (at least up to 2.6.11.10) doesnt have working support for selinux attributes.
The latest rawhide kernel seems to have it. Did you do any tests?
You mean FC4T3 installer has it? Or you mean the latest kernel downloadable via yum updater?
Finally, are there still known situations where a corrupt ReiserFS file system could corrupt kernel memory? This was the bug that got me to convert the root file systems of machines I own to use Ext2/3.
None that I know of. If there were you would expect them to be reported in linux-kernel or bugzilla, and I don't see anything.
I do however see some serious recent issues with ext3: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149478 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139374
We can go around in circles endlessly posting tit-for-tat comparisons of ext3 and reiserfs. Neither FS is flawless and both have their issues. However reiserfs has been perfect for our needs in every way and in production systems has shown zero failures whereas we had many total losses with ext3.
-Dan
On Wednesday 25 May 2005 22:47, Dan Hollis goemon@anime.net wrote:
When (not if) the root file system needs a thorough fsck any interruption (such as power failure) will result in a non-bootable system. But it's still a significant improvement, it used to be that --rebuild-tree was not permitted on a ro mounted file system so booting from an install CD was necessary to check the root fs.
Note that XFS won't let you fsck a readonly-mounted fs _at all_. Even a non destructive read-only check. I've argued with the XFS developers about this and they stated they don't see this as a problem and they're not going to fix it. I have no idea why they think this is a good idea.
Interesting. I've got a couple of machines that can only boot with an XFS root. Fortunately I can easily remove the disks from them.
Alternatively you could put a reiser3 image on ext2 if you really want to do that. It's not hard.
Sure it's not hard. That's nice to know AFTER you've done it and had your data corrupted (as has happened to several people).
Who?
Me and Roger Wolff.
Just repeat the test I performed a few hours ago. Why are you so argumentative about things which you can easily test? You don't have to believe me, do your own tests and you'll get the same results.
reiserfs (at least up to 2.6.11.10) doesnt have working support for selinux attributes.
The latest rawhide kernel seems to have it. Did you do any tests?
You mean FC4T3 installer has it? Or you mean the latest kernel downloadable via yum updater?
2.6.11-1.1319_FC4 has it. As for FC4T3, that depends on the kernel, the installer, etc. Why not test it?
Ext3 is the default file system for Fedora for reasons which have already been explained. As the default choice Ext3 gets the most testing from Red Hat employees, also Ext3 is a priority for testing as it's in RHEL. The purpose of this list is for people from the community to assist us with testing, and this particularly applies to non-default options. It would be good if you could help us in this regard.
I'm sure that FC4 release will have a kernel at least as recent as 2.6.11-1.1319_FC4. So I don't expect any problems using ReiserFS and SE Linux on FC4 release.
Finally, are there still known situations where a corrupt ReiserFS file system could corrupt kernel memory? This was the bug that got me to convert the root file systems of machines I own to use Ext2/3.
None that I know of. If there were you would expect them to be reported in linux-kernel or bugzilla, and I don't see anything.
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.
On Thu, 26 May 2005, Russell Coker wrote:
The purpose of this list is for people from the community to assist us with testing, and this particularly applies to non-default options. It would be good if you could help us in this regard.
It would be nice if you would stop arguing against people using non-default options then :-)
If you want things like reiserfs tested then stop arguing against people using it :-)
-Dan
On Thursday 26 May 2005 04:18, Dan Hollis goemon@anime.net wrote:
On Thu, 26 May 2005, Russell Coker wrote:
The purpose of this list is for people from the community to assist us with testing, and this particularly applies to non-default options. It would be good if you could help us in this regard.
It would be nice if you would stop arguing against people using non-default options then :-)
I am not making a blanket argument against ReiserFS. ReiserFS will work fine for /var/spool/news or /var/spool/mail, also it has never had any SE Linux issues for such use, there's the context= mount option and prior to that people were using ReiserFS on SE Linux systems with genfscon entries in the policy to give all ReiserFS files the desired context. One machine I ran had ReiserFS used for /var/spool/squid and was configured such that all ReiserFS files had the type squid_cache_t.
Also given the fsck issue, it's probably best to mount ReiserFS file systems as nodev,nosuid.
On Wed, 2005-05-25 at 05:47 -0700, Dan Hollis wrote:
You mean FC4T3 installer has it? Or you mean the latest kernel downloadable via yum updater?
FC4T3 kernel should have included the reiserfs xattr fixes to make it work with SELinux, as the fixes were included in upstream kernels >= 2.6.12-rc1, and 2.6.12-rc1 was included in FC4 kernels a long time ago (1.1187, 2005/03/18). For that matter, I would have expected it in FC4T2 as well.
On Wed, 25 May 2005, Stephen Smalley wrote:
On Wed, 2005-05-25 at 05:47 -0700, Dan Hollis wrote:
You mean FC4T3 installer has it? Or you mean the latest kernel downloadable via yum updater?
FC4T3 kernel should have included the reiserfs xattr fixes to make it work with SELinux, as the fixes were included in upstream kernels >= 2.6.12-rc1, and 2.6.12-rc1 was included in FC4 kernels a long time ago (1.1187, 2005/03/18). For that matter, I would have expected it in FC4T2 as well.
Nope, FC4T3 is busted and not only that, it won't be fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159123
-Dan
On Mon, May 30, 2005 at 08:47:53PM -0700, Dan Hollis wrote:
On Wed, 25 May 2005, Stephen Smalley wrote:
On Wed, 2005-05-25 at 05:47 -0700, Dan Hollis wrote:
You mean FC4T3 installer has it? Or you mean the latest kernel downloadable via yum updater?
FC4T3 kernel should have included the reiserfs xattr fixes to make it work with SELinux, as the fixes were included in upstream kernels >= 2.6.12-rc1, and 2.6.12-rc1 was included in FC4 kernels a long time ago (1.1187, 2005/03/18). For that matter, I would have expected it in FC4T2 as well.
Nope, FC4T3 is busted and not only that, it won't be fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159123
As with any unsupported component, you can file a bug in the upstream bugzilla (bugzilla.kernel.org in this case), and Fedora will inherit any fixes in a future update.
Dave
On Mon, 2005-05-30 at 20:47 -0700, Dan Hollis wrote:
On Wed, 25 May 2005, Stephen Smalley wrote:
On Wed, 2005-05-25 at 05:47 -0700, Dan Hollis wrote:
You mean FC4T3 installer has it? Or you mean the latest kernel downloadable via yum updater?
FC4T3 kernel should have included the reiserfs xattr fixes to make it work with SELinux, as the fixes were included in upstream kernels >= 2.6.12-rc1, and 2.6.12-rc1 was included in FC4 kernels a long time ago (1.1187, 2005/03/18). For that matter, I would have expected it in FC4T2 as well.
Nope, FC4T3 is busted and not only that, it won't be fixed:
No - just we don't spend any developer time in anaconda on it - if you send patches for specific anaconda/Fedora reiser fixups then they'll get considered for inclusion.
Paul
On Wed, 25 May 2005, Russell Coker wrote:
On Wednesday 25 May 2005 21:01, Dan Hollis goemon@anime.net wrote:
How is it lacking? In a quick test it seems to work.
reiserfs (at least up to 2.6.11.10) doesnt have working support for selinux attributes.
The latest rawhide kernel seems to have it. Did you do any tests?
Yep I just finished testing.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159123
there you go, as you requested.
-Dan
On Mon, May 23, 2005 at 03:22:37AM -0700, Dan Hollis wrote:
I think some of this has to do with the fact that ext3 is fundamentally a very, very, very old filesystem. Its some of the oldest code still in the kernel iirc. Some of the assumptions made in the original design may no longer be so relevant over a decade later. ext2 was in use when everyone was still on PIO and C/H/S :-) reiserfs by comparison is brand spanking new.
Not really. The fs has had major reworking over time and its one of the few very SMP scalable file systems for example. Nor is it from the world of PIO and C/H/S - it doesn't care about geometry and it threw out a lot of the old BSD cruft like interleave and rotational latency tricks that were old world.
I recall hearing something about a tailmerging patch for ext2/3 somewhere. What happened to that?
tailmerging is very 1980's, its not been worth deploying in the real world for the past ten or more years. BSD FFS did big blocks on small disks in order to get large block sizes to handle the lack of good command queueing and the latency of block requests, and then needed the tail/fragment hacks to cover up the space lossage. Nowdays nobody wants to trade 10-20% of performance for 1% more disk space given the price of disks and the disks can stream data at high speed without 8K blocks.
Alan
On Mon, 23 May 2005, Alan Cox wrote:
Nowdays nobody wants to trade 10-20% of performance for 1% more disk space given the price of disks and the disks can stream data at high speed without 8K blocks.
Alan self appointed spokesperson for the entire world :-)
At least on my home machine I got ~10% extra disk space and only take a small performance hit on writes. Its like having a 220gb disk instead of a 200gb one. Thats worth it to me at least.
And at least its an option for end users to choose, instead of "the one and only true way" ala steve jobs applethink.
-Dan
Hi
A pity selinux doesnt work on reiserfs yet, but selinux has serious growing pains atm so we will wait for selinux to stabilize before we worry about that.
There is a patch for reiserfs to support xattr but upstream isnt interested. An explanation of the "growing pains" would also be useful
regards Rahul
On Mon, 23 May 2005, Rahul Sundaram wrote:
A pity selinux doesnt work on reiserfs yet, but selinux has serious growing pains atm so we will wait for selinux to stabilize before we worry about that.
There is a patch for reiserfs to support xattr but upstream isnt interested. An explanation of the "growing pains" would also be useful
"not production ready" eg not ready for deployment in ISP production environment. When people stop filing critical selinux bugs in buzilla then it will be production ready :-)
And of course the lack of reiserfs support is a non starter for us too.
-Dan
Hi
"not production ready" eg not ready for deployment in ISP production environment. When people stop filing critical selinux bugs in buzilla then it will be production ready :-)
Using just the number of bug reports to assert whether something is production ready or not looks like a bad idea to me. Take a look at the bug count against any major package like the kernel or xorg for comparison
regards Rahul
On Mon, 23 May 2005, Rahul Sundaram wrote:
"not production ready" eg not ready for deployment in ISP production environment. When people stop filing critical selinux bugs in buzilla then it will be production ready :-)
Using just the number of bug reports to assert whether something is production ready or not looks like a bad idea to me. Take a look at the bug count against any major package like the kernel or xorg for comparison
I'm not using just the number. I'm using the criticality of the bugs. Eg showstoppers.
Would _you_ seriously deploy FC4T3+selinux in a corporate production server right now?
-Dan
Hi
I'm not using just the number. I'm using the criticality of the bugs. Eg showstoppers.
Would _you_ seriously deploy FC4T3+selinux in a corporate production server right now?
-Dan
It wasnt clear to me that you were talking about SELinux specifically in the test releases. Test releases by design are not fit for production, let alone SELinux in it. Of course I wouldnt suggest doing that
regards Rahul
On Mon, 23 May 2005, Rahul Sundaram wrote:
I'm not using just the number. I'm using the criticality of the bugs. Eg showstoppers. Would _you_ seriously deploy FC4T3+selinux in a corporate production server right now?
It wasnt clear to me that you were talking about SELinux specifically in the test releases. Test releases by design are not fit for production, let alone SELinux in it. Of course I wouldnt suggest doing that
Ok, would you recommend FC3+selinux in a corporate production environment then?
-Dan
On Mon, 2005-05-23 at 03:04 -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Rahul Sundaram wrote:
I'm not using just the number. I'm using the criticality of the bugs. Eg showstoppers. Would _you_ seriously deploy FC4T3+selinux in a corporate production server right now?
It wasnt clear to me that you were talking about SELinux specifically in the test releases. Test releases by design are not fit for production, let alone SELinux in it. Of course I wouldnt suggest doing that
Ok, would you recommend FC3+selinux in a corporate production environment then?
I'd not recommend FC<anything> in a corporate production environment, I'd recommend RHEL for such environments. (and yes RHEL4 has selinux enabled by default)
Dan Hollis wrote:
On Mon, 23 May 2005, Rahul Sundaram wrote:
"not production ready" eg not ready for deployment in ISP production environment. When people stop filing critical selinux bugs in buzilla then it will be production ready :-)
Using just the number of bug reports to assert whether something is production ready or not looks like a bad idea to me. Take a look at the bug count against any major package like the kernel or xorg for comparison
I'm not using just the number. I'm using the criticality of the bugs. Eg showstoppers.
Would _you_ seriously deploy FC4T3+selinux in a corporate production server right now?
good joke :-) [...] not production ready [...] seriously deploy FCxTx+selinux in a corporate production [...]
* *http://www.net-security.org/search.php?sort=0&keyword=selinux&search... -> http://www.net-security.org/news.php?id=7755 -> http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1082560,00...
<snip> *"Think before deploying Security-Enhanced Linux in RHEL 4"
*One of the most exciting new features in RHEL v.4 is the implementation of Security-Enhanced Linux (SELinux). In this tip, we'll look at how you can use it to beef up system security. </snip>
On Monday 23 May 2005 17:31, Dan Hollis goemon@anime.net wrote:
On Mon, 23 May 2005, Rahul Sundaram wrote:
A pity selinux doesnt work on reiserfs yet, but selinux has serious growing pains atm so we will wait for selinux to stabilize before we worry about that.
There is a patch for reiserfs to support xattr but upstream isnt interested. An explanation of the "growing pains" would also be useful
"not production ready" eg not ready for deployment in ISP production environment. When people stop filing critical selinux bugs in buzilla then it will be production ready :-)
SE Linux is enabled by default in RHEL4, it is a supported and recommended feature.
I am not aware of any bugs reported against SE Linux that would make it unsuitable for use in an ISP. I know of some ISPs that have it on their servers.
On Wednesday 25 May 2005 21:02, Dan Hollis goemon@anime.net wrote:
On Wed, 25 May 2005, Russell Coker wrote:
I am not aware of any bugs reported against SE Linux that would make it unsuitable for use in an ISP. I know of some ISPs that have it on their servers.
which isps?
I don't know of any that have given permission for such information to be published.
On Mon, 2005-05-23 at 12:39 +0530, Rahul Sundaram wrote:
Hi
A pity selinux doesnt work on reiserfs yet, but selinux has serious growing pains atm so we will wait for selinux to stabilize before we worry about that.
There is a patch for reiserfs to support xattr but upstream isnt interested. An explanation of the "growing pains" would also be useful
Actually, reiserfs xattr support went upstream a while back, and fixes to the reiserfs xattr support to allow use with SELinux are included in kernels >= 2.6.12-rc1 (and thus in the FC4 kernels).
On Sat, 2005-05-21 at 12:58 -0600, John P Poet wrote:
I have been happily running Fedora Core 2 for a year.
I just tried to install Fedora Core 4T3, but it fails with:
There was an error installing cracklib-dicts-2.8.2-1. This can indicate media failure, lack of disk space, and/or hardware problems. This is a fatal error and your install will be aborted.
If I switch over to F3, I see:
Setting file_context_path to /etc/selinux/targeted/contexts/file_contexts
F4 shows:
<6>SELinux: initialized (dev hda3, type xfs), uses xattr
<4>post_create: setxatter failed, rc=1 (dev=hda7 ino=16449)
My partion layout is:
hda1: /boot (ext3) hda2: swap hda3: /home (xfs) hda4: extended hda5: / (Fedora core 2) (ext3) hda6: / (alternate root) (jfs) hda7: / (Fedora core 4T3) (jfs)
I booted off the DVD with "linux jfs", so it would allow me to format the root partion with jfs. I told it not to install SELinux.
I did test the media, and it is fine. Pretty sure my hardware is okay, since Fedora Core 2 is quite happy running on it.
Any other information I can provide to help track this problem down?
The errno displayed by post_create was EPERM. Looking at the jfs code, it appears that they return EPERM from can_set_xattr() if the file is a symlink. SELinux attempts to label all files, including symlinks. Please report to the jfs maintainers, as it is a bug in their code.