Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
ah... well.. but its 32bit OS for sure from reading the responses. So many things were done with this system, I can't reinstall it with a new 64bit OS. but I know now what to upgrade with.
One admin at my company decided to update xfs with 64bit on this system and now its crashing. oh well... life has its weird challenging moments.
I really appreciate your feedbacks.
Thanks so much!
Switching from 32bit to 64bit requires (at least on package based systems) doing a clean install. Trying to do an incremental switch will just end with a broken system and the loss of a lot of hair.
To find the true capabilities of your cpu, you can use
Code:
cat /proc/cpuinfo
If you see "lm" in between your cpu flags, then your cpu does have support for x86_64.
That output from uname only refers to the arch that the kernel was compiled for, that doesn't necesarily match the capabilities of your physical cpu. i686 refers to pentium pro, II and III, pentium classic and pentium mmx were from the i586 generation.
I can't reinstall it with a new 64bit OS. but I know now what to upgrade with.
Quote:
Originally Posted by lazlow
Trying to do an incremental switch will just end with a broken system and the loss of a lot of hair.
I tend to agree with Lazlow on that.
If you accept his wisdom, maybe you can rethink whether reinstalling is really out of reach.
If you don't accept that Lazlow is correct, I suggest/request you describe your intended approach to doing the upgrade. If you know something we don't, we'll learn something. If you are overlooking something we don't, we might save some of your hair.
I was mostly concerned with what this new admin is doing... he came on board as an expert on linux but he is making errors and making our life harder. I'm not going to lose my hair over his mistakes. I'm going to let him know that he updated the system with 64bit package instead of 32. that's basic stuff right?
But thank you very much for all the support everyone.
I'm going to let him know that he updated the system with 64bit package instead of 32. that's basic stuff right?
After I posted, I suddenly thought maybe I was misinterpreting what you meant by "I know now what to upgrade with". Even so, I didn't think of the actual meaning.
Now that you made the meaning clear (almost the opposite of what I thought you meant) I suddenly can't see why I didn't understand you in the first place.
Anyway, Yum in Centos ought to make it hard to make the mistake your new admin made. Was he updating something that can't be updated via Yum? Or does he not know to use Yum for what can be updated by Yum? Or did he work at overriding the correct behavior of Yum to make it do the wrong thing?
Good luck breaking him in.
Supposedly the people in another office, who have been failing totally to provide any IT support for the office where I work, are trying to hire a new IT person to work here and support this office but report there. I'm not very optimistic about the results. I expect shortly I'll be in worse shape with a new admin than you are. So maybe you should also wish me luck. The Centos guru working for me who actually does the IT is supposed to be doing software engineering. Having him not doing software engineering because he is busy with IT is bad. Having none of us doing software engineering because IT is too messed up by someone who isn't answerable to us could be worse.
I find it really hard to believe someone is able to do that, not because someone can't think of it, but because of johnsfine says above, it's difficult to do so. Installing packages out of your architecture is something that the package manager should not allow to happen, because, well, they will not work.
Are you sure he installed a package compiled for x86_64 on an i686 OS? Do you actually have proofs or is maybe something you heard? Because if it's something you heard you might have misinterpreted it. And I will explain you the why: XFS is a 64 bit filesystem, meaning that it uses that for indirections (offsets) to define the amount of data it can handle and other structures (that might be subject to the OS limits though). So, it's a 64 bit fs regardless of the bitness of the host OS.
So, there are two different things: if he installed xfs, which is a 64 bit fs, on a 32 bit machine, that's completely right and fine, and the problem is elsewhere. If he installed a 64 bit binary rpm of the xfs tools, then that's not fine.
However, I am not sure that even then that could cause a hang up at all. Note that the fs driver in *inside* the kernel, and the kernel is compiled for i686, as uname tells us. So, it should mount and operate without problems. The xfs package contains userland tools that as far as I know are not necessary (strictly speaking) to operate normally. I am not an xfs user so I might have missed something in there.
But for the sound of it, I think that it's just a confusion, and that he did nothing wrong at least in that regard. Something is broken, but I doubt it's what you think it is.
...Yum in Centos ought to make it hard to make the mistake your new admin made. Was he updating something that can't be updated via Yum? Or does he not know to use Yum for what can be updated by Yum? Or did he work at overriding the correct behavior of Yum to make it do the wrong thing?
...
I was watching him work and he downloaded the package manually, compiled and installed it. I always used yum and rarely downloaded rpms... just to be safe. I thought he knew a better way to install xfs...
As long as he can get the system back to where it was, I don't really care as long as things doesn't go down.
Even if he's compiling for some reason (i.e. to get the latest because of some security problem or something) he will still get a 32 bit binary package, unless he is cross-compiling. So, again, I doubt that the bitness is the root of the problem. All you need to run an xfs filesystem is a kernel supporting it and the mount command.
Even if he's compiling for some reason (i.e. to get the latest because of some security problem or something) he will still get a 32 bit binary package, unless he is cross-compiling. So, again, I doubt that the bitness is the root of the problem. All you need to run an xfs filesystem is a kernel supporting it and the mount command.
I don't think you even need the xfs package.
Thank you. I may have missed something while he was poking around. Time will tell the truth.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.