On 2010/09/23 18:11 (GMT+0200) Stan Goodman composed:

grub> kernel /boot/vmlinuz root=/dev/hdb5 noresume splash=verbose 3 [Linux-bzImage, setup=0x3000, size=0x269760] grub>intrd /boot/int<tab>.img intrd /boot/int.img

Error 27: Unrecognized command

So it stalls here.

initrd is a Grub command. intrd is not. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/23 20:20 (GMT+0200) Stan Goodman composed:

But that still seems like the place where things hang. I went through the sequence of grub commands, beginning with root (hd1,5), and through loading the kernel. From there:

grub> initrd /boot/initrd<tab>.img initrd /boot/initrd.img

And it doesn't return to the GRUB promptl

Did you type in ".img"? If so, why? grub> find /boot/initrd.img grub> find /boot/initrd-2.6.34-12.3-desktop grub> find /boot/initrd Try proceeding only with an initrd that Grub found. Alternatively, or after, try: grub> initrd (hd1,5)/boot/initrdTAB to see the initrd(s) that exist on (hd1,5), complete as desired if desired, then grub> boot -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/23 17:04 (GMT-0400) Stan Goodman composed:

On Thursday 23 September 2010 21:44:29 Felix Miata wrote:

...

On 2010/09/23 20:20 (GMT+0200) Stan Goodman composed:

...

...

But that still seems like the place where things hang. I went through the sequence of grub commands, beginning with root (hd1,5), and through loading the kernel. From there:

...

...

grub> initrd /boot/initrd<tab>.img initrd /boot/initrd.img

...

...

And it doesn't return to the GRUB promptl

...

Did you type in ".img"? If so, why?

I typed it in by way of trying to follow your directions in your message received here today at 16:27:29 (10:27 your time if you are on ET). Here is your model:

...

grub> initrd /boot/init<tab>.img Possible files are: initrd.img-2.6.12 initrd.img

I understood from this that we were seeking a file with a name of the form "initrd*.img". Looking at your model just above, that is still what it seems to me to be saying quite clearly. Please correct me if I am misinterpreting.

You're trying as if the _model_ I provided was an exact clone of what you need to do. Since I'm not there looking at your screen I can't and didn't do that. I provided a model intended to function only as a model. Rather than interrupting my own work to find an approximation of an exact initrd filename match for 11.3, I chose a simpler and doable selection of a disk two with / on a single digit partition. If your installations' initrds do not end in .img, then you can't expect adding .img yourself could be in any way useful.

...

grub> find /boot/initrd.img

...

grub> find /boot/initrd-2.6.34-12.3-desktop

...

grub> find /boot/initrd

There is an "initrd" on both disks. Presumably that is the file I need.

Agreed

...

Try proceeding only with an initrd that Grub found.

...

Alternatively, or after, try:

...

grub> initrd (hd1,5)/boot/initrdTAB

...

to see the initrd(s) that exist on (hd1,5), complete as desired if desired, then

...

grub> boot

I repeated the same sequence of commands as before, beginning with grub> root (hd1,5) and loading the kernel. Then, after grub> initrd /boot/initrd

Error 16:Inconsistent filesystem structure

Google seems to think you have a hardware problem, not a SUSE problem: http://www.linuxquestions.org/questions/linux-newbie-8/error-16-inconsistent... Can't you get anything to boot on any HD? http://www.ultimatebootcd.com/ has an iso with many different troubleshooting utilities. Boot it into the one that matches your brand of HD and see if it thinks your HD is OK. Optionally, get the single purpose test utility from the web site of whatever brand your HD is and run that. e.g. http://pcsupport.about.com/od/toolsofthetrade/tp/tophddiag.htm I'm sure that live Fedora you tried before has something similar but generic, but I always use ultimatebootcd when trouble like this arises. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/24 10:59 (GMT+0200) Stan Goodman composed:

BTW, I have tried these experiments on both drives with the same result, so it would not seem that the drives themselves are at fault, and neither of them is really old. The MB, on the other hand, is long in the tooth (Pentium4) and I had been thinking of replacing it with a G41 chipset and E7500 CPU.

