hi. i recently installed 9.3 pro (from the 5-cd set, not the dvd). all's well except the root partition, which is probably not umounting at shutdown time. the shutdown sequence says "umounting hdb6", but at the next boot it still does an XFS recovery on that partition. this was not the case in 9.2, where XFS recovery ran only when there was an unclean shutdown. just to check what was happening, i used the magic-sysrq combos to sync the disks, remount the partitions r/o, kill all tasks, and instant-reboot. upon the subsequent boot, there was no XFS recovery. i don't thnk it's an XFS driver issue, because the other XFS partitions don't have this problem. here's my partition structure: hdb1 /boot ext3 50 mb hdb5 swap 500 mb hdb6 / xfs 10 gb hdb7 /home xfs 105 gb only hdb6 has the problem, the others are fine. i applied almost all relevant patches through YOU, but the problem persists. ok - i didn't install the kernel patch because that broke the system once on 9.2, and i'm slightly phobic about it. if the kernel patch is a sure cure for this, i'll try it. but if it isn't, i'd rather try other options first. thanks in advance. - t. -- cogito, ergo es.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2005-06-19 at 23:11 +0530, Tathagata Banerjee wrote:
i applied almost all relevant patches through YOU, but the problem persists. ok - i didn't install the kernel patch because that broke the system once on 9.2, and i'm slightly phobic about it. if the kernel patch is a sure cure for this, i'll try it. but if it isn't, i'd rather try other options first.
Frankly, you should apply whatever kernel patches are available from SuSE, unless you have a definite reason to know it will not work - and you haven't. Your problem might be solved, or it might not, but you will not know unless you try. And, if you are afraid it might break your system, simply have the DVD available, and make sure you can boot the rescue system. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCtg6wtTMYHG2NR9URAug0AJwO03SoAlc+lxq3GvCNac2nUBxiOwCdHDy4 VN5uFIsj1xuKeaMlISR33s0= =/4G2 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Frankly, you should apply whatever kernel patches are available from SuSE, unless you have a definite reason to know it will not work - and you haven't.
Personally I prefer "if it ain't broke, don't fix it". No matter who provides the patch. /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - managed anti-spam and anti-virus solution. Starting at EUR20/year - sign up for your free 30-day trial now!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-06-20 at 12:18 +0200, Per Jessen wrote:
Personally I prefer "if it ain't broke, don't fix it". No matter who provides the patch.
The original poster stated a problem... thus, it is broken. And, where security is involved, there is no excuse not to apply security patches - unless you know that the patch is broken. If you don't, and somebody breaks into your computer, don't cry later. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCtqRntTMYHG2NR9URAp1aAJ9SM+Mtn6RahqmM7xpJxOqbXb9bIgCfd/jC I2+KvA+I8qBCPdqQUrjp2iI= =yP0q -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Monday 2005-06-20 at 12:18 +0200, Per Jessen wrote:
Personally I prefer "if it ain't broke, don't fix it". No matter who provides the patch.
The original poster stated a problem... thus, it is broken.
Agreed, but you proposed applying patches uncritically - "apply whatever kernel patches are available".
And, where security is involved, there is no excuse not to apply security patches -
Of course - but like you said, something is broken. IMHO, applying patches uncritically and without knowing what they fix, is not the way to go. Be selective and apply what you need. /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - managed anti-spam and anti-virus solution. Starting at EUR20/year - sign up for your free 30-day trial now!
Per, On Monday 20 June 2005 06:18, Per Jessen wrote:
...
Agreed, but you proposed applying patches uncritically - "apply whatever kernel patches are available".
SuSE doesn't produce kernel updates (or any other updates) for the hell of it. In the case of the kernel, only fixes for verified security or crashing bugs elicit kernel updates.
...
/Per Jessen, Zürich
Randall Schulz
Randall R Schulz wrote:
SuSE doesn't produce kernel updates (or any other updates) for the hell of it. In the case of the kernel, only fixes for verified security or crashing bugs elicit kernel updates.
Admitted, I don't use the SuSE patches myself (we only run vanilla kernels), but are they always "clean", ie. nothing else slips in "on the side"? Even so, I'd still be careful with the ones for "crashing bugs" - if they don't manifest themselves on my system, why apply a fix? I guess much depends on what the system is used for, but for a production system, any change is a risk and I still believe in "if it ain't broke, don't fix it". /Per Jessen, Zürich
Per, On Monday 20 June 2005 07:14, Per Jessen wrote:
Randall R Schulz wrote:
SuSE doesn't produce kernel updates (or any other updates) for the hell of it. In the case of the kernel, only fixes for verified security or crashing bugs elicit kernel updates.
Admitted, I don't use the SuSE patches myself (we only run vanilla kernels), but are they always "clean", ie. nothing else slips in "on the side"?
They list all the changes applied in every patch released via YOU. If you don't trust the YOU updates, then why do you trust any package built by SuSE / Novell?
Even so, I'd still be careful with the ones for "crashing bugs" - if they don't manifest themselves on my system, why apply a fix?
Because the conditions that elicit such a crash may occur on your system in the future, of course. I'd say your paranoia is best directed elsewhere.
I guess much depends on what the system is used for, but for a production system, any change is a risk and I still believe in "if it ain't broke, don't fix it".
I don't agree, in general, and many of us run systems that are not what is usually considered "production." My policy, which has not caused me any problems, is to apply all YOU patches. For the most part, I'm greedy about new software, new capabilities and enjoying the nice steady stream of improvements that issue forth from the Open Source community. Take KDE, for example: Over the past year it has progressed immensely, and I for one would not want to forgo all those improvements.
/Per Jessen, Zürich
Randall Schulz
Randall R Schulz wrote:
They list all the changes applied in every patch released via YOU. If you don't trust the YOU updates, then why do you trust any package built by SuSE / Novell?
For the same reason that I in my +15 years in the IBM world also trusted the IBM shipped software, but not the patches. Release-quality software is usually put through rigorous testing - patches are often too, but far from as a matter of course.
I'd say your paranoia is best directed elsewhere.
Randall, I (obviously) disagree about this being paranoia. As a sysadmin you should be fully aware of what is running on your systems. Applying patches and fixes more or less in the blind is not the way to go about that. Whether or not you trust the supplier.
many of us run systems that are not what is usually considered "production."
I totally appreciate that, but I don't think it can be taken as the rule. (Why stick to only SuSEs patches if you're not in some form of controlled environment?)
My policy, which has not caused me any problems, is to apply all YOU patches. For the most part, I'm greedy about new software, new capabilities and enjoying the nice steady stream of improvements that issue forth from the Open Source community. Take KDE, for example: Over the past year it has progressed immensely, and I for one would not want to forgo all those improvements.
On my personal workstation I apply exactly what you've just described, but for most other systems, customers depend on them being up and running, so the risk involved in applying an _unnecessary_ (kernel or not) patch is not warranted. There's room for everyone of course, but I have a number of production systems to run 7x24. Downtime is scheduled about one month in advance, preferably around Christmas :-) My general system uptimes are +300 days with a couple of exceptions in both ends. Anyway, I was merely trying to suggest a careful change policy, I didn't intend to dictate to anyone how to run their system(s). /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - managed anti-spam and anti-virus solution. Sign up for your free 30-day trial now!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-06-20 at 22:05 +0200, Per Jessen wrote:
many of us run systems that are not what is usually considered "production."
I totally appreciate that, but I don't think it can be taken as the rule. (Why stick to only SuSEs patches if you're not in some form of controlled environment?)
Er... the OP did not specify his system being a production one. Obviously, the update policy for a production machine is different. I assumed a home system for my answer. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCt1nctTMYHG2NR9URAjf0AJ41sPzQDvOkE/2809yB9sk3NW1zNQCgkGmx UPNwl/fA6DC80ojB8SQOVJw= =9iME -----END PGP SIGNATURE-----
Per, On Monday 20 June 2005 13:05, Per Jessen wrote:
Randall R Schulz wrote:
...
I'd say your paranoia is best directed elsewhere.
Randall, I (obviously) disagree about this being paranoia. As a sysadmin you should be fully aware of what is running on your systems. Applying patches and fixes more or less in the blind is not the way to go about that. Whether or not you trust the supplier.
This just does not make any sense. They do detail the changes they put into each YOU update. And again, if you don't trust the provider you've chosen, then you might as well skip a commercial distribution altogether and build the system from sources yourself. That's the only way you'll be "fully aware of what is running on your systems." That, and read and fully comprehend all the source code for that software. You might as well write all the software you're going to run if you feel you need such a total, complete, and deep understanding of the code you're running. What you're saying just doesn't work in practice. You have to trust someone or you won't get anywhere. And no matter how much you think you know about what you're running, you can't be fully assured of preventing crashes, break-downs or break-ins. And the characterization "blind" is yours, not mine. To make it a policy to install all kernel updates doesn't mean install them without being aware of what they do or contain, just that in order to be abreast of all the security and bug fixes extant, you can't skip releases.
many of us run systems that are not what is usually considered "production."
I totally appreciate that, but I don't think it can be taken as the rule. (Why stick to only SuSEs patches if you're not in some form of controlled environment?)
It's not a rule, just a recognition that many people aren't using SuSE Professional to run mission-critical systems. And many people will advise you _not_ to use SuSE Pro or Fedora for such systems and stick to the more reliable "enterprise" variants from the respective vendors. My employer runs its huge fleet of production Linux systems on RHEL3. Sadly, we have to use the same for development, which irks me, but I live with it.
My policy, which has not caused me any problems, is to apply all YOU patches. For the most part, I'm greedy about new software, new capabilities and enjoying the nice steady stream of improvements that issue forth from the Open Source community. Take KDE, for example: Over the past year it has progressed immensely, and I for one would not want to forgo all those improvements.
On my personal workstation I apply exactly what you've just described, but for most other systems, customers depend on them being up and running, so the risk involved in applying an _unnecessary_ (kernel or not) patch is not warranted. There's room for everyone of course, but I have a number of production systems to run 7x24. Downtime is scheduled about one month in advance, preferably around Christmas :-) My general system uptimes are +300 days with a couple of exceptions in both ends.
Again, SuSE Professional is a leading-edge distribution. If you have these requirements, then it's a dubious choice to use such a distribution instead of one of the more stable enterprise counterparts.
Anyway, I was merely trying to suggest a careful change policy, I didn't intend to dictate to anyone how to run their system(s).
And I don't think my suggestion is lacking in carefullness, but as you say, each system administrator must make that determination for themselves.
/Per Jessen, Zürich
Randall Schulz
Randall R Schulz wrote:
And many people will advise you _not_ to use SuSE Pro or Fedora for such systems and stick to the more reliable "enterprise" variants from the respective vendors.
Yeah, well. Those variants have only been around for so long - they weren't around when most of my systems were installed, and I'm not convinced there is anything gained by changing now. But quite possibly in the future.
My employer runs its huge fleet of production Linux systems on RHEL3. Sadly, we have to use the same for development, which irks me, but I live with it.
To some extent I can't help thinking that the various "enterprise" versions are nothing more than a safety-blanket for pointy-haired managers.
Again, SuSE Professional is a leading-edge distribution. If you have these requirements, then it's a dubious choice to use such a distribution instead of one of the more stable enterprise counterparts.
What did people do _before_ the enterprise versions came about? Did we all run dubious systems? Most systems here are based on SuSE 8.2, one or two are still 7.3, and I think one or two non-critical boxes might be on 9.0 by now. There's little bleeding edge around here. /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - managed anti-spam and anti-virus solution. Starting at EUR30/year - sign up for your free 30-day trial now!
Per, On Tuesday 21 June 2005 00:19, Per Jessen wrote:
Randall R Schulz wrote:
...
My employer runs its huge fleet of production Linux systems on RHEL3. Sadly, we have to use the same for development, which irks me, but I live with it.
To some extent I can't help thinking that the various "enterprise" versions are nothing more than a safety-blanket for pointy-haired managers.
They're not something for which I feel a need, but I'm not responsible for mission-critical operations. When we have significant outages, people lose their jobs. Since we do a lot of on-line business, a down system is lost sales and possibly lost customers. The head honchos at my place take such things very, very seriously.
Again, SuSE Professional is a leading-edge distribution. If you have these requirements, then it's a dubious choice to use such a distribution instead of one of the more stable enterprise counterparts.
What did people do _before_ the enterprise versions came about? Did we all run dubious systems? Most systems here are based on SuSE 8.2, one or two are still 7.3, and I think one or two non-critical boxes might be on 9.0 by now. There's little bleeding edge around here.
Keep in mind Linux is young. It's the youngest OS used supporting large-scale commercial operations. Before there were supported, more heavily tested enterprise distributions, end users were accepting much more of the responsibility of keeping a Linux system going. This is not a good way to promote an OS and people like the founders of RedHat and SuSE saw the opportunity to sustain and promote Linux and do so in a profitable way. And here we are. I pretty much trust the people at SuSE and appreciate their work. That's why I buy my distributions and do so regularly. That's also why I apply YOU patches regularly (while paying attention to just what I'm applying).
/Per Jessen, Zürich
Randall Schulz
Randall R Schulz wrote:
They're not something for which I feel a need, but I'm not responsible for mission-critical operations. When we have significant outages, people lose their jobs. Since we do a lot of on-line business, a down system is lost sales and possibly lost customers. The head honchos at my place take such things very, very seriously.
Also, some applications or servers might only be supported on certain distros or versions.
Okay, stupid question time: if I'm just trying to change the sizes of my reiserfs partitions in 9.1Pro (shrinking one half-empty partition to make some room for an overcrowded one), is the process destructive? Or simply high-risk? I'm making backups either way, but I'd like to know just how much of a chance I'm taking here...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-06-20 at 15:18 +0200, Per Jessen wrote:
The original poster stated a problem... thus, it is broken.
Agreed, but you proposed applying patches uncritically - "apply whatever kernel patches are available".
You omit one word from what I said: "available from SuSE". That is critical to my statement. Not _any_ patches, but those provided by SuSE, ie, the official patches, which are only security patches. I never recommended to apply any patch uncritically. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCt1dZtTMYHG2NR9URAkX/AJ9FlJ7WxWrCtH7VAClc9o1dHVZDjgCeKsSx Ub+bOdlAmw3YcQDm8+vsKLo= =NNvZ -----END PGP SIGNATURE-----
yes, it's a home system, not production. and yes, i finally applied the kernel patch because without that this thread wasn't going anywhere. the patch didn't break anything, but neither did it solve my problem. here's the current output of "dmesg|grep XFS" : SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled SGI XFS Quota Management subsystem XFS mounting filesystem hdb6 Starting XFS recovery on filesystem: hdb6 (dev: hdb6) Ending XFS recovery on filesystem: hdb6 (dev: hdb6) XFS mounting filesystem hdb7 Ending clean XFS mount for filesystem: hdb7 now that the patch issue is out of the way, does anyone have any idea what may be wrong with my system? as an aside, let me add that i *do* trust SuSE to do their best for customers, but to err is human. one of their kernel patches in 9.2 broke the system badly, and it was updated in a hurry; i'm sure everyone on this list remembers that. i was one of the sufferers, and i had to restore the original kernel in rescue-boot mode. i wished i had waited to let the patch sink in for a few days before applying it. i'm ignorant about production systems and their management policies; this was just a home user's twopence, for what it's worth. thanks. - t. -- cogito, ergo es.
Tathagata Banerjee wrote:
as an aside, let me add that i *do* trust SuSE to do their best for customers, but to err is human.
I couldn't have said that any better. /Per Jessen, Zürich -- http://www.spamchek.ch/freetrial - managed anti-spam and anti-virus solution. Ab Sfr30/Jahr - überzeugen Sie sich - 30 Tage kostenlos und unverbindlich!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2005-06-21 at 10:56 +0530, Tathagata Banerjee wrote:
the patch didn't break anything, but neither did it solve my problem.
Well, at least we know that that is not the problem :-}
now that the patch issue is out of the way, does anyone have any idea what may be wrong with my system?
The script responsible for boot up fsck in SuSE 9.3 is /etc/init.d/boot.rootfsck (and /etc/init.d/boot.localfs checks the rest of the partitions). There are several tests it does to determine if the partition should be checked; one is the existence of the file '/forcefsck', for example. Another is that the file '/fastboot' should not exist. Later, the script '/etc/init.d/boot.localfs' deletes '/fastboot'. If I remember correctly, the flag file '/fastboot' is created during halt to denote that the system was properly closed; but I can't find now who creates it. It might be failing, the root partition might be umounted or the system halted before it flushes that file. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCt/zotTMYHG2NR9URAhUNAJ44ut43bfaNlas0G/CJ8h9jirzVugCfdUCJ 9CnWVUHAEVzLlK15jyDaZrw= =SauO -----END PGP SIGNATURE-----
Carlos E. R. wrote:
You omit one word from what I said: "available from SuSE". That is critical to my statement. Not _any_ patches, but those provided by SuSE, ie, the official patches, which are only security patches. I never recommended to apply any patch uncritically.
True, I did - to underline that to me it doesn't really matter where the patches come from. I think all patches need to be carefully selected and carefully applied. But obviously for a home-system, it matters little. I think I just jumped on your blanket statement about patches and didn't bother realising that the OP was in a different environment to mine. /Per Jessen, Zürich -- http://www.spamchek.ch/freetrial - managed anti-spam and anti-virus solution. Ab Sfr30/Jahr - überzeugen Sie sich - 30 Tage kostenlos und unverbindlich!
participants (6)
-
Carlos E. R. -
David McMillan -
James Knott -
Per Jessen -
Randall R Schulz -
Tathagata Banerjee