Just got my Lenovo TS130 with a Xeon E3-1225 Processor, 4GB RAM, blah, blah, blah...... It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot 32 bit CentOS 6.0. Any ideas? Otherwise, its going back to Amazon Monday and I'm done. Will keep my 5.7 Centos boxes until they rot! TIA
On 09/16/2011 09:52 PM, Thomas Dukes wrote:> Just got my Lenovo TS130 with a Xeon E3-1225 Processor, 4GB RAM, blah, blah, > blah...... > > It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot > 32 bit CentOS 6.0. > > Any ideas? Otherwise, its going back to Amazon Monday and I'm done. Will > keep my 5.7 Centos boxes until they rot! > > TIAIs Red Hat Enterprise Linux listed as a supported operating system? If so, download the trial version and see if you have the same problem. If/when you do, call Lenovo and open a support ticket. -- Digimer E-Mail: digimer at alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "At what point did we forget that the Space Shuttle was, essentially, a program that strapped human beings to an explosion and tried to stab through the sky with fire and math?"
On Fri, 2011-09-16 at 21:52 -0400, Thomas Dukes wrote:> Just got my Lenovo TS130 with a Xeon E3-1225 Processor, 4GB RAM, blah, blah, > blah...... > > It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot > 32 bit CentOS 6.0. > > Any ideas? Otherwise, its going back to Amazon Monday and I'm done. Will > keep my 5.7 Centos boxes until they rot!---- Xeon processor? sounds old - might not run 64 bit. If you boot the 32 bit, what do you get for processor when you run dmidecode? (note - there's quite a bit of data there - only want the process info. Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Hi, On 09/17/2011 02:52 AM, Thomas Dukes wrote:> It won't boot CentOS 6.0 64 bit, Scientific Linux 64 bit 6.1, but will boot > 32 bit CentOS 6.0.Can you expand a bit on the 'wont boot', actually expand quite a lot. Run the installer in debug mode and turn off all rhgb, quiet etc and see what point and how far the system gets. Also, some manufacturers have been known to turn off 64 bit ( lm ) support in BIOS when the device is sold with a 32bit Windows. Make sure that its not the case. Finally, you mentioned 5.7 but didnt say what your test results there were. Does the 5.7/x86_64 installer boot for you ? if not, how far does it get ? is that about the same point as the 6.0 installer ? - KB
<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>As the OP, I will say this. I blew out my CentOS 6.0 installation having installed SL kernel and firmware packages. I thought I would install SL 6.1 to see how it would be since it was a new install with no real value as far as customizations. It wouldn't run after the installation, boot up and crap out. And no, I didn't burn the DVDs on the bad DVD burner.</div><div><br></div><div>My thinking was how could the SL people be better than the CentOS people. They aren't for reasons unbeknown to me.</div><div><br></div><div>While I'm in the process of changing ISPs, I'm stuck hotspotting my (home) internet through my iPhone. Hopefully, I will be back by the weekend.</div><div><br></div><div>I will be sticking with CentOS with a few mods from SL. I don't know, but I would wager RH is having 6.1 problems.</div><div><br></div><div>Thanks for ALL you do!!</div><div><br></div><div>Eddie<br></div></span></body></html>
On Friday, September 23, 2011 12:57:31 PM Johnny Hughes wrote:> There is a whole channel of RPMs that we are not allowed to look at from > upstream now. They do not release them on any ISOs and we can't pull > things directly off RHN (the only way to get the optional channel) and > use it. This is just one of many issues we are having right now.Just for clarification, this is to check binary compatibility, correct? The source RPM's are in the regular location on the ftp.redhat.com site, at least the few I looked at in the optional channel are. I think many here simply do not understand the degree of meticulousness required to check binary compatibility at the level the CentOS team has historically checked binary compatibility. To the best of my knowledge, checking binary compatibility requires having a copy of the target binary package from a subscribed system (ideally, you'd likely want to do the checking, or generating a compatability 'signature' of some sort, on a subscribed system to prevent running afoul of the subscription terms of service). To do this for all channels requires multiple licensed and subscribed systems, as far as I can tell from looking at the set of packages I see from my duly subscribed RHEL 6.1 box (duly as in I have paid for the subscription). But I reserve the right to be wrong. RHEL 6.1 also made significant anaconda installer improvements; to do a full-up 6.1 requires dealing with that, too. The current setup upstream that I can see appears to have made things drastically more difficult, at least from my point of view. And the intended targets weren't CentOS and SL; rather, other commercial competitors providing their own support were the intended targets, IMHO. While I have asked myself this question (and I think I have it answered privately to my own satisfaction), I really don't think it's appropriate in this list to ask 'well, why has SL been able to release a 6.1 if it is so hard?' since the two projects are different and have different goals, different infrastructure (particularly on the build side), and different teams; no, I'm not going to share my own private answer with anyone, don't even ask. Suffice to say that I will have some SL boxes, and I'll continue to have some CentOS boxes, and I have an RHEL box in my most critical point, and will use each distribution in the role(s) it is most suited to as appropriate to the resources available to support those roles.
On Friday, September 23, 2011 01:29:51 PM Dennis Jacobfeuerborn wrote:> What you are suggesting here is that people should expect centos systems to > be insecure and go the RHEL if they want secure systems.If the timeliness of security updates is essential/critical you cannt get faster updates than with the upstream paid subscription; it is impossible for a rebuild to release the update before it's posted. So, yeah, if getting the fix the quickest is mission-critical then a subscription to upstream should be purchased. If you can't afford or don't want to pay for a subscription, then you have two options: 1.) Build and test it yourself; 2.) Wait on someone else to build it and test it, where 'someone else' can be an individual or one of the rebuild projects, of which CentOS has the largest distribution with SL next largest. If you can't wait and can't build it and can't pay for a subscription, then you have two options: 1.) Get your server off the net immediately; 2.) Be insecure until you get the update.> Have you pondered the moral implications of your statement? Does that mean > that the centos project is perfectly fine with knowingly distributing a > system that insecure and a danger not only to its users but to others as well?All systems are insecure. Updates are for the known holes; there are and always will be unknown holes. Have you pondered the moral implications of knowlingly installing insecure software and placing it on the public internet? Oh, wait, it's not a moral issue, since there is no such thing as secure software.> Drop whatever 6.x related things you are > doing, build the package, put it online, make an announcement and then get > back to the regular schedule.You are missing some highly important steps. Let me summarize: 1.) Get source RPM(s) for the update from upstream. Upstream's source RPM's for the updates have been known to be delayed, sometimes for quite a while; 2.) Build; 3.) Verify binary compatibility (that is, does it have identical binary dependencies on identical versions of dependencies, verifying that it was built in an identical buildroot as upstream?) (you do realize that a given source RPM can be built to generate very different and potentially incompatible binary RPMs depending upon the contents of the buildroot, right?); 4.) QA the package to make sure other people with various systems can install and use the package, and that it really does fix the problem; 5.) Make sure the resulting repository is 'closed' (that is, in a consistent state so people updating don't get nasty surprises); 6.) Seed the mirror system. A large package update set can take a significant amount of time to propagate; 7.) Announce, and wait on the inevitable bug reports and complaints that it broke users' systems. Sounds like fun, no?
On Friday, September 23, 2011 02:35:40 PM Craig White wrote:> I moved to Ubuntu on my own server, some of my customers servers as has my employer.This is not a Ubuntu list. I have had my share of problems with more than one of the LTS Ubuntu distributions, more than I have had with CentOS. Dist-upgrade has broken more things, in my experience with several versions, than I care to detail.
On Friday, September 23, 2011 03:17:07 PM Dennis Jacobfeuerborn wrote:> On 09/23/2011 07:57 PM, Lamar Owen wrote: > > Have you pondered the moral implications of knowlingly installing insecure software and placing it on the public internet? Oh, wait, it's not a moral issue, since there is no such thing as secure software. > > It is a moral issue if you know that you cannot provide timely updates.You cannot know how long an update will take until the update is done, thanks to the iterative process of insuring binary compatability.> "Fun" doesn't enter into it. Apparently there existed an updated httpd > package on Sept. 1st that was ready to go and yet here we are three weeks > later with no release but more importantly no timely message that it will > in fact not be released as planned.I don't think you understand. The process is iterative; if QA fails it's all the way back up to building it again. A package may have existed three weeks ago in terms of being built; if that package had passed binary testing and QA it would have been released by now. As to 'fun' entering into it, you also realize these guys are volunteers, right? Make a volunteer's life too hard, and that volunteer stops volunteering. These volunteers *owe* the users of CentOS *nothing*. I'm just glad they've done what they've done.> Again if it's not possible for the project to keep up with the updates then > this should be openly communicated so users can ponder alternatives.I disagree. The project has no obligation to communicate *anything* to me; I'll watch the announcements, and when it's announced, I'll get it. I cannot expect any more than that from any volunteer project. If the project chooses to communicate that's great and fine, but I cannot expect it when I am not entitled to it by some means. Sure, that's inconvenient to users of the project's distribution; but users of any free, volunteer-run project need to understand what they're getting themselves into before they install it. Perhaps the project should more adequately communicate during installation that timely updates, bug-free opeeration, and security fixes are not guaranteed, and require the user to agree to that before installation proceeds. The CentOS project has done a fantastic job over the years, and it's easy to get spoiled to being a freeloader. But updates don't build and QA themselves.> And if it's not possible to release specific high profile/impact updates in > a timely fashion for some reason then users should be informed too so they > can deal with the situation in other ways.Again, it is impossible to know how long a package release will take when you start, or even when you've built it for the twentieth time. Full 100% binary compatibility may mean packages have to be built in a particular order, and it may mean a set of updates has to be built together in order to pass binary compatibility. Once it has passed the binary check it still has to be QA'd, and if it fails you are at square one in ways, building again in a slightly different way to a slightly different buildroot, correcting what QA found. And the fix for one QA issue could easily cause another. A package as important as httpd must pass muster. A broken update is worse than no update at all.> Yes, QA'ing and releasing a package may be time consuming but sending out > an email is not and would do a great deal to at least aid users in their > decision making.Karanbir sent out an e-mail with his best estimate of the time; the estimate was incorrect, but due to the nature of the beast it is impossible to know how long it really will take. Perhaps the QA process could be more open; perhaps it should be. Perhaps it shouldn't be, too. I'm not in a position to judge that. Rosman, NC 28772 http://www.pari.edu
On Saturday, September 24, 2011 06:34:15 AM Christopher Chan wrote:> Ah...you're supposed to use do-release-upgrade and not 'apt dist-upgrade'If that is what is called by the gui distribution upgrade button, it has done similar things to a few installs I have had to repair.> Ubuntu ain't Debian. It's something worse and requires uber hacks to get > around crap. Them uber hacks are loaded in do-release-upgrade.Been there, broke that.> Pound Ubuntu properly pal. Giving examples of unsupported processes > ain't pounding it properly.TMTOWTDI. If it's not supported it shouldn't be enabled and easily (ab)used. This is part of the reason you have to add a boot argument to get CentOS to do a version upgrade; it's known to not work properly, and thus is semi-hidden.