My newest CPUs are single core, at least 4 years old. I see no need for newer any time soon. When you get a chance, I'd like to see complete DFSee 'fdisk -r-' output and the Geo portion of 'map -m' output, like the head of http://fm.no-ip.com/Tmp/Dfsee/gx270L01.txt , unwrapped of course. There may be something we're just not thinking of here that that info might bring to light. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 24 September 2010 00:52:57 Felix Miata wrote:

...

On 2010/09/23 17:04 (GMT-0400) Stan Goodman composed:

...

On Thursday 23 September 2010 21:44:29 Felix Miata wrote:

...

On 2010/09/23 20:20 (GMT+0200) Stan Goodman composed:

...

<long snip>

I've not chimed in since you've been getting good help from Felix. Now that it appears you have got past the syntax hurdles, couple other comments to thrown in . . . From the grub menu command shell, try grub> rootnoverify (hd1,5) grub> kernel /boot/vmlinuz root=/dev/sdb6 grub> initrd /boot/initrd Grub can read a file system without mounting. The root command does a mount. Rootnoverify does not attempt mount, it just makes the call based on what it reads from the table. For reasons sometimes impossible to explain, rootnoverify works when root does not. (And yes, this is usually reserved for a file system that grub cannot read, like NTFS, but it also sometimes resolves an issue with a native file system as well or when there is a problem reading the table.) Also try this using (hd0,5) and /dev/sda6. It might also help to see how the 11.3 installer read the boot sequence and how it installed grub: grub> cat (hd1,5)/boot/grub/device.map grub> cat (hd1,5)/etc/grub.conf Compare that with how grub was installed in your previous installation: grub> cat (hd0,5)/etc/grub.conf grub> cat (hd0,5)/boot/grub/device.map Besides the data in those files, this can also be helpful because when grub is used from its shell off the menu, it is relying on bios query and how it reads the table, whereas when grub is run from the installer or in a booted system, it gets its data from the kernel. Typically the result is the same, but that is not guaranteed. It might also help to look at the partition table as linux sees it. Boot the Fedora CD, open a terminal, switch to root, and do: fdisk -l (That's an "l" as in love, not the numeral one.) And while you are there, you can make sure the contents of /boot are as expected: #mount -t <filesystem> /dev/sdb6 /mnt #ls -l /mnt/boot Again, that's the letter "l". Substitute the fileystem you installed, eg., ext3, in place of <filesystem> You should see: vmlinuz -> vmlinuz_2.6. . . . . (your installed kernel filename) initrd -> initrd-2.6. . . . . (your installed initrd filename) The "vmlinuz ->" and "initrd ->" indicates these are symlinks pointing to the actual filenames. It's the symlinks that Felix has been having you use in his suggestions. I doubt it is a problem with your hardware, certainly not the motherboard and unlikely to have a problem with both disks. I would suspect the partition table(s). If I understood correctly, you used a different OS to create the partitions? As a general rule, it is advised to create partitions with the OS which will live on that partition. Is it feasible to reinstall 11.3, creating the extended primary and the logicals with the 11.3 installer? If so, it would also be advisable to enter the boot loader dialog at that step and look at where it is going to install grub, comparing that to where grub was installed on the first disk (per the cat command above). As an aside, there is a grub manual with the error messages, on the web. Unfortunately, some of the explanations are rather difficult to understand without already having some knowledge of grub. Apology in advance if any of this is redundant. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/24 13:26 (GMT-0400) dwgallien composed:

...

If I understood correctly, you used a different OS to create the partitions? As a general rule, it is advised to create partitions with the OS which will live on that partition.

That general rule contradicts the general rule Stan has been given for more than a decade:

Do all partitioning in advance of installation of anything, preferably using a cross-platform partitioning tool, and when subsequent partitioning is called for, always use the same tool or a later version thereof.

That's what I recommend, and what I believe Stan, as a former OS/2 user, usually does. You can learn about the tool we use on http://www.dfsee.com/ . It works identically whether booted to DOS, Windows, Linux, OS/2 or, subject to some limitations, Mac.

Limiting partitioning to a single competent tool all but eliminates the possibility for the conflicts in partition tables that does occasionally occur in the real world, as table entry standards are rather loose. Partitioning in advance with a single tool means familiarity and fewer mistakes, and getting what you want instead of the surprises that unfamiliarity often brings.

http://fm.no-ip.com/Tmp/Dfsee/gx270L01.txt as referred to in my last thread post, and asked him to provide, was made by that same tool, and provides the info from fdisk -l that you asked for, and more.

I agree entirely re partitioning in advance. Re which tool, there is conflicting advice on that. For example, the fdisk and cfdisk man pages advise that "you should always use an OS-specific partition table program." I recall seeing the same admonition in kernel documentation re disk geometry calcuations and table handling. I've seen this to be an issue quite a few times when mixing Windows and Linux (I have no experience with OS/2). Consequenlty for a long while I used Partition Magic, precisely for the reasons you state - that is, until I had it break the table twice. In any event, if you all have a cross-platform tool that you are confident is reliable, then that's what's important. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 24 September 2010 19:26:59 dwgallien wrote:

...

On Friday 24 September 2010 00:52:57 Felix Miata wrote:

...

On 2010/09/23 17:04 (GMT-0400) Stan Goodman composed:

...

On Thursday 23 September 2010 21:44:29 Felix Miata wrote:

...

On 2010/09/23 20:20 (GMT+0200) Stan Goodman composed:

...

<long snip>

I've not chimed in since you've been getting good help from Felix. Now that it appears you have got past the syntax hurdles, couple other comments to thrown in . . .

From the grub menu command shell, try

grub> rootnoverify (hd1,5) grub> kernel /boot/vmlinuz root=/dev/sdb6 grub> initrd /boot/initrd

Grub can read a file system without mounting. The root command does a mount. Rootnoverify does not attempt mount, it just makes the call based on what it reads from the table. For reasons sometimes impossible to explain, rootnoverify works when root does not. (And yes, this is usually reserved for a file system that grub cannot read, like NTFS, but it also sometimes resolves an issue with a native file system as well or when there is a problem reading the table.) Also try this using (hd0,5) and /dev/sda6.

It might also help to see how the 11.3 installer read the boot sequence and how it installed grub:

grub> cat (hd1,5)/boot/grub/device.map

grub> cat (hd1,5)/etc/grub.conf

Compare that with how grub was installed in your previous installation:

grub> cat (hd0,5)/etc/grub.conf

grub> cat (hd0,5)/boot/grub/device.map

Besides the data in those files, this can also be helpful because when grub is used from its shell off the menu, it is relying on bios query and how it reads the table, whereas when grub is run from the installer or in a booted system, it gets its data from the kernel. Typically the result is the same, but that is not guaranteed.

It might also help to look at the partition table as linux sees it. Boot the Fedora CD, open a terminal, switch to root, and do:

fdisk -l

(That's an "l" as in love, not the numeral one.)

And not "I" as in ego.

And while you are there, you can make sure the contents of /boot are as expected:

#mount -t <filesystem> /dev/sdb6 /mnt #ls -l /mnt/boot

Again, that's the letter "l". Substitute the fileystem you installed, eg., ext3, in place of <filesystem>

You should see:

vmlinuz -> vmlinuz_2.6. . . . . (your installed kernel filename) initrd -> initrd-2.6. . . . . (your installed initrd filename)

The "vmlinuz ->" and "initrd ->" indicates these are symlinks pointing to the actual filenames. It's the symlinks that Felix has been having you use in his suggestions.

I doubt it is a problem with your hardware, certainly not the motherboard and unlikely to have a problem with both disks. I would suspect the partition table(s). If I understood correctly, you used a different OS to create the partitions? As a general rule, it is advised to create partitions with the OS which will live on that

Not operating system, but disk- and filesysstem- analysys tool. http://dfsee.com. I have always partitioned with DFSee, and have never encountered difficulty with the results. It's a very handy tool, by the way.

partition. Is it feasible to reinstall 11.3, creating the extended primary and the logicals with the 11.3 installer? If so, it would also be advisable to enter the boot loader dialog at that step and look at where it is going to install grub, comparing that to where grub was installed on the first disk (per the cat command above).

The actual location of GRUB was my initial reason for wanting to have the DFSee output analyzed. I hope I'll have the support response soon, which will tell me a lot. Reinstalling v11.3 was also my idea from the beginning, but I wanted to wait for the analysis first. I certainly hope you are correct about the hardware/software root of the problem.

As an aside, there is a grub manual with the error messages, on the web. Unfortunately, some of the explanations are rather difficult to understand without already having some knowledge of grub.

I did bookmark the GRUB manual as soon as GRUB entered the conversation here, but haven't yet had time to read it.

Apology in advance if any of this is redundant.

Not at all. I feel very fotunate for any advice I get. -- Stan Goodman Qiryat Tiv'on Israel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 28 September 2010 14:55:06 Felix Miata wrote:

On 2010/09/26 20:52 (GMT+0200) Stan Goodman composed:

...

On Friday 24 September 2010 19:26:59 dwgallien wrote:

...

From the grub menu command shell, try

grub> rootnoverify (hd1,5) grub> kernel /boot/vmlinuz root=/dev/sdb6 grub> initrd /boot/initrd

Grub can read a file system without mounting. The root command does a mount. Rootnoverify does not attempt mount, it just makes the call based on what it reads from the table. For reasons sometimes impossible to explain, rootnoverify works when root does not....Also try this using (hd0,5) and /dev/sda6.

I must have missed your reply that this too failed. Or did it?

I guess I got distracted by something else. I should try it though, on both of the HDs. I'll report on what it does. -- Stan Goodman Qiryat Tiv'on Israel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/28 10:30 (GMT+0200) Stan Goodman composed:

Now I have a reply from DFSee, containing the following:

...

...

The GRUB info on that bootsector looks OK to me: +++++++++++++ Bootsector format : GRUB, GRand Unified Bootloader, stage1 code PC style BPB info : not present GRUB stageX @PSN : 0x01293010 Located on : /dev/hda6 /boot/grub PID: 03 StageX segm:addr : 0800:8000 Forcing LBA : Yes Stage1 install by : 3.2 Boot Disk # : 0xff = disknr : 1 StageX install by : 3.2 LoadSegment : 0x0820 = stage 2 code GRUB code version : 0.97 Code size : 0x0000005F = 47.5 KiB GRUB Config file : /boot/grub/menu.lst +++++++++++++

...

...

The GRUB code for disk 2 looks good too: +++++++++++++ Bootsector format : GRUB, GRand Unified Bootloader, stage1 code PC style BPB info : not present GRUB stageX @PSN : 0x02142630 Located on : /dev/hdb6 /boot/grub PID: 09 StageX segm:addr : 0800:8000 Forcing LBA : Yes Stage1 install by : 3.2 Boot Disk # : 0xff = disknr : 2 StageX install by : 3.2 LoadSegment : 0x0820 = stage 2 code GRUB code version : 0.97 Code size : 0x000000C7 = 99.5 KiB GRUB Config file : /boot/grub/menu.lst +++++++++++++

I have to wonder why the size of the little GRUB code on one drive is twice as large as on the other one.

I wanted to compare that output to mine to see if the size matters, but you omitted the actual DFSee command that generated that output and I have no idea what it would be.

That seems to narrow things down to hardware. And seems also to leave me no choice but to replace the MB.

"MB"? Motherboard? If wasn't uncommon of motherboards of the pre-multicore period to be equipped with non-durable capacitors. If this is the case, a self-done repair might be easier, and certainly less expensive, than a replacement. http://en.wikipedia.org/wiki/Capacitor_plague

I only hope that I can salvage the data from the 11.1 installation.

I doubt all has been corrupted, unless it's actually both HDs at fault. To get your data without first spending a lot on a motherboard or system you should be able to put those HDs into an external HD container that connects to your laptop via USB or eSATA, e.g. http://www.newegg.com/Product/Product.aspx?Item=N82E16817173042 if the HDs are SATA or something similar it they are PATA.

For the new replacement sysem, I am seriously considering sticking with v11.1; I don't really care if people call me an old fogy.

After 11.3 was released I upgraded my no longer supported 11.0 main system to 11.2, pending more stability from KMS kernels and their interplay with the still heavily evolving Xorg base and driver systems, which hopefully will become much better before support of 11.2 ends. I don't anticipate that much improvement before 11.1 support ends. Note that hardware support necessary for "new" systems is commonly lacking from older distro releases. 11.1 installation, or at least full hardware support, might be impossible on a new system unless you are a very careful shopper. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Felix: In running: grub> rootnoverify (hd1,5) grub> kernel /boot/vmlinuz root_/dev/sdb6 grub> initrd /boot/initrd I have tried every possible combination of hd(0/1,5) and sd(a/b), and in each case get at the end a response of the form: Linux-initrd@0x37583, 0xa6c156 bytes. About posting the output of fdisk -r, there is an administrative problem. Easy enough to run the command, and I see it running; I find no way to get it onto a removable medium (i.e. USB stick)., because I don't know where it is being written. It doesn't get into the directory I defined, nor into the default RAMdisk. -- Stan Goodman Qiryat Tiv'on Israel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 28 September 2010 20:35:51 Felix Miata wrote:

On 2010/09/28 19:35 (GMT+0200) Stan Goodman composed:

...

In running: grub> rootnoverify (hd1,5) grub> kernel /boot/vmlinuz root_/dev/sdb6 grub> initrd /boot/initrd

I have tried every possible combination of hd(0/1,5) and sd(a/b), and in each case get at the end a response of the form:

Linux-initrd@0x37583, 0xa6c156 bytes.

Yikes! dwgallien's command list was incomplete. He and I know know there was a final command missing, but we both know it unlikely you'd recognize that implied final command. The more complete command set:

grub> rootnoverify (hd1,5) grub> kernel /boot/vmlinuz root_/dev/sdb6 splash=verbose noresume grub> initrd /boot/initrd grub> boot

Actually, I should have caught it myself. This sequence is almost the same as the one with root, which ended with the boot command. The reason I didn't is that I am getting numb. I will try harder to pay attention. To my great surprise, the sequence got me the v11.3 (sic) welcome screen, and then booted into v11.1, after showing me the log. There were two red- flagged failure lines, but they were not on the screen long enough for me to read them. Tomorrow I will find the log and the failure lines, and get back to you.

...

About posting the output of fdisk -r, there is an administrative problem. Easy enough to run the command, and I see it running; I find no way to get it onto a removable medium (i.e. USB stick)., because I don't know where it is being written. It doesn't get into the directory I defined, nor into the default RAMdisk.

Maybe you mean output of 'fdisk -l'? If you have some removable media mounted somewhere you can see where in the output of mount. If that turns out to be something like "/media/STICK", then you'd do 'fdisk -l

...

/media/STICK/filename.txt'.

That was what I did. "STICK" is "M-Systems" everywhere else, but DFSee thinks it's "M-Systems.S". It sees none of the directories on the stick, but it does see one that isn't there. I need some sleep, and it's late. More tomorrow. When I attack this tomorrow, I will use the DFSee Linux version that I hope I will still have access to, rather than the DOS version on the bootable CD. Unbelievably, I think we are seeing daylight, thanks to you both. -- Stan Goodman Qiryat Tiv'on Israel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 28 September 2010 22:51:43 Felix Miata wrote:

On 2010/09/28 22:07 (GMT+0200) Stan Goodman composed:

...

To my great surprise, the sequence got me the v11.3 (sic) welcome screen, and then booted into v11.1...

More tomorrow. When I attack this tomorrow, I will use the DFSee Linux version that I hope I will still have access to, rather than the DOS version on the bootable CD.

Pay attention to where DFSee lists Grub as filesystem instead of Linux in the Related column. My guess is that the 11.3 installer put things where it thought they belonged instead of where you needed/wanted them, only partially overwriting your 11.1 "Grub" with 11.3 Grub, leading to the whole mess you've been trying to extricate yourself from with this thread.

No, the root partitions are both marked for GRUB. I assume, BTW, that the fact that I get to the GRUBs indicates that the MBR is intact.

The 11.3 filesystems might be unreadable by 11.1's Grub, either due to 256 byte inodes, or use of EXT4 filesystem(s).

I only mentioned to Jan today that the partial 11.3 install was formatted with ext4; if he is aware of a problem with that, he may say something tomorrow. But it really doesn't matter much. The new install didn't even finish, so it has to be started over from scratch, and nothing is lost. I am not committed to ext4, and can format with ext3 if there is a reason to do so.

Booted to 11.1 you can reinstall its Grub, getting you back normal 11.1 operation. Once that's done we can figure out what can be done about 11.3 besides abandoning or reinstalling it.

As I say, there is no option, and I will install over it. Jan mentioned, by the way, that he believes recent Linux installers are problematic when there are multiple OSes on the system. Whether that is true or not, I intend to remove the 11.1 HD from the system when I install 11.3 (0r simply remove the Bootable flag from it), and after getting data and Java programs transferred from it to the new install, remove power from the 11.1 HD. Historically, after a new OS is installed, I never look at the older one, and there is no reason to spin its HD. -- Stan Goodman Qiryat Tiv'on Israel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/28 22:07 (GMT+0200) Stan Goodman composed:

...

To my great surprise, the sequence got me the v11.3 (sic) welcome screen, and then booted into v11.1 ...

So rootnoverify works then . . . ? The problem does not appear to be with the grub code or files. You have been able to get to the grub shell to manually run commands from there - that shell *is* a part of /boot/grub/stage2. That is, you are already running stage2. Your DFSee analysis appears to indicate it found grub stage1/1.5 in the partition boot sector (note, not the file system). Stage1 is simply a strap with a pointer to find stage2; stage1.5 is an appended piece of code which enables stage1 to read the file system to find stage2. Since you were able to get to stage2, this indicates that your IBM boot manager has a strap in the MBR which is calling its code in the primary partition which in turn is finding the partition boot sector where grub stage1 is located and transferring control to it (this is called "chainloading" and is exactly how the Vista/W7 boot manager works, too). So . . . That rootnoverify worked indicates some problem with reading the file system. This conceivably could be related to ext4, but it could also be an issue with the 1.5 code, or something more obscure. The simple solution may just be to modify /boot/grub/menu.lst to use rootnoverify. But it is also possible that there is a second problem with the syntax in menu.lst. To check this, you need to edit menu.lst so as to use the exact same syntax as you used from the shell. You can do this from a live-CD, mounting the partition, editing the file, unmounting, rebooting w/o CD; when doing this you can also verify exactly how stage1/1.5 was installed by viewing /etc/grub.conf. Alternatively, you can reinstall, except at the boot loader step, enter the dialog which will take you to a new series of screens; there you can verify/control exactly how grub will be installed/configured, including manually editing menu.lst. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/10/05 13:10 (GMT+0200) Stan Goodman composed:

ftp://hashkedim.com/pub/

ftp://hashkedim.com/pub/device.map-11_1 says 11.1's grub found a Hitachi 250G HD as 2nd HD, and an older IBM or Hitachi HD as 1st HD. ftp://hashkedim.com/pub/menu.lst-11_1 confirms 11.1's root was on 6th partition on 2nd HD, while telling that 10.3 was on 6th partition on the 1st HD. ftp://hashkedim.com/pub/device.map-11_3 says 11.3's grub found a Seagate 250G HD as 1st HD, and the same Hitachi 250G HD as 2nd that 11.1 found. ftp://hashkedim.com/pub/menu.lst-11_3 confirms 11.3's root was on 6th partition on 1st HD, while telling that 11.1 was on the 6th partition on the 2nd HD. ftp://hashkedim.com/pub/fdisk tells us that both disks are same size and have identical Linux partition layout, but show that partition table entries on both disks are in a different order, plus the HD fdisk says is sdb has a FAT32 partition following IBM Boot Manager and the Linux partitions. ftp://hashkedim.com/pub/DFSWORK.LOG shows us the the two HDs are currently presented by the BIOS in reverse logical order of what they were at the time their SUSEs were installed, with 11.1 living on the 1st HD and 11.3 living on the 2nd HD. It's no wonder booting from the existing menu.lsts is not possible, but proper Grub prompt commands succeed in starting SUSE boot. It _looks_ like all that would have been required to fix the problem would have been to swap cables between the two SATA disks, but also swapping the HD order in the BIOS might accomplish the same thing as a cable swap, and could be the reason leading to this thread's OP. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/10/08 10:43 (GMT+0200) Stan Goodman composed:

Felix Miata wrote:

...

ftp://hashkedim.com/pub/device.map-11_1 says 11.1's grub found a Hitachi 250G HD as 2nd HD, and an older IBM or Hitachi HD as 1st HD.

Which is wrong; one of the HDs is a Seagate. This is an old GRUB. The phantom HD was a Hitachi.

I wrote "Found" on purpose, speaking of the state of affairs when 11.1 was installed. I purposely didn't say or imply is now. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/10/08 05:39 (GMT-0400) Stan Goodman composed:

Felix Miata wrote:

...

It's no wonder booting from the existing menu.lsts is not possible, but proper Grub prompt commands succeed in starting SUSE boot. It _looks_ like all that would have been required to fix the problem would have been to swap cables between the two SATA disks, but also swapping the HD order in the BIOS might accomplish the same thing as a cable swap, and could be the reason leading to this thread's OP.

I chose to switch the HD cables. The result is that booting hangs exactly as before, but sda6 and sdb6 are now exchanged.

If I had thought harder I would have suggested the BIOS be tried first. I don't remember any previous mention of cable swapping, but then again the older Hitachi did get changed out for a Seagate. Some BIOS can be rather unintuitive regarding boot order. When the old Hitachi was removed, before there was any partitioning or formatting on the new Seagate, the BIOS itself could have moved the formerly #2 Hitachi into the #1 logical position. Long term, a correct fix to 11.1 probably requires /boot/grub/device.map be rewritten to remove the reference to the no longer used Hitachi. To do it now manually, you can change that line to read either '(hd0) /dev/sda' or '(hd0) /dev/disk/by-id/ata-ST3250318AS_6VY56XND'. Try putting the cables the way they were, and swap the two in the BIOS boot order. But first before you do that, try booting without the cable connected to the Hitachi. DFSee provides clues. One is that the order it presents the disks is in BIOS order. As long as the two disks are shown as swapped from the order seen by the SUSE installation programs, you cannot expect either menu.lst to work unless you change each 0 to 1 and each 1 to 0 where you now see (hd0,5) & (hd1,5), and do the same for each /etc/grub.conf before any new kernel update. Also as long as the logical swap remains in place, attempts to reinstall Grub will probably be fruitless, unless menu.lst, device.map and grub.conf are conformed to the swapped order. To make the series of boots easier between now and whenever the ultimate solution has been implemented, try pasting the following into each menu.lst as an additional entry: title generic openSUSE on disk 1 rootnoverify (hd0,5) kernel /boot/vmlinuz showopts root=/dev/sda6 noresume splash=verbose vga=0x31a 3 initrd /boot/initrd title generic openSUSE on disk 2 rootnoverify (hd1,5) kernel /boot/vmlinuz showopts root=/dev/sdb6 noresume splash=verbose vga=0x317 3 initrd /boot/initrd 'showopts' ahead of root= on kernel line will enable you to edit all relevant portions of the kernel line if desired or required via the Grub gfxmenu, and save having to do all that typing in a grub shell to get booted. Before any kernel or initrd updates, you should goto /etc/zypp/zypp.conf and uncomment the multiversion line, and also goto /boot and cp the current initrd to a new name, such as initrd-2.6.34-12-desktop-orig, so it could be used for more troubleshooting if necessary. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/28 10:30 (GMT+0200) Stan Goodman composed:

...

...

...

GRUB code version : 0.97 Code size : 0x0000005F = 47.5 GRUB code version : 0.97 Code size : 0x000000C7 = 99.5

...

I have to wonder why the size of the little GRUB code on one drive is twice as large as on the other one.

I wonder too, but I'm guessing it's more data than "code". Here are those from this system: GRUB code version : 0.97 Code size : 0x00000017 = 11.5 KiB GRUB code version : 0.97 Code size : 0x00000015 = 10.5 KiB GRUB code version : 0.95 Code size : 0x00000017 = 11.5 KiB GRUB code version : 0.97 Code size : 0x0000002F = 23.5 KiB GRUB code version : 0.95 Code size : 0x00000017 = 11.5 KiB GRUB code version : 0.95 Code size : 0x0000005F = 47.5 KiB GRUB code version : 0.97 Code size : 0x0000002F = 23.5 KiB

Version .97 has been used since '05, although of course its been patched since. Currently 99.5 KB. See my last post: You are definitely running the /boot/grub/stage2 shell; that's where you have been entering the commands. In your boot manager, do you have entries to boot both disks? If you can get to the grub shell from both and successfully enter the commands, you have no problem with the stage2 code. If you have a problem with the sda stage2 but not sdb's, you can check/copy sda's by looking at /usr/lib/grub/stage2 - that is the file that gets installed, /boot/grub/stage2 is a copy of it. Or reinstall. Again, ref my last post. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/24 00:58 (GMT-0400) Mike McMullin composed:

On Thu, 2010-09-23 at 20:20 +0200, Stan Goodman wrote:

...

grub> initrd /boot/initrd<tab>.img initrd /boot/initrd.img

...

And it doesn't return to the GRUB promptl

Just an observation Stan, there really is no need for a <tab> in vmlin<tab>uz, all one word shoud suffice, and as for initrd<tab>.img, that can be fixed to initrd.img. A bit odd those <tab>s.

If you look further upthread you might detect that the object of the <tab>s was educational/efficiency exercise. It's silly to type more than a few characters when the shell will do it for you, and without making typos. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 2010-09-24 at 15:03 +0200, Stan Goodman wrote:

On Friday 24 September 2010 06:58:57 Mike McMullin wrote:

...

On Thu, 2010-09-23 at 20:20 +0200, Stan Goodman wrote:

...

On Thursday 23 September 2010 18:35:02 Felix Miata wrote:

...

On 2010/09/23 18:11 (GMT+0200) Stan Goodman composed:

...

grub> kernel /boot/vmlinuz root=/dev/hdb5 noresume splash=verbose 3 [Linux-bzImage, setup=0x3000, size=0x269760] grub>intrd /boot/int<tab>.img intrd /boot/int.img

Error 27: Unrecognized command

So it stalls here.

initrd is a Grub command. intrd is not.

Sorry.

But that still seems like the place where things hang. I went through the sequence of grub commands, beginning with root (hd1,5), and through loading the kernel. From there:

grub> initrd /boot/initrd<tab>.img initrd /boot/initrd.img

And it doesn't return to the GRUB promptl

Just an observation Stan, there really is no need for a <tab> in vmlin<tab>uz, all one word shoud suffice, and as for initrd<tab>.img, that can be fixed to initrd.img. A bit odd those <tab>s.

By now, I know that you are right. But at the time, my level of insight was so low that the only possible strategy was to follow directions as closely as possible according to my understanding.

Since, by the way, the absence of the "uz" could not have produced a different result, it's clear that the real reason for the difference must have been copying/typing error. There were, in fact, many such errors, most (but not quite all) of which I caught. That was tedious work.

It usually is, fortunately oS has kept grub 1, grub2 seems to be more fun than most folks want to have, the learning curve is much steeper than for grub 1. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/09/25 20:43 (GMT+0200) Carlos E. R. composed:

Stan Goodman wrote:

...

...

grub> kernel /boot/vmli<tab>

...

That got only the usual action of the Tab key, it didn't try to autocomplete anything.

There is an old Bugzilla for that.

Tab completion works fine if you don't forget either to issue a valid root command first, or use the 'kernel (hdx,y)/vml<tab>' syntax instead. Note that the Grub shell works post-boot, not just for booting, so you can test commands and syntax (e.g. for educational purposes) any time you're booted, and just need to avoid the boot command after issuing valid pre-boot commands if you want to maintain your current boot. ;-) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-09-26 at 16:34 +0200, Stan Goodman wrote:

...

There is an old Bugzilla for that.

When Bugzillas get old enough, do they ferment and turn into something usefull?

Nope. They wait till the distro version they were reported for gets out of maintenance, then close the bugzilla as "wontfix" because the version is no longer maintained - without even doing any work on the bug. It is the reporter who then goes fermenting! >:-| - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkyfXkEACgkQtTMYHG2NR9V9DACgiK92P0XG/6XgMwtGVyPQdYOS dpoAoIGcFF/aYIswKj1dxPetEVZjvgOO =5BkP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org