Installation boot error question

I receive the following when booting the gnome live 11.1 CD.

Data Prog
34 9ef1b 4 5 9b2a.65
35 9ef2a 4 6 9ebe0.a
36 9ef39 4 7 3.1
37 9ef48 4 8 1.1
38 9ef57 4 9 9b10.55
39 9ef66 4 a 9b27.15
3a 9ef75 4 b 9b1e.5
3b 9ef84 4 c 8623.5

err e
ip 8571: 4.7
>>zu_ZA<<

I have no idea what this means … needless to say it wont boot. In fact, I have never succeeded in booting opensuse on this - shuttle. I have had everything else on it, but not opensuse.

The company I work for has always wanted to use opensuse but has had problems similar to this.

Before we permanently kick opensuse to the curb, does anyone have any ideas?

Thanks
Jim

Did the md5sum verification on the iso? Did the media-check verification on the burn?

Where precisely are you seeing the above errors?

I’m sure the media is fine. We have tried installing opensuse dating back to 9.x - on this hardware and a class of SMP Xeon server.

The message appears on the screen that contains the boot parameters entry (at the bottom of a list) and several boot options. (In the upper left corner - it resembles a curses subwindow. Black bordered box over the Suse green.)

The last time we made this attempt and failed, I posted to try and find a solution. We ended up committing to Centos. The owner of the company is Hungarian and would prefer opensuse.

P.S.
The table was collapsed - I added spacing here

Data … … … Prog
34 … 9ef1b 4 … 5 … 9b2a.65
35 … 9ef2a 4 … 6 … 9ebe0.a
36 … 9ef39 4 … 7 … 3.1
37 … 9ef48 4 … 8 … 1.1
38 … 9ef57 4 … 9 … 9b10.55
39 … 9ef66 4 … a … 9b27.15
3a … 9ef75 4 … b … 9b1e.5
3b … 9ef84 4 … c … 8623.5

err e
ip 8571: … … … 4.7
>>zu_ZA<<

What happens if you hit the Escape screen to drop the graphic splash?

I assume you have tried this using a different monitor?

Mingus, thanks for the replys.

Here is what I have found.

If I have video hole (memory) at 15m-16m enabled in the bios, then suse fails. This is a default setting on this XPC Shuttle. I am certain it is a default setting on other systems as well.

I suspect the table listed above is in fact the output from a kernel debugger. That means it is serious.

I currently have Fedora running on that very iron and have tested Ubuntu 8 as well.

Finally, had we received any support years ago, we would have chosen opensuse instead of centos for our customers then. But the slightest hint of instability disqualifies any distro from production use.

I am pleased that I found the issue even if I havent found the precise cause. I will note that this means that opensuse has ‘failed code’ embedded in it unattended. (I say that as a loooooong time professional programmer).

… and thanks again Mingus. :slight_smile:

Jim

Well, from a looooooong time systems engineer :wink: . . .

Good catch. And close, but no cigar. You actually did find the cause, but your conclusions are not correct.

First, just for clarification, note that the program that is choking is linuxrc, not the kernel - the kernel has not been called at all when you see the initial screen. Linuxrc is “a small program that runs before the actual installation program YaST is started. It is responsible for the hardware setup and will search for an installation repository.” It sets up the environment by doing the initial hardware probe via the bios map, accepts kernel arguments and supplemental modules to then pass to the kernel and initrd. You can also do a lot to change the behavior of the downstream installation program via passing parameters.

The issue is, as you found, the memory hole setting in the bios. While the setting is in your Shuttle bios, it is legacy and very likely useless (unless the machine is fairly old). It is for reserving a small slice of memory exclusively for use with an ISA card. Even when used, it is was optional, not needed if there was sufficient total system ram. So far from this being enabled by default on most other systems, the setting is typically not present at all because ISA support was dropped from mobo’s years ago.

Several useful quotes, two specifically ref Shuttle bios’s:

Memory Hole at 15M~16M - Reserves space in memory between 15MB and 16MB for ISA card ROM. Can speed things up if enabled, but will also place a maximum 16MB limit of usable memory in DOS.

In order to improve performance, certain space in memory can be reserved for ISA cards. This memory must be mapped into the memory space below 16 MB.

Memory Hole or Memory Hole At 15 MB Add: Creates a memory hole between 15M and 16M in order to have the PC compatible with some old ISA video boards using this memory area. As this options results in a loss of 1 MB of memory, we suggest you keep it disabled.

Bottom line, just disable it.

By the way, this should not to be confused with “memory hole remapping” in some bios’s (the terminology is not consistent) which involves remapping the memory reserved for PCI devices. With PCI-Express in particular which uses more memory, this sometimes creates a problem on a 32-bit machine because of its addressable ram limitation. So this option permits that memory allocation to be mapped to another location (albeit it at ~50MB loss).

I stand by my post. ubuntu and fedora arent ‘crashed’ by the memory hole setting.

I am aware of the history of the isa bus.

The table posted was a dump - of whatever is running at that point.

And just because I dont appreciate sarcasm …

I started in 1966 on Univacs at the age of 14.
I progressed to IBM 360’s
Next were Dec 10’s
Then PDP-11’s running RSTSe and TSX
Then PDP-11’s running BSD 6
Then Vax’s (VMS)
Then 8080 class micros running cpm.
Then Apple II’s (never programmed a Mac)
Then msdos on IBM pc’s
Then 8086’s and cpm86 and mpm
Then a number of off brand systems including symbolics
About here an DG eclipse
Then motorola unix boxes
Then national semiconductor unix boxes
Then motorola 88000 unix boxes
Then IBM aix boxes

… in '79 I even got into a pissing match over the phone with Bill Gates.

… and I’m sure I have missed some.

I have used most languages.
I have designed hardware (statmuxes)
I have written OS’s for above

I am going to skip a large block of time in which I was involved in creating manufacturing software for a company that went public. (bad experience)

and currently (last decade) have designed and implemented hotel property management systems which include interfaces to everything from security systems (locks throughout the property), PBX systems, video rental systems, credit card processing (certified), Bestwestern CRS, Expedia, Booking.com, Genares (most of these are XML over either HTTPS or direct SSL - using openssl and/or curl and my own hand writting recursive decent XML parser) as well as managing the entire property and its reservations and interfacing to a proprietary web system (cgi based) that allows the customer to manage their own reservations in realtime … and more.

… I really meant long.

… and the suse group is foolish to allow this bios oversight to harm its install base. (which it has done in our case - dozens of hotels and hundreds of workstations that are currently running an OS other than suse because we didnt trust it).

My interest in OS chic ended about 30 years ago. They are tools and honestly I dont have time to treat them as a hobby. (Personally I prefer BSD - which cant be used for other reasons)

Thanks again for your help (?)
Jim

Good grief. I’m afraid you misunderstood - I meant no sarcasm at all. After all, it was you that wrote you had been a programmer for so loooooong. All I did was make a friendly in-kind response - I’ve been in this game a loooooong time, too. I meant no offense.

I’m an old salt, too. I also can name lots of machines, OS’s, apps, ad nauseum. I’ve personally met Gates (though thankfully he was arguing with someone else). I even had several sessions with Steve Jobs. Jeez, Steve and Bill deserve one another. Heck, I’ve even worked on much of the same kinds of software as you have. You “really meant long”? - well, I believe you. Actually, I been in this game for even a few years longer than you have. (Work in the Valley, by chance?) Maybe someday if we’re lucky we can scrawl dirty-old-man messages in assembler on the nursing home wall just to terrorize Nurse Ratchet.

So whaddya say, let’s drop the dueling credentials at ten paces and focus on the problem instead?

First, if I may say so, I’m not clear why you’re not taking the issue to Novell; your requirements are enterprise-scale. Apparently your client wants to use free software without support? That’s certainly the client’s prerogative, but here at openSUSE you are just reaching knowledgeable users, not the engineers.

