Red Hat 7.2 Released

Spirit writes "Red Hat has anounced the release of Version 7.2 distribution with Gnome 1.4 and Nautilus, default ext3 fliesystem and according to ZDnet migration from LILO to GRUB"

Updated by HeUnique:There are some issues to note before upgrading: The kernel that comes with the RH 7.2 is heavily patched 2.4.7 and has been tested quite heavily on fully loaded Linux boxes - so the recommendation is to use it

If you're upgrading from the previous Red Hat 7.1 and you're using Ximian GNOME, then you might want to erase all Ximian GNOME RPMS (use the command: rpm -e `rpm -qa | grep -i ximian` --nodeps to erase the RPMS). Red Hat's GNOME RPMS has been more tested then Ximian's one and there is a conflict between them. You cannot use Red-Carpet on Redhat 7.2 as it will fail with the RPM libraries.

These are the most critical notes about Redhat 7.2. You might want to read the README & the Release-notes which appears on the 1st ISO image.

Oh, and if you already installed it - then have some fun with the new un-official RPMS from Enigma's section of FreshRPMS

to forestall the inevitable -- why not reiserfs?

[Anonymous Coward]

To forestall the inevitable questions
-- why not reiserfs, xfs, jfs, etc.

First look at the total feature
list of ext3 and compare, in particular the
compatibility (forwards AND backwards) with ext2.

There may or may not be better candidates for
a fs, but there are certainly none better for
a default install.

Re:LILO vs. GRUB

[phutureboy]

Nothing to fear with GRUB. I've been using it for about a year. Configuring it is a little different than with LILO, but it works fine.

Re:First impression

[bero-rh]

Redhat has dropped support for Postfix (a sendmail replacement), which used to be on the Powertools CD. I really don't know why

It's because Powertools was dropped, and everything on Powertools that conflicts with something on a main CD (e.g. you can't install postfix and sendmail on the same system) had to go because at this time, the installer doesn't handle conflicting packages (breaking the "Everything" install isn't nice).

This is likely to get fixed in a future release (no promises though, it's not my decision [I'm all for postfix]).

Those who prefer it can grab the current official postfix package from rhcontrib [bero.org]. I'll open up the 7.2 section there later today.

Since it is a .2 version, RedHat is going to support it for a looong time

<obligatory "we don't preannounce releases" rant>
What makes you think the next release will be 8.0? ;)
</rant>

Re:First impression

[Alan Cox]

Not me - I did a bit of benchmarking but that is my sole contribution to nautilus. Lots of other folks both inside and outside of RH did all the work.

Re:What a crapfest

[|DeN|niS]

For example, they're using ext3. Blech. It is a journaling system tacked on to the old ext2 system, which seems a little too much like the evolution of FAT to me.

FAT? Hardly! ext3 uses is built on extension hooks designed into ext2, allowing you to mount ext3 partitions with an ext2-only kernel (of course no journalling in that case). Also, it takes a few seconds to "convert" ext2 to ext3, can't get easier than that! :-)

Personally I find it impressive that the foresight in the ext2 design allowed for ext3 to evolve the way it did with the backwords compatibility

And hey, it just works. Performance is like ext2, except you never have to fsck anymore when the machine doesn't shut down properly. And your ext2 bootfloppies still work, you don't have to reformat your partitions first, and did I mention it just works? :-)

So why not? ReiserFS would be more suited for news spool and squid cache partitions, but if you just want your same old system except for the fsck's, ext3 is the way to go.

Re:Name...

[joestar]

"Enigma" - wasn't it the name of this German machine that was used to encrypt secret messages during WWII ?

Re:Is RH including proprietary sw these days?

[Alan Cox]

gcc 2.96-RH is all open , always has been. Gcc 3 is not quite compatible so wouldnt be appropriate for the base tools for a new release. It is on the CD though if you want it

The only nonfree stuff on the RH distro should be netscape, and we recommend mozilla 8)

Re:GRUB ?

[Haeleth]

GNU GRUB != GRUB. I don't know which version this is, but RMS will be annoyed if they've left off a GNU... :D

From the GNU GRUB Faq:

1. How does GNU GRUB differ from Erich's original GRUB?
GNU GRUB is the successor of Erich's great GRUB. He couldn't work on GRUB because of some other tasks, so the current maintainer Gordon Matzigkeit took over the maintainership, and opened the development in order for everybody to participate it.

Technically speaking, GNU GRUB has many features that are not seen in the original GRUB. For example, GNU GRUB can be installed on UNIX-like operating system (i.e. GNU/Linux) via the grub shell /sbin/grub, it supports Logical Block Address (LBA) mode that solves the 1024 cylinders problem, and TAB completes a filename when it's unique. Of course, many bug fixes are done as well, so it is recommended to use GNU GRUB.

Think mirrors!

[French Thias]

I've put up a "known to be fully synced" mirror list here :

http://freshrpms.net/misc/enigma.html [freshrpms.net]

Also, don't forget to go get all the "missing" goodies (xine, lame, nessus...) from http://enigma.freshrpms.net/ [freshrpms.net]

Happy download! :-)

Matthias

Stress test time for the ftp servers.

[Alan Cox]

UK folks should find
ftp://zeniiib.linux.theplanet.co.uk/pub/distribu ti ons/redhat/7.2

nice and fast (its the new linux.org.uk test box)

Alan

Re:GRUB ?

[Anonymous Coward]

Maybe you should read the article, fuckwit. GRUB is filesystem-aware, editable on the fly, features a command prompt like a REAL boot loader, and features none of the limitations of LILO.

Redhat explained the choice of ext3 before

[clarkie.mg]

On this page [linuxtoday.com], a redhat employee explained why they chose ext3.

It was also the topic of a previous slashdot post [slashdot.org].

This extract sums it up :

Why do you want to migrate from ext2 to ext3? Four main reasons: availability, data integrity, speed, and easy transition.

[...]

Again, we don't claim that every one of these points are unique to ext3. Most of them are shared by at least one other filesystem. We merely claim that the set of all of them together is true only for ext3.

Re:Question about the ISO files

[Nachtfalke]

I don't know exactly what is on Disc 2, but I do know that you need both discs for a complete install, the second CD is not optional.

Re:to forestall the inevitable -- why not reiserfs

[bero-rh]

An official statement on why ext3 was chosen (ext2 compatibility is a major reason, but not the only one) can be found here [linuxtoday.com].

Re:Without Fail...

[Baki]

Not really, but gradually and constantly: There is a -current and a -stable CVS branch. You can follow the -stable CVS branch to stay completely uptodate all the time. Nothing ever breaks except on major announcements and big MFC's (merge from current) that are announced. At those times it may be necessary to revisit your config files in /etc (which can be automated with 'mergemaster').

Thus, you never have to download a new version, but you can always download incremental diffs (daily) that patch the complete source tree (cvsup). I have not reinstalled my FreeBSD system in 5 years time, yet it is 100% clean (all add-ons and optional parts to into /usr/local and don't spoil the main OS) and up to date.
(cd /usr/src; make world from time to time).

How to download 7.2....

[unperson]

1. Go to the official ftp.redhat.com site and get the MD5SUM:

efab549656a1a85ab8fa39eb873eff0e enigma-SRPMS-disc1.iso
70703897af7703b40e41777a3aa186c3 enigma-SRPMS-disc2.iso
cf7bce0c1cdbfedfae29e60aef202f6f enigma-i386-disc1.iso
fd705b3e5d0e37a828db35d21195a9f6 enigma-i386-disc2.iso

2. Go to any available mirror that isn't slashdotted...I found:

ftp://linux.nssl.noaa.gov

Mirror in Europe

[Yenya]

a 100Mbps mirror in Czech Republic, Europe can be found at ftp.linux.cz [linux.cz].

Re:to forestall the inevitable -- why not reiserfs

[bero-rh]

Please provide a testcase. Our tests have shown that (unless you compile in full debugging), ext3 is actually faster than ext2.

ext3 migration is seamless

[James Youngman]

I migrated my / filesystem (only the one Linux filesystem on my laptop - it dual-boots) from ext2 ro ext3. Totally seamless. No time lost with fsck.

I accidentally nobbled the ext3 module (by upgrading the kernel and omitting the initrd that normally loads the ext3 module from linuxrc). Red Hat seamlessly mounted as ext2 - no loss of data (but obviously no journalling). Puttng the initrd back brought me back into the ext3 fold, again seamlessly. It was completely painless -I was really impressed. This experience is with 7.1.93 - I have not yet tried 7.2

In fact, I might not ever try 7.2 because of the really annoying ppp-watcher in 7.1. I had an ISP problem where the chat script would fail to authenticate, and the ppp-watcher just dialled again and again and again... Really annoying, and hard to change. I'm sure I'd miss RH if I stopped using it because I've used it since RH 2.1. For the moment I'm running Red Hat 7.1.93 at home and Debian on my laptop.

LILO is not synonymous with GRUB

[Ranger Rick]

1. GRUB kicks LILO's ass, feature-wise.
2. GRUB understands filesystems.
3. GRUB doesn't screw you if you forget to run a program after changing the configuration file.
4. GRUB lets you enter a configuration manually at boot time if you *do* screw up the configuration file.
5. GRUB can boot on some broken BIOSes and hard drives that LILO cant.
6. GRUB has the same interface across all platforms it runs on, which saves RedHat from having different boot instructions on different architectures (and having to do extra testing on each of those architectures).

Besides, RedHat lets you choose at installation, so you can <sarcasm>"leverage" the mountain of knowledge you have about LILO</sarcasm>. Like there's so much to know...

Re:Custom kernel

[deaddeng]

I've had no problems compiling and using custom kernels under the 7.2 beta, aka "Roswell." You just need to patch the stable 2.4.12 tree for ext3 support, or use the -ac kernels, which already incorporate ext3 support. I've found 2.4.12-ac3 to be a very stable kernel with good memory and VM behavior. RedHat kernels are closer to -ac kernels right now, it would appear, than to Linus' main kernel tree.

Re:Question about the ISO files

[chabotc]

Disk 2 contains a few less-used packages, most of the -devel.rpm's, and some server daemons.

All in all, unless you do a extrememe minimal instalation, you will _definatly_ need disk to.

The point i'm trying to make, it is not a 'PowerTools' or 'Addons' disk, it is an intergral part of the instalation!

They have merged the PowerTools into the main instalation set (leaving out not often used, or badly maintained, or conflicting tools). So currently there is no 'Addons' cd's.

.. Unless you get the $199 Redhat 7.2 Pro set, which has (if i remeber correctly) 6 cd's containing quite a few extra apps and daemons.

Re:What about ReiserFS?

[Cheeze]

the reason for ext3 over resier is the ability to non-destructively upgrade an ext2 drive. with reiserfs, you have to format the drive, which means dataloss for those that can't just 'tar zcvf /dev/tape /'. i'm sure there are other reasons too, but for most people, that ability is important.

Re:ipsec, freeS/WAN and RedHat

[bero-rh]

I understand RedHat cannot integrate ipsec / FreeS/WAN into the Linux distribution because of US export restrictions.

I don't think the export restrictions you're referring to are still in place.

We're currently shipping cipe, which provides pretty much the same functionality.

There have been some reasons for choosing cipe over FreeS/WAN. I don't remember the details, but I think it was related to not supporting non-x86 arches.

Re:GCC 3.01

[bero-rh]

Mostly for 2 reasons:

• It breaks binary compatibility, which we can't do in a minor release
• It produces broken code when C++ is used. Try compiling KDE 2.x (or 3.x) with it; every application will crash because of a miscompilation in kdelibs

Re:don't understand the need for constant upgradin

[miniver]

I'm still running 6.2 w/ any patches that concern me.
I don't particularly see any need to upgrade to 7.0, 7.1 or 7.2 for that matter.
What's the big deal?

I've used every version of RedHat since 3.3, and several versions of Mandrake over the last 6 years. That's a lot of upgrading, particularly since I have several servers and workstations running Linux. My firewall/proxy/router is still running a heavily upgraded version of RH 6.1, and my mail server is running a butchered version of RH 6.0. My internal web server and all of the workstations are running RH 7.1, and I'll be upgrading some of those to RH 7.2 in the near future, as it stabilizes.

Here's a short list of my reasons to upgrade to RH 7.X:

• Convenience: I like RedHat and RPM, because it means I can spend my time developing and deploying applications instead of spending my time configuring software. Since I build distributed applications for a living, I find it convenient to be able to mirror my development and deployment environment at home, and RPM is a great way to make certain that all of the servers are configured correctly and running the same versions of the necessary software. Of course, convenience has a price, and with RedHat, the price is that RPMs for newer software are built for the most recent release.
• OpenSSL/OpenSSH: you can't beat the convenience of having these pre-installed and working from RPMs. Anyone who's had to build these from scratch and then configure them will appreciate not having to repeat that procedure every time someone finds a new bug.
• Apache 1.3.20: One word: security.
• 2.4 Kernels: Much better for heavily threaded servers, because of the finer locking granularity.
• XFree 4.X: Better support for graphics hardware for my workstations.

Ultimately with Red Hat, they've done a good job of supporting older X.2 releases, but support doesn't mean adding new features. If you want the new features, you'll want to upgrade. If you don't want/need them, then stick with what works. At least Red Hat (and most Linux distros) give you that choice -- as opposed to certain eXtra Proprietary systems.

Re:Recommend you use a vulnerable kernel ?

[Zapdos]

This has been patched. Nothing to see here folks move along.

Re:to forestall the inevitable -- why not reiserfs

[bero-rh]

I want to know why ReiserFS debugging was turned on in 7.1

Because our tests have shown the version of ReiserFS in the 7.1 kernel to produce filesystem corruption under some circumstances.

Avoiding that (or at least giving us a chance to debug it) was more important than getting it to full speed.

We haven't seen fs corruption in the 7.2 kernel, so it's turned off now.

Re:First impression

[Anonymous Coward]

e.g Compile a library with gcc3 , compile
an app using the library with gcc 2.X. -->
Will porbably(and probably is not good enough) not work, atleast not for C++ programs.

Redhat tries to maintain binary compability in
their major releases, Binary compability is a _very_ good thing
but often neglected in the opensource world

Try out RedHat 7.2

[Test Drive]

We now have RedHat 7.2 up and running in the Compaq Test Drive Program [compaq.com], so you can try it on our systems before you put it on yours. It's running on a couple of dual-processor x86 systems, and using the ext3 file system. Sign up for a free account [compaq.com] and give it a try.

Re:GRUB ?

[Saint Aardvark]

Amen to that, brother...last year after fucking up LILO for the nth time, I grabbed GRUB and installed it. Wonderful! Amazing! Can't recommend it enough! One of the cool things: you can tell GRUB to hide drives when certain operating systems are booted. What point, you ask? Well, I've finally got a dual-boot Linux/Windows machine with Windows NOT on the first hard drive, in the first partition. Go for GRUB, people. And one hint: if you're using Debian (like me) and you get "invalid device errors" when trying to install to the hard drive, get the latest version. I'm not sure if there's a .deb for 0.90 in -unstable; I just went to the source [gnu.org] and got it there.

Go, GRUB, go!

RedHat 7.2 kernel and glibc updates.

[Shane]

kernel-headers-2.4.9-7.i386.rpm
kernel-2.4.9-7.i386.rpm
kernel-doc-2.4.9-7.i386.rpm
kernel-source-2.4.9-7.i386.rpm
kernel-BOOT-2.4.9-7.i386.rpm
nscd-2.2.4-19.i386.rpm
glibc-common-2.2.4-19.i386.rpm
glibc-devel-2.2.4-19.i386.rpm
glibc-profile-2.2.4-19.i386.rpm
glibc-2.2.4-19.i386.rpm
openssh-askpass-gnome-2.9p2-9.i386.rpm
openssh-2.9p2-9.i386.rpm
openssh-askpass-2.9p2-9.i386.rpm
openssh-clients-2.9p2-9.i386.rpm
openssh-server-2.9p2-9.i386.rpm
squid-2.4.STABLE1-6.i386.rpm
mew-1.94.2-12.i386.rpm
util-linux-2.11f-12.i386.rpm

Ximian GNOME for Red Hat Linux 7.2 is out!

[Peter Teichman]

Ximian GNOME for Red Hat Linux 7.2 has been released. Please don't follow the instructions in the article for removing Ximian GNOME, as that will break your rpm dependency tree pretty badly.

The recommended procedure for upgrading to Red Hat Linux 7.2 with Ximian GNOME is to perform the Red Hat upgrade, then immediately reinstall Ximian GNOME.

lynx -source http://go-gnome.com/ |sh

The mirrors will pick it up shortly.

Share and enjoy,
The Ximian release team

Please mod parent up and a note to Hemos and co.

[luge]

Just to re-emphasize, Hemos's instructions for 'cleaning' Ximian will seriously break your system- it'll remove glib (among other things) which will remove a large number of RH's system tools. So... don't.
Luis Villa [Ximian Bugmaster, who doesn't want to have to deal with 'Hemos broke my system' bugs all day]

Re:Ximian GNOME for Red Hat Linux 7.2 is out!

[luge]

You have to install specifically for RH 7.2 from the web; the Red Carpet on the CD won't be of any help because of changes in librpm between 7.1 and 7.2.

Re:I am stoked!

[bero-rh]

issue and issue.net get clobbered by a file called redhat-release at start-up

This is intentional to make sure people calling up support can tell them which kernel they're running.
The correct way to change it is to edit /etc/rc.d/init.d/rc.local.

WTF can't you just use inetd.conf?

inetd was dumped precisely because inetd.conf sucks.
One of big advantages of xinetd is that packages can add themselves to xinetd without having to do ugly sed or perl tricks on a file.

Now you've got this thing called GRUB. Do any of the other distros have it?

Sure. Mandrake does, Debian does. Don't know about the others.

What happens when I decide I want to upgrade to kernel 2.4.12 - does it automagically know how to install itself on this new, poorly named bootloader?

If you install the RPM, yes, GRUB will know about it. If you install from source, you have to edit grub.conf (but you don't need to reinstall GRUB afterwards).

Speaking of which, why is 2.96-RH STILL the default compiler?

• We don't break binary compatibility between minor releases
• It's still the most stable compiler out there - 3.0.1 miscompiles KDE and other C++ code

But taking industry-standard files and replacing them with something silly

If a standard is broken, it needs to be fixed. (Any website still running on HTML 1.0?)

xinetd is pretty much a standard right now - almost every Linux distribution has it, and it's in FreeBSD's ports collection.

Much the same is happening/has already happened for GRUB.

RH, for some reason, can't be happy with keeping the samba files in /etc

There is no standard whatsoever that asks for putting them straight in /etc.
I don't know why the change was made (I don't do samba and I've never used it), but I'd think it's in order to make it more obvious which users need to edit nmbd.conf and which users can simply ignore it (or better yet deinstall the package, but there are quite a number of everything installs out there because people can't figure out which packages they need).

What you RH people don't seem to understand is that some of us still like to edit config files

Most of us understand. I for one don't use GUI config tools (except for testing, or to get a base configuration up to tune by hand later on).

could you _please_ stop mangling the text files they parse in the first place?

One of the things that sets Red Hat Linux apart from some other distributions is, actually, that most of our config tools try to parse existing config files rather than simply dumping any changes made by the user.

if you guys have got the time to troll on /. as much as you're doing today, 7.2 had better be bug-free.

This is a cyclic thing - right now, we have much less work than shortly before the engineering freeze for 7.2. The development of the next version has already started quite some time ago, of course - but a lot of the changes require waiting for other projects to finish, so at this time, we have some spare time. (And besides, it's long after office hours around here, so don't think I'm wasting work time. Granted, since I don't have a life I'd probably be hacking if I weren't reading /., but...).

Re:Without Fail...

[Arandir]

And now to rebut...

ext3 is just as robust, and doesn't require a fsck at all after a power cycle.

The fsck on a softupdates volume is blazingly fast. To be sure, ext3 is a nice file system, but that doesn't mean all the other ones are crap.

OpenOffice for Linux doesn't run, and native AbiWord in 4.4-release doesn't start. Koffice import filters for .doc don't seem to be working either.

Use the native OpenOffice. I didn't have any problems with AbiWord. And KOffice filters are identical under Linux and FreeBSD.

up2date takes care of all that for in-distro packages.

Yeah, for the in-distro packages. But that ignores the major flaw of RPM: you have to use RPM for everything or you screw up your system. With FreeBSD you can use packages, ports, or compile by hand, and nothing gets out of sync.

Except maybe just doing a half-hour upgrade and getting back to work, rather than compiling all day ...

Ever heard of multitasking? Compile everything in the background while you work in the foreground. Plus, if you cvsup once a week, you're never so far behind that you need to compile "all day". Or better yet, if you're into precompiled packages, just upgrade the packages!

Nautilus, f.e., doesn't even start in 4.4's GNOME distribution.

I didnt have any problem at all with Nautilus (other than the fact that it's slower than molasses).

On the server side, you can't just install fbsd and use it as a NAT or enable quotas without recompiling the kernel.

Huh? A coworker of mine installed FreeBSD "out of the box" for his server and had it up and running in half an hour. He never had to recompile anything. I don't know much about NAT (except that my coworker got it running without recompiling), but quotas are already in the shipping kernel.

FreeBSD just takes more work.

It does require that you use more than two brain cells, and it does require you to make some sort of effort to get it installed and administered. But since when has that been a drawback in the Unix world?

Re:I am stoked!

[bero-rh]

That's why I said "most" config tools.
I know there are some exceptions (mostly due to schedules that had to be kept - we can't always get all wanted features into the first version...).

The non bandaid solution is to standardize on a particular format for config files

This is true - but I don't think you can get every project to follow the same standard.

We actually talked about something like this internally (basically, "provide one standard library for every config stuff, then fork every app to make use of it and ask maintainers to apply the patch"), but dismissed the idea quite quickly because that would definitely be a nonstandard thing giving people legitimate reasons to complain about ("Oh, you're using the Red Hat version of my application? Then I can't help you, I don't know anything about it, and I don't like their config layout"), and more "Red Hat is just like Microsoft, now they're forcing everyone to use their crap rather than compiling from source!" type FUD.

In an ideal world, we'd all be using the same format for config files (how do you represent /etc/sendmail.cf in key=value or xml, by the way?) - but it's almost certainly not going to happen, at least not anytime soon.

Even OSes that try to enforce one config scheme on everything (e.g. M$ registry) end up with applications that create their own config files using something totally different.

Re:RH just became a whole lot more expensive

[rajumd]

Huh? According to Redhat's site [redhat.com] it's $990 for 10 machines for a year! And I suspect you can get even bigger discounts if you're going to register 50 machines.