You could file an openSUSE bugzilla report, but frankly I doubt you’d gain much traction. I’ve worked these forums a good while, and I’ve only see what you’ve described once or twice at the most. AFAIK, this is a real corner case. It’s not going to be viewed as harming an installed base. It’s not that I dispute that linuxrc shouldn’t choke (on what I’m guessing is a quirk in reading the bios map), but chances are that if Novell knew there were real revenues or real commercial customers at stake, the problem would receive entirely different attention. So imho, Novell is where to look.

I also confess that I don’t quite understand why disabling the ISA memory hole is not an option. There’s no harm in doing so, is there? If there were a problem in the kernel or critical mainline, of course that’s a different matter altogether. But this is just an installation setup program; there are a half-dozen other supported methods. And with a large number of machines, I would think you would use an enterprise-class process for installs and upgrades - so you might not see linuxrc at all. (It’s also conceivable that there may be a linuxrc argument that would work around the issue, but I’d have to look further into that to be sure.)

Finally, of course the reason you haven’t seen this in other distros is because the problem is in an openSUSE unique front-end program. I wished that weren’t so. If that’s not resolvable or can’t be worked around, well, I’m glad you found good alternatives.

Good luck and be well.

Good grief. I’m afraid you misunderstood - I meant no sarcasm at all. After all, it was you that wrote you had been a programmer for so loooooong. All I did was make a friendly in-kind response - I’ve been in this game a loooooong time, too. I meant no offense.

I’m an old salt, too. I also can name lots of machines, OS’s, apps, ad nauseum. I’ve personally met Gates (though thankfully he was arguing with someone else). I even had several sessions with Steve Jobs. Jeez, Steve and Bill deserve one another. Heck, I’ve even worked on much of the same kinds of software as you have. You “really meant long”? - well, I believe you. Actually, I been in this game for even a few years longer than you have. (Work in the Valley, by chance?) Maybe someday if we’re lucky we can scrawl dirty-old-man messages in assembler on the nursing home wall just to terrorize Nurse Ratchet.

So whaddya say, let’s drop the dueling credentials at ten paces and focus on the problem instead?

First, if I may say so, I’m not clear why you’re not taking the issue to Novell; your requirements are enterprise-scale. Apparently your client wants to use free software without support? That’s certainly the client’s prerogative, but here at openSUSE you are just reaching knowledgeable users, not the engineers.

You could file an openSUSE bugzilla report, but frankly I doubt you’d gain much traction. I’ve worked these forums a good while, and I’ve only seen what you’ve described once or twice at the most. AFAIK, this is a real corner case. It’s not going to be viewed as harming an installed base. It’s not that I dispute that linuxrc shouldn’t choke (on what I’m guessing is a quirk in reading the bios map), but chances are that if Novell knew there were real revenues or real commercial customers at stake, the problem would receive entirely different attention. So imho, Novell is where to look.

I also confess that I don’t quite understand why disabling the ISA memory hole is not an option. There’s no harm in doing so, is there? If there were a problem in the kernel or critical mainline, of course that’s a different matter altogether. But this is just an installation setup program; there are a half-dozen other supported methods. And with a large number of machines, I would think you would use an enterprise-class process for installs and upgrades - so you might not see linuxrc at all. (It’s also conceivable that there may be a linuxrc argument that would work around the issue, but I’d have to look further into that to be sure.)

Finally, of course the reason you haven’t seen this in other distros is because the problem is in an openSUSE unique front-end program not used elsewhere. I wished that weren’t so - I’ve used this distro for years now and find it one of the very best all-around. But if the issue is not resolvable or can’t be worked around, I’m glad at least that you have found good alternatives.

Good luck and be well.

Jim, I just send you a pm. For future reader’s ref, please see this bugzilla report: https://bugzilla.novell.com/show_bug.cgi?id=211094.