Re: [opensuse] BIOS/GRUB Problem
On 2010/10/28 14:58 (GMT+0200) Stan Goodman composed:
While awaiting a reply, I booted to DFSee to try to find anything that seemed out of the ordinary. I found that DFSee says that "MBR boot code unknown to DFSee" (it should be generic). So I thought to take a shot at making new MBR code. When it came to choosing which HD, DFSee reported that the sole disk present as "1 Disk2 ....". Before any of this mess happened, I reported to Jan that, depending where in DFSee one looked, the HD numbers were interchanged, or they were both labeled Disk2. He didn't know what to make of this.
1-Boot to BIOS setup 2-Note which HD is selected as first boot priority 3-Exit BIOS setup with save & power down 4-Disconnect SATA cable and/or power cable from Hitachi 5-Boot to BIOS setup 6-Note if first boot priority has changed 7-Use DFSee to give the Seagate a LVM disk name that includes the word Seagate 8-Use DFSee to 'newmbr 1' (or same thing via its menu) 9-Try to boot Seagate 10-Reconnect Hitachi 11-Boot to BIOS setup 12-Ensure Seagate is first HD priority 13-Exit BIOS setup with save, power off 14-Use DFSee to give Hitachi a LVM disk name that includes the word Hitachi 15-Use DFSee to newmbr the Hitachi 16-Note which disk is #1 & which is #2 according to DFSee 17-Exit DFSee 18-Restart DFSee with new logname DFSWORK2.TXT 19-Exit DFSee 20-Upload DFSWORK2.TXT to ftp://hashkedim.com/pub/ 21-Make hashkedim.com/pub available via HTTP (cannot right click links to open in new tabs from FTP list in Firefox 4 or SeaMonkey 2.1) 22-Boot whichever HD brings up BM 23-Try to get a Grub prompt or menu 24-report back -- "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 Thursday 28 October 2010 16:13:55 Felix Miata wrote:
On 2010/10/28 14:58 (GMT+0200) Stan Goodman composed:
While awaiting a reply, I booted to DFSee to try to find anything that seemed out of the ordinary. I found that DFSee says that "MBR boot code unknown to DFSee" (it should be generic). So I thought to take a shot at making new MBR code. When it came to choosing which HD, DFSee reported that the sole disk present as "1 Disk2 ....". Before any of this mess happened, I reported to Jan that, depending where in DFSee one looked, the HD numbers were interchanged, or they were both labeled Disk2. He didn't know what to make of this.
1-Boot to BIOS setup 2-Note which HD is selected as first boot priority
Seagate (11.3)
3-Exit BIOS setup with save & power down 4-Disconnect SATA cable and/or power cable from Hitachi 5-Boot to BIOS setup 6-Note if first boot priority has changed 7-Use DFSee to give the Seagate a LVM disk name that includes the word Seagate 8-Use DFSee to 'newmbr 1' (or same thing via its menu) 9-Try to boot Seagate
Boot Manager now comes up, and a v11.3 herald screen, after which there is a maintenance screen, showing actions during the boot process. The first line is: Trying manual resume from /dev/disk/by-id/ata-<Seagate#>-part5 . . . . . . /dev/sda6: UNEXPECTED INCONSISTENCY: Run fsck MANUALLY (i.e. without -a or -p optiona) fsck failed. Mounting root device read-only (Here the line "activating swap-devices in /etc/fstab" failed) fsck failed. Please repair manually and repeat. The root file system is currently read only To remount it read-write do # mount -n -o remount, rw/ ATTENTION Only CONTROL-D will reboot the system in this maintenance mode. shutdown or reboot will not work. It asked for root's pw, and I gave it, then a prompt appeared in red: repair file system # I am not clear whether it wants me now to do fsck or to remount. If the former, I assume it is on the installation DVD.
10-Reconnect Hitachi 11-Boot to BIOS setup 12-Ensure Seagate is first HD priority
It is.
13-Exit BIOS setup with save, power off 14-Use DFSee to give Hitachi a LVM disk name that includes the word Hitachi 15-Use DFSee to newmbr the Hitachi 16-Note which disk is #1 & which is #2 according to DFSee
In "MBR and EBR operations, both are Disk2.
17-Exit DFSee 18-Restart DFSee with new logname DFSWORK2.TXT
Having done nothing in between?
19-Exit DFSee
Nothing was recorded.
20-Upload DFSWORK2.TXT to ftp://hashkedim.com/pub/ 21-Make hashkedim.com/pub available via HTTP (cannot right click links to open in new tabs from FTP list in Firefox 4 or SeaMonkey 2.1)
The FTP facility is not available, because I have not had time to deao with it since the hosting service disabled it after telling me that it had been invaded. Is there somewhere else I can upload for the List (when I have something to upload)?
22-Boot whichever HD brings up BM
See above. I can get as far as the <repair file system #> prompt. If you intend that I boot from GRUB, please tell me how to get to a GRUB prompt.
23-Try to get a Grub prompt or menu 24-report back
-- 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/11/06 17:12 (GMT+0200) Stan Goodman composed:
1-Boot to BIOS setup 2-Note which HD is selected as first boot priority
Seagate (11.3)
3-Exit BIOS setup with save& power down 4-Disconnect SATA cable and/or power cable from Hitachi 5-Boot to BIOS setup 6-Note if first boot priority has changed 7-Use DFSee to give the Seagate a LVM disk name that includes the word Seagate 8-Use DFSee to 'newmbr 1' (or same thing via its menu) 9-Try to boot Seagate
Boot Manager now comes up, and a v11.3 herald screen, after which
No Grub menu? This implies first boot after initial installation never previously succeeded. First "boot" by default isn't a complete reboot. By default the installer uses kexec to re-init after replacing the installation kernel in memory with the installed kernel and initrd.
there is a maintenance screen, showing actions during the boot process.
These are normal boot messages, normally hidden by the "quiet" the installer puts on the Grub menu's kernel lines. By removing quiet and/or putting splash=verbose on those kernel lines you get to watch boot progress instead of wondering what if anything is happening while trying to get the OS started.
The first line is:
Trying manual resume from /dev/disk/by-id/ata-<Seagate#>-part5
The installer presumes you'll be wanting to resume from sleep by putting resume=<swap-partition> on the kernel line. I always remove this from desktop installations, as I never want a multiboot system to presume I want to start wherever I left off. . . .
/dev/sda6: UNEXPECTED INCONSISTENCY: Run fsck MANUALLY (i.e. without -a or -p optiona) fsck failed. Mounting root device read-only
(Here the line "activating swap-devices in /etc/fstab" failed)
fsck failed. Please repair manually and repeat. The root file system is currently read only To remount it read-write do # mount -n -o remount, rw/
I've never figured out how to manually do what couldn't be done automatically upon encountering this series of messages. I fix it by booting something else and doing fsck from that, and if that fails, reformatting and restoring from backup, or reinstalling fresh. Considering what has happened to your system over recent weeks, likely fresh installation of 11.3 will be the best course of action.
ATTENTION Only CONTROL-D will reboot the system in this maintenance mode. shutdown or reboot will not work.
It asked for root's pw, and I gave it, then a prompt appeared in red:
repair file system #
This is a root prompt, but you can't do much from it while / remains mounted ro due to filesystem inconsistency.
I am not clear whether it wants me now to do fsck or to remount. If the former, I assume it is on the installation DVD.
fsck is available from that prompt, but understanding how to get it to do manually what it couldn't figure out how to do automatically has always escaped me. Booting something else in order to fsck is what I always do from this point.
10-Reconnect Hitachi 11-Boot to BIOS setup 12-Ensure Seagate is first HD priority
It is.
13-Exit BIOS setup with save, power off 14-Use DFSee to give Hitachi a LVM disk name that includes the word Hitachi 15-Use DFSee to newmbr the Hitachi 16-Note which disk is #1& which is #2 according to DFSee
In "MBR and EBR operations, both are Disk2.
I don't see how this is possible unless a step is being missed by one of us. Before selecting to perform MBR/EBR area operations from the Mode=FDISK menu you should first select the disk to be operated upon from the File -> Open object to work with menu, or exiting the menu, entering disk nr on the command line, then going back to the Mode=FDISK menu. If it still always refers to disk 2, maybe this is a question to refer to Jan. Simply starting DFSee you should see a table of partitioning, with each HD having a heading line that includes: ---<disk #></dev/sdX>--------<LVM disk label>--- The first should have *Seagate*, the second *Hitachi*.
17-Exit DFSee 18-Restart DFSee with new logname DFSWORK2.TXT
Having done nothing in between?
Right, to generate a DFSee log with nothing in it other than the information it displays upon startup.
19-Exit DFSee
Nothing was recorded.
Are you sure? Did you hit ESC at startup instead of typing in DFSWORK2.TXT and hitting <enter>? Did you start DFSee from floppy or CD and have no writable space available to save the log?
20-Upload DFSWORK2.TXT to ftp://hashkedim.com/pub/ 21-Make hashkedim.com/pub available via HTTP (cannot right click links to open in new tabs from FTP list in Firefox 4 or SeaMonkey 2.1)
The FTP facility is not available, because I have not had time to deao with it since the hosting service disabled it after telling me that it had been invaded. Is there somewhere else I can upload for the List (when I have something to upload)?
http://susepaste.org/ & http://pastebin.com/ are two of many places that can serve this purpose. See also http://en.wikipedia.org/wiki/Pastebin
22-Boot whichever HD brings up BM
See above. I can get as far as the<repair file system #> prompt. If you intend that I boot from GRUB, please tell me how to get to a GRUB prompt.
What happened above was a Grub menu bypass that is normal on first boot following installation. If you were to try again, I would expect you would get a Grub menu or Grub prompt before a root repair # prompt.
23-Try to get a Grub prompt or menu 24-report back
This has been some progress. -- "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 Sunday 07 November 2010 06:49:17 Felix Miata wrote:
On 2010/11/06 17:12 (GMT+0200) Stan Goodman composed:
1-Boot to BIOS setup 2-Note which HD is selected as first boot priority
Seagate (11.3)
3-Exit BIOS setup with save& power down 4-Disconnect SATA cable and/or power cable from Hitachi 5-Boot to BIOS setup 6-Note if first boot priority has changed 7-Use DFSee to give the Seagate a LVM disk name that includes the word Seagate 8-Use DFSee to 'newmbr 1' (or same thing via its menu) 9-Try to boot Seagate
Boot Manager now comes up, and a v11.3 herald screen, after which
No Grub menu? This implies first boot after initial installation never previously succeeded. First "boot" by default isn't a complete reboot. By default the installer uses kexec to re-init after replacing the installation kernel in memory with the installed kernel and initrd.
there is a maintenance screen, showing actions during the boot process.
These are normal boot messages, normally hidden by the "quiet" the installer puts on the Grub menu's kernel lines. By removing quiet and/or putting splash=verbose on those kernel lines you get to watch boot progress instead of wondering what if anything is happening while trying to get the OS started.
That long list of actions is what I normally see when booting. This one is much shorter, and only a few lines are concerned with anything other than worrying about fsck.
The first line is:
Trying manual resume from /dev/disk/by-id/ata-<Seagate#>-part5
The installer presumes you'll be wanting to resume from sleep by putting resume=<swap-partition> on the kernel line. I always remove this from desktop installations, as I never want a multiboot system to presume I want to start wherever I left off. . . .
/dev/sda6: UNEXPECTED INCONSISTENCY: Run fsck MANUALLY (i.e. without -a or -p optiona) fsck failed. Mounting root device read-only
(Here the line "activating swap-devices in /etc/fstab" failed)
fsck failed. Please repair manually and repeat. The root file system is currently read only To remount it read-write do # mount -n -o remount, rw/
I've never figured out how to manually do what couldn't be done automatically upon encountering this series of messages. I fix it by booting something else and doing fsck from that, and if that fails, reformatting and restoring from backup, or reinstalling fresh. Considering what has happened to your system over recent weeks, likely fresh installation of 11.3 will be the best course of action.
I've been thinking about that for some time, but I have done a great deal of configuration etc, and would resist losing it. I could make a new partition to replace sda6, say sda8, and reinstall to it, specibying that the sda7 continue to be used for /home, and not be formatted. Or maybe easier, copy sda7 to a backup partition, reinstall in the existing partitions as they are, then recopy the backup over sda7. Question: If the problem is in GRUB, does it make sense to use David Rankin's GRUB Recovery Cheat Sheet, and make a new GRUB?
ATTENTION Only CONTROL-D will reboot the system in this maintenance mode. shutdown or reboot will not work.
It asked for root's pw, and I gave it, then a prompt appeared in red:
repair file system #
This is a root prompt, but you can't do much from it while / remains mounted ro due to filesystem inconsistency.
I am not clear whether it wants me now to do fsck or to remount. If the former, I assume it is on the installation DVD.
fsck is available from that prompt, but understanding how to get it to do manually what it couldn't figure out how to do automatically has always escaped me. Booting something else in order to fsck is what I always do from this point.
If this is something I should do, where is fsck and how can I get to it?
10-Reconnect Hitachi 11-Boot to BIOS setup 12-Ensure Seagate is first HD priority
It is.
13-Exit BIOS setup with save, power off 14-Use DFSee to give Hitachi a LVM disk name that includes the word Hitachi 15-Use DFSee to newmbr the Hitachi 16-Note which disk is #1& which is #2 according to DFSee
In "MBR and EBR operations, both are Disk2.
I don't see how this is possible unless a step is being missed by one of us. Before selecting to perform MBR/EBR area operations from the Mode=FDISK menu you should first select the disk to be operated upon from the File -> Open object to work with menu, or exiting the menu, entering disk nr on the command line, then going back to the Mode=FDISK menu. If it still always refers to disk 2, maybe this is a question to refer to Jan.
"missed by one of us"? You are too kind to me. I spoke with Jan about this months ago, before this problem developed; he mentioned taking it up with you, as a matter of fact. I'll repeat the exercise, and let you know what happened. I think it isn't necessary to first select the disk to be operated upon, because it asks which disk after one chooses to make a new MBR. But I will do exactly as written above when I repeat the procedure.
Simply starting DFSee you should see a table of partitioning, with each HD having a heading line that includes:
---<disk #></dev/sdX>--------<LVM disk label>---
The first should have *Seagate*, the second *Hitachi*.
Yes, of course. And that's the way it is.
17-Exit DFSee 18-Restart DFSee with new logname DFSWORK2.TXT
Having done nothing in between?
Right, to generate a DFSee log with nothing in it other than the information it displays upon startup.
19-Exit DFSee
Nothing was recorded.
Are you sure? Did you hit ESC at startup instead of typing in DFSWORK2.TXT and hitting <enter>? Did you start DFSee from floppy or CD and have no writable space available to save the log?
I definitely made the DFSWORK2 directory on a USB stick.
20-Upload DFSWORK2.TXT to ftp://hashkedim.com/pub/ 21-Make hashkedim.com/pub available via HTTP (cannot right click links to open in new tabs from FTP list in Firefox 4 or SeaMonkey 2.1)
The FTP facility is not available, because I have not had time to deao with it since the hosting service disabled it after telling me that it had been invaded. Is there somewhere else I can upload for the List (when I have something to upload)?
http://susepaste.org/ & http://pastebin.com/ are two of many places that can serve this purpose. See also http://en.wikipedia.org/wiki/Pastebin
22-Boot whichever HD brings up BM
See above. I can get as far as the<repair file system #> prompt. If you intend that I boot from GRUB, please tell me how to get to a GRUB prompt.
What happened above was a Grub menu bypass that is normal on first boot following installation. If you were to try again, I would expect you would get a Grub menu or Grub prompt before a root repair # prompt.
I have fired up the system several times since, always with the same result.
23-Try to get a Grub prompt or menu 24-report back
At this point, I would settle for getting back to a GRUB prompt that I could boot from, like before.
This has been some progress.
Yeah? -- 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/11/07 12:22 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
I've never figured out how to manually do what couldn't be done automatically upon encountering this series of messages. I fix it by booting something else and doing fsck from that, and if that fails, reformatting and restoring from backup, or reinstalling fresh. Considering what has happened to your system over recent weeks, likely fresh installation of 11.3 will be the best course of action.
I've been thinking about that for some time, but I have done a great deal of configuration etc, and would resist losing it.
I could make a new partition to replace sda6, say sda8, and reinstall to it, specibying that the sda7 continue to be used for /home, and not be formatted. Or maybe easier, copy sda7 to a backup partition, reinstall in the existing partitions as they are, then recopy the backup over sda7.
You could, but I don't think that's necessary quite yet. Certainly sda7 can be used for /home without formatting. If you want to learn what's actually wrong with sda6 without stumbling through emergency boots to do it, by all means create sda8 to install to. I suggest if you do, disconnect the Hitachi to protect against the possibility of recurrence of whatever went wrong last time.
Question: If the problem is in GRUB, does it make sense to use David Rankin's GRUB Recovery Cheat Sheet, and make a new GRUB?
Assuming Grub were the problem, both yes and no. Followed exactly you'd lose IBM BM. The step setup (hd0) needs to instead be setup (hd0,5) in order to install Grub properly on sda6 instead of the MBR. Right now you seem to have an almost working Grub that reinstalling likely would not fix. Someone else needs to chime in here, because I don't know how the installer manipulates Grub to bypass the Grub menu (and access to a Grub prompt) on first boot after installation. If the bypass could be unset or ignored, you could reach a Grub prompt, from which you could chainload to sdb6 to perform further repair to sda6. The thing is, without a working Grub, you'd not be seeing what follows...
fsck is available from that prompt, but understanding how to get it to do manually what it couldn't figure out how to do automatically has always escaped me. Booting something else in order to fsck is what I always do from this point.
If this is something I should do, where is fsck and how can I get to it?
It's right there like I wrote. From the # repair shell prompt, type 'fsck /dev/sda6', but good luck actually getting it to fix anything. Unless you can get it fixed from the repair prompt, or boot some CD or DVD to run fsck successfully, I think you'll need to reinstall. I'm wondering if this corrupt filesystem message is due to corruption in the installer's 11.3 initrd rather than the filesystem itself, causing it to think it's operating on sda6 but instead seeing sdb6? I believe until you can make the Seagate boot 11.3, you may need to leave the Hitachi disconnected to protect its content.
Right, to generate a DFSee log with nothing in it other than the information it displays upon startup.
19-Exit DFSee
Nothing was recorded.
Are you sure? Did you hit ESC at startup instead of typing in DFSWORK2.TXT and hitting<enter>? Did you start DFSee from floppy or CD and have no writable space available to save the log?
I definitely made the DFSWORK2 directory on a USB stick.
I've yet to run DFSee while any type of USB device is connected, not even a mouse IIRC. I wonder if there are any bugs regarding disk ordering when DFSee is run from USB? It should be a DFSWORK2.TXT log file, not a directory.
What happened above was a Grub menu bypass that is normal on first boot following installation. If you were to try again, I would expect you would get a Grub menu or Grub prompt before a root repair # prompt.
I have fired up the system several times since, always with the same result.
So Grub on sda6 is actually working, just bypassing the menu because the final step of installation has yet to succeed, and boot can't succeed while the / filesystem on sda6 remains "corrupt".
23-Try to get a Grub prompt or menu 24-report back
At this point, I would settle for getting back to a GRUB prompt that I could boot from, like before.
As long as we can't figure out how to bypass the Grub menu bypass, or more importantly, get sda6 uncorrupted, I think you're stuck with needing to reinstall. -- "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 Sunday 07 November 2010 16:29:00 Felix Miata wrote:
On 2010/11/07 12:22 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
I've never figured out how to manually do what couldn't be done automatically upon encountering this series of messages. I fix it by booting something else and doing fsck from that, and if that fails, reformatting and restoring from backup, or reinstalling fresh. Considering what has happened to your system over recent weeks, likely fresh installation of 11.3 will be the best course of action.
I've been thinking about that for some time, but I have done a great deal of configuration etc, and would resist losing it.
I could make a new partition to replace sda6, say sda8, and reinstall to it, specibying that the sda7 continue to be used for /home, and not be formatted. Or maybe easier, copy sda7 to a backup partition, reinstall in the existing partitions as they are, then recopy the backup over sda7.
You could, but I don't think that's necessary quite yet. Certainly sda7 can be used for /home without formatting. If you want to learn what's actually wrong with sda6 without stumbling through emergency boots to do it, by all means create sda8 to install to. I suggest if you do, disconnect the Hitachi to protect against the possibility of recurrence of whatever went wrong last time.
Question: If the problem is in GRUB, does it make sense to use David Rankin's GRUB Recovery Cheat Sheet, and make a new GRUB?
Assuming Grub were the problem, both yes and no. Followed exactly you'd lose IBM BM. The step
Losing IBM BM would not be a disaster, since VirtualBox became available and I can run a Windows virtually.
setup (hd0)
needs to instead be
setup (hd0,5)
in order to install Grub properly on sda6 instead of the MBR.
Right now you seem to have an almost working Grub that reinstalling likely would not fix. Someone else needs to chime in here, because I don't know how the installer manipulates Grub to bypass the Grub menu (and access to a Grub prompt) on first boot after installation. If the bypass could be unset or ignored, you could reach a Grub prompt, from which you could chainload to sdb6 to perform further repair to sda6.
The thing is, without a working Grub, you'd not be seeing what follows...
fsck is available from that prompt, but understanding how to get it to do manually what it couldn't figure out how to do automatically has always escaped me. Booting something else in order to fsck is what I always do from this point.
If this is something I should do, where is fsck and how can I get to it?
It's right there like I wrote. From the # repair shell prompt, type 'fsck /dev/sda6', but good luck actually getting it to fix anything. Unless you can get it fixed from the repair prompt, or boot some CD or DVD to run fsck successfully, I think you'll need to reinstall.
I'm wondering if this corrupt filesystem message is due to corruption in the installer's 11.3 initrd rather than the filesystem itself, causing it to think it's operating on sda6 but instead seeing sdb6? I believe until you can make the Seagate boot 11.3, you may need to leave the Hitachi disconnected to protect its content.
Right, to generate a DFSee log with nothing in it other than the information it displays upon startup.
19-Exit DFSee
Nothing was recorded.
Are you sure? Did you hit ESC at startup instead of typing in DFSWORK2.TXT and hitting<enter>? Did you start DFSee from floppy or CD and have no writable space available to save the log?
I definitely made the DFSWORK2 directory on a USB stick.
I've yet to run DFSee while any type of USB device is connected, not even a mouse IIRC. I wonder if there are any bugs regarding disk ordering when DFSee is run from USB?
It should be a DFSWORK2.TXT log file, not a directory.
What happened above was a Grub menu bypass that is normal on first boot following installation. If you were to try again, I would expect you would get a Grub menu or Grub prompt before a root repair # prompt.
I have fired up the system several times since, always with the same result.
So Grub on sda6 is actually working, just bypassing the menu because the final step of installation has yet to succeed, and boot can't succeed while the / filesystem on sda6 remains "corrupt".
23-Try to get a Grub prompt or menu 24-report back
At this point, I would settle for getting back to a GRUB prompt that I could boot from, like before.
As long as we can't figure out how to bypass the Grub menu bypass, or more importantly, get sda6 uncorrupted, I think you're stuck with needing to reinstall.
Now I am really confused. in your paragraph just above, and again a few paragraphs up, you say I will need to reinstall. Yet near the top, you say that isn't necessary yet, and also that we seem to be closing in in fixing the existing installation. .....? -- 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/11/07 18:04 (GMT+0200) Stan Goodman composed:
Now I am really confused. in your paragraph just above, and again a few paragraphs up, you say I will need to reinstall. Yet near the top, you say that isn't necessary yet, and also that we seem to be closing in in fixing the existing installation.
A successful fsck may preclude need to reinstall. If you can find a howto or someone else who knows more about manual fsck from a recovery prompt, or can achieve successful fsck by booting something besides 11.3, then maybe 11.3 will work with little or no further fuss. Otherwise, reinstall, or install to sda8 or 9. Either way, for safety's sake, install with the Hitachi disconnected until after installation has successfully completed. -- "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 Sunday 07 November 2010 19:04:06 Felix Miata wrote:
On 2010/11/07 18:04 (GMT+0200) Stan Goodman composed:
Now I am really confused. in your paragraph just above, and again a few paragraphs up, you say I will need to reinstall. Yet near the top, you say that isn't necessary yet, and also that we seem to be closing in in fixing the existing installation.
A successful fsck may preclude need to reinstall. If you can find a howto or someone else who knows more about manual fsck from a recovery prompt, or can achieve successful fsck by booting something besides 11.3, then maybe 11.3 will work with little or no further fuss. Otherwise, reinstall, or install to sda8 or 9. Either way, for safety's sake, install with the Hitachi disconnected until after installation has successfully completed.
I guess the way to go for fsck information would be to find a forum concerned with GRUB. How to reinstall just the / on another partition is the clear next step. Thanks, Felix. -- 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/11/07 23:25 (GMT+0200) Stan Goodman composed:
I guess the way to go for fsck information would be to find a forum concerned with GRUB.
Once you see any of the kernel & init messages leading up to the recovery shell prompt, Grub has long since finished doing anything it can do. Discussing this on a Grub forum would be 100% off-topic.
How to reinstall just the / on another partition is the clear next step.
No big deal: 1-disconnect the Hitachi 2-create sda9 with DFSee if you don't want to use sda8 as the new 11.3 / 3-put the new target partition in the BM menu 4-install using expert partitioning, specifying sda[8,9] as / and sda7 as /home and formatting only /, optionally doing a repair install without formatting to sda6 if it offers that choice (probably won't unless you've fixed sda6's filesystem inconsistency first, in which case you shouldn't need to install again) -- "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 Monday 08 November 2010 01:51:10 Felix Miata wrote:
On 2010/11/07 23:25 (GMT+0200) Stan Goodman composed:
I guess the way to go for fsck information would be to find a forum concerned with GRUB.
Once you see any of the kernel & init messages leading up to the recovery shell prompt, Grub has long since finished doing anything it can do. Discussing this on a Grub forum would be 100% off-topic.
Then beyond a Google search on "fsck", the obvious clear next stip is reinstall, .....
How to reinstall just the / on another partition is the clear next step.
....which was all that sentence was meant to convey.
No big deal:
No.
1-disconnect the Hitachi 2-create sda9 with DFSee if you don't want to use sda8 as the new 11.3 / 3-put the new target partition in the BM menu 4-install using expert partitioning, specifying sda[8,9] as / and sda7 as /home and formatting only /, optionally doing a repair install without formatting to sda6 if it offers that choice (probably won't unless you've fixed sda6's filesystem inconsistency first, in which case you shouldn't need to install again)
I can use sda8. -- Stan Goodman Qiryat Tiv'on Israel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 08 November 2010 09:58:16 Stan Goodman wrote:
On Monday 08 November 2010 01:51:10 Felix Miata wrote:
On 2010/11/07 23:25 (GMT+0200) Stan Goodman composed:
I guess the way to go for fsck information would be to find a forum concerned with GRUB.
Once you see any of the kernel & init messages leading up to the recovery shell prompt, Grub has long since finished doing anything it can do. Discussing this on a Grub forum would be 100% off-topic.
Then beyond a Google search on "fsck", the obvious clear next stip is reinstall, .....
There have been developments. Remembering your caveat that there were likely to be problems in running fsck manually when it had failed to produce results automatically, I decided to run it once, simply to get a feel for how it worked, so I ran: fsk /dev/sda6 which caused it to ask for confirmation to correct errors. When it finished, I rebooted to the same repair screen, ran fsck again, and it reported that sda6 was clean, which was very rewarding. The "failed" line in the actions report, which was about inconsistent system clock, was now marked "skipped" instead. Actually, it is the date that is wrong, being sometime in 2002; the time of day, which I had set after the resetting of the BIOS, is accurate. Then I wondered why, if sda6 was clean, why I had been returned to the repair screen, and so noticed that the INCONSISTENCY it had been worrying about was now reported on sda7 (the /home partition), so I ran fsck on that partition. A reboot brought the system to its present state, which is that the desktop is now up partially. The chameleon is still there, with the progress gauge (with no progress), but the upper-left quadrant is occupied by the Desktop Folder window. neither the folder nor the rest of the screen is populated. This would seem to be progress. What I would like to do is to run fsk on sda7 again, but I am unsure how to reboot, since there is no button to do so, and I am reluctant to screw things up again by using the OFF switch. Actually, I think that switch does an orderly shutdown before removing power, but I would like to be sure. -- 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/11/08 14:17 (GMT+0200) Stan Goodman composed:
A reboot brought the system to its present state, which is that the desktop is now up partially. The chameleon is still there, with the progress gauge (with no progress), but the upper-left quadrant is occupied by the Desktop Folder window. neither the folder nor the rest of the screen is populated.
This would seem to be progress. What I would like to do is to run fsk on sda7 again, but I am unsure how to reboot, since there is no button to do so, and I am reluctant to screw things up again by using the OFF switch. Actually, I think that switch does an orderly shutdown before removing power, but I would like to be sure.
1-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 2-login as root 3A-init 6 # reboot, or 3B-init 3 # shut down X 4-fsck /dev/sda7 # what you wish 5-init 5 # restart X If a reboot or X restart does not fix X, try: 6-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 7-login as root # if not still logged in from #2 above 8-init 3 # shut down X 9-zypper up # refreshes repos & updates installed packages to latest versions 10-init 5 # restart X 11-report back As an alternative to #3A, reboot from root login can also be accomplished using the reboot command, or the shutdown command, both of which have man pages. Also, telinit can be substituted for any instance above of init, which also has a man page explaining what the init/telinit numbers mean. e.g., 3 produces runlevel 3, which is full system function except for anything that requires X to work. Any time you need to reboot while X is dysfunctional, you can prevent having X start by appending any of single, 1, 2 or 3 to the kernel line while in the Grub menu or from a Grub prompt. Then after performing repairs to the X system, init 5 will attempt to start X and bring up the GDM/KDM/XDM login screen. To test if your window manager is working without bothering with the login screen, you can login from any of the virtual consoles as any regular user (or root if you dare), then run the command startx. Done this way if the display manager is still not producing a menu that allows you to exit, you can kill X completely with Ctrl-Alt-BS Ctrl-Alt-BS. -- "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 Monday 08 November 2010 16:34:18 Felix Miata wrote:
On 2010/11/08 14:17 (GMT+0200) Stan Goodman composed:
A reboot brought the system to its present state, which is that the desktop is now up partially. The chameleon is still there, with the progress gauge (with no progress), but the upper-left quadrant is occupied by the Desktop Folder window. neither the folder nor the rest of the screen is populated.
This would seem to be progress. What I would like to do is to run fsk on sda7 again, but I am unsure how to reboot, since there is no button to do so, and I am reluctant to screw things up again by using the OFF switch. Actually, I think that switch does an orderly shutdown before removing power, but I would like to be sure.
1-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 2-login as root
Fails right here. While the system was sitting here unloved, it has frozen. The mouse cursor doesn't move, and Ctrl-Alt-Fx does nothing.
3A-init 6 # reboot, or 3B-init 3 # shut down X 4-fsck /dev/sda7 # what you wish 5-init 5 # restart X
If a reboot or X restart does not fix X, try: 6-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 7-login as root # if not still logged in from #2 above 8-init 3 # shut down X 9-zypper up # refreshes repos & updates installed packages to latest versions 10-init 5 # restart X 11-report back
As an alternative to #3A, reboot from root login can also be accomplished using the reboot command, or the shutdown command, both of which have man pages.
Also, telinit can be substituted for any instance above of init, which also has a man page explaining what the init/telinit numbers mean. e.g., 3 produces runlevel 3, which is full system function except for anything that requires X to work.
Any time you need to reboot while X is dysfunctional, you can prevent having X start by appending any of single, 1, 2 or 3 to the kernel line while in the Grub menu or from a Grub prompt. Then after performing repairs to the X system, init 5 will attempt to start X and bring up the GDM/KDM/XDM login screen.
To test if your window manager is working without bothering with the login screen, you can login from any of the virtual consoles as any regular user (or root if you dare), then run the command startx. Done this way if the display manager is still not producing a menu that allows you to exit, you can kill X completely with Ctrl-Alt-BS Ctrl-Alt-BS.
-- 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/11/08 17:46 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
1-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 2-login as root
Fails right here. While the system was sitting here unloved, it has frozen. The mouse cursor doesn't move, and Ctrl-Alt-Fx does nothing.
You'll have to force a reboot, power switch if you have no reset button. With a system idle because frozen for several minutes or more, there will not likely be any new filesystem corruption that auto fsck won't handle on restart.
3A-init 6 # reboot, or 3B-init 3 # shut down X 4-fsck /dev/sda7 # what you wish 5-init 5 # restart X
If a reboot or X restart does not fix X, try: 6-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 7-login as root # if not still logged in from #2 above 8-init 3 # shut down X 9-zypper up # refreshes repos& updates installed packages to latest versions 10-init 5 # restart X 11-report back
As an alternative to #3A, reboot from root login can also be accomplished using the reboot command, or the shutdown command, both of which have man pages.
Also, telinit can be substituted for any instance above of init, which also has a man page explaining what the init/telinit numbers mean. e.g., 3 produces runlevel 3, which is full system function except for anything that requires X to work.
Any time you need to reboot while X is dysfunctional, you can prevent having X start by appending any of single, 1, 2 or 3 to the kernel line while in the Grub menu or from a Grub prompt. Then after performing repairs to the X system, init 5 will attempt to start X and bring up the GDM/KDM/XDM login screen.
Above (3) you need to do on your reboot, so that hopefully the broken X won't hang the keyboard. Then login as root, and execute 'zypper up' to hopefully cleanup whatever wasn't properly done in initial X installation. What gfxchip type do you have? If Intel, you might be in for continued trouble with 11.3, and better off sticking to 11.1 or installing 11.2 to use until 11.4 is released.
To test if your window manager is working without bothering with the login screen, you can login from any of the virtual consoles as any regular user (or root if you dare), then run the command startx. Done this way if the display manager is still not producing a menu that allows you to exit, you can kill X completely with Ctrl-Alt-BS Ctrl-Alt-BS. -- "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 Monday 08 November 2010 18:02:44 Felix Miata wrote:
On 2010/11/08 17:46 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
1-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 2-login as root
Fails right here. While the system was sitting here unloved, it has frozen. The mouse cursor doesn't move, and Ctrl-Alt-Fx does nothing.
You'll have to force a reboot, power switch if you have no reset button. With a system idle because frozen for several minutes or more, there will not likely be any new filesystem corruption that auto fsck won't handle on restart.
3A-init 6 # reboot, or 3B-init 3 # shut down X 4-fsck /dev/sda7 # what you wish 5-init 5 # restart X
If a reboot or X restart does not fix X, try: 6-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 7-login as root # if not still logged in from #2 above 8-init 3 # shut down X 9-zypper up # refreshes repos& updates installed packages to latest versions 10-init 5 # restart X 11-report back
As an alternative to #3A, reboot from root login can also be accomplished using the reboot command, or the shutdown command, both of which have man pages.
Also, telinit can be substituted for any instance above of init, which also has a man page explaining what the init/telinit numbers mean. e.g., 3 produces runlevel 3, which is full system function except for anything that requires X to work.
Any time you need to reboot while X is dysfunctional, you can prevent having X start by appending any of single, 1, 2 or 3 to the kernel line while in the Grub menu or from a Grub prompt. Then after performing repairs to the X system, init 5 will attempt to start X and bring up the GDM/KDM/XDM login screen.
Above (3) you need to do on your reboot, so that hopefully the broken X won't hang the keyboard. Then login as root, and execute 'zypper up' to hopefully cleanup whatever wasn't properly done in initial X installation.
What gfxchip type do you have? If Intel, you might be in for continued trouble with 11.3, and better off sticking to 11.1 or installing 11.2 to use until 11.4 is released.
This is an Intel board (915GAV). If that makes v11.3 problematic, then I can wait for v11.4, which I think is scheduled for release in March. That can mean either returning to v11.1, once the booting is straightened out (on the next reboot, I will check to see how v11.1 is behaving after all this). Or I could continue to use v11.2 on the laptop, as I have been doing these weeks.
To test if your window manager is working without bothering with the login screen, you can login from any of the virtual consoles as any regular user (or root if you dare), then run the command startx. Done this way if the display manager is still not producing a menu that allows you to exit, you can kill X completely with Ctrl-Alt-BS Ctrl-Alt-BS.
-- 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/11/08 18:53 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
What gfxchip type do you have? If Intel, you might be in for continued trouble with 11.3, and better off sticking to 11.1 or installing 11.2 to use until 11.4 is released.
This is an Intel board (915GAV). If that makes v11.3 problematic, then I
There are too many different Intel chips for me to keep track of which work OK or not. I just know widespread video trouble with Intel didn't exist in 11.2 like in 11.3.
can wait for v11.4, which I think is scheduled for release in March. That can mean either returning to v11.1, once the booting is straightened out (on the next reboot, I will check to see how v11.1 is behaving after all this). Or I could continue to use v11.2 on the laptop, as I have been doing these weeks.
Since you have so much freespace on the Seagate, and probably a much bigger display on the desktop system, you might consider putting the next 11.4 development milestone (3) on sda6 or sda8, and maybe even 11.2 on the other. If you do a 11.4 milestone and update from the factory-snapshot repo periodically, you'll wind up with 11.4 GA before its release gets announced. That would give you opportunity to complain about bugs soon enough that they might get fixed before whatever follows 11.4 is released. :-) -- "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 Monday 08 November 2010 18:02:44 Felix Miata wrote:
On 2010/11/08 17:46 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
-----snip-----
3A-init 6 # reboot, or 3B-init 3 # shut down X
-----snip-----
Above (3) you need to do on your reboot, so that hopefully the broken X won't hang the keyboard. Then login as root, and execute 'zypper up' to hopefully cleanup whatever wasn't properly done in initial X installation.
In the above paragraph, the clause "Above (3) you need to do on your reboot" is unclear. Can you explain it please? -- 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/11/08 12:32 (GMT-0500) Stan Goodman composed:
Felix Miata wrote:
Above (3) you need to do on your reboot, so that hopefully the broken X won't hang the keyboard. Then login as root, and execute 'zypper up' to hopefully cleanup whatever wasn't properly done in initial X installation.
In the above paragraph, the clause "Above (3) you need to do on your reboot" is unclear. Can you explain it please?
The quoted paragraph refers to the immediately preceding paragraph in my 2010/11/08 11:02 (GMT-0500) reply, originally the next to last paragraph in http://lists.opensuse.org/opensuse/2010-11/msg00291.html IOW, while in your Grub gfxmenu, before the countdown timer boots the default selection, right before pressing <Enter> on the selection you wish to boot, you type a 3. If you have a text menu instead of the gfxmenu, you must hit e on the menu selection you wish to boot, then edit its kernel line to append a 3. If at a Grub prompt, your kernel line must include ' 3 ' somewhere. -- "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 Monday 08 November 2010 16:34:18 Felix Miata wrote:
On 2010/11/08 14:17 (GMT+0200) Stan Goodman composed:
A reboot brought the system to its present state, which is that the desktop is now up partially. The chameleon is still there, with the progress gauge (with no progress), but the upper-left quadrant is occupied by the Desktop Folder window. neither the folder nor the rest of the screen is populated.
This would seem to be progress. What I would like to do is to run fsk on sda7 again, but I am unsure how to reboot, since there is no button to do so, and I am reluctant to screw things up again by using the OFF switch. Actually, I think that switch does an orderly shutdown before removing power, but I would like to be sure.
1-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 2-login as root 3A-init 6 # reboot, or 3B-init 3 # shut down X 4-fsck /dev/sda7 # what you wish 5-init 5 # restart X
If a reboot or X restart does not fix X, try: 6-Switch to 1 of your 6 virtual consoles (Ctrl-Alt-F[1-6]; e.g. Crtl-Alt-F2) 7-login as root # if not still logged in from #2 above 8-init 3 # shut down X 9-zypper up # refreshes repos & updates installed packages to latest versions 10-init 5 # restart X 11-report back
As an alternative to #3A, reboot from root login can also be accomplished using the reboot command, or the shutdown command, both of which have man pages.
Also, telinit can be substituted for any instance above of init, which also has a man page explaining what the init/telinit numbers mean. e.g., 3 produces runlevel 3, which is full system function except for anything that requires X to work.
Any time you need to reboot while X is dysfunctional, you can prevent having X start by appending any of single, 1, 2 or 3 to the kernel line while in the Grub menu or from a Grub prompt. Then after performing repairs to the X system, init 5 will attempt to start X and bring up the GDM/KDM/XDM login screen.
To test if your window manager is working without bothering with the login screen, you can login from any of the virtual consoles as any regular user (or root if you dare), then run the command startx. Done this way if the display manager is still not producing a menu that allows you to exit, you can kill X completely with Ctrl-Alt-BS Ctrl-Alt-BS.
I was prepared this morning to proceed according to your suggestions, but v11.3 seems to have booted to completion, with a populated desktop and all the apps that were loaded weeks ago running. Remembering that the system ran well when I was able to boot from the GRUB prompt, without evident graphic problems, I think it would be worth a try to continue to use it now, until if and when such problems appear. What I see from the reports of problems with 11.3 on Intel boards is that many of them concern either laptops or Nvidia cards, neither of which is the case here. So I think and hope that the problems are straightened out. Felix, I am greatly indebted to you for your advice and guidance, not to mention your patience. From my own point of view, I have learned quite a lot about the booting process and about GRUB that I wouldn't have learned had the original problem not occurred, so it certainly has not been a waste of time for me. WARNING: Anyone who switches my drives in the future will be shot, whether it was me or anyone else. -- Stan Goodman Qiryat Tiv'on Israel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 07 November 2010 06:49:17 Felix Miata wrote:
Nothing was recorded.
Are you sure? Did you hit ESC at startup instead of typing in DFSWORK2.TXT and hitting <enter>? Did you start DFSee from floppy or CD and have no writable space available to save the log?
As always, you are right. Clearly at some point I zigged when I should have zagged. The log file is at <http://susepaste.org/29420363>. It will be up for one day, which I hope is sufficient. (I can repost it later if necessary.) I started DFSee from a CD, and wrote the output to a USB stick that has a bootable DFSee v10.0; I can't use the stick to boot this machine, because the MB's BIOS doesn't support that. It is very strange that the CD, which is also v10.0, announces that there is no key, because I have been using that CD for quite a while, since v10.0 was released, and there was never a problem. So I tried the exercise with a CD of v9.12, which I used for years without complaint, never having been nudged to get a key before the temporary one would run out, and it too now tells me that it is unregistered. You will also notice that the labels of the two HDs are not Seagate and Hitachi. But it is clear from the disk numbers that the first is the Seagate disk and the second is the Hitachi. -- 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/11/07 16:22 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
Are you sure? Did you hit ESC at startup instead of typing in DFSWORK2.TXT and hitting<enter>? Did you start DFSee from floppy or CD and have no writable space available to save the log?
As always, you are right. Clearly at some point I zigged when I should have zagged. The log file is at<http://susepaste.org/29420363>. It will be up for one day, which I hope is sufficient. (I can repost it later if necessary.)
I don't know where those spurrious line feeds came from. Maybe next paste try pastebin.com. The wrapping in susepaste.org's narrow window is uncool too.
You will also notice that the labels of the two HDs are not Seagate and Hitachi. But it is clear from the disk numbers that the first is the Seagate disk and the second is the Hitachi.
Actually, the labels do include Seagate & Hitachi, as the following excerpt from the log shows: +-<disk 1>--</dev/hda >--<Disk2 - D1Seagate>----- ... +-<disk 2>--</dev/hdb >--<Disk2 - D2Hitachi>----- It's just that the table DFSDOS.EXE outputs doesn't provide space for labels so long. I suggest next time you open DFSee that you delete the misleading prefaces in those LVM disk labels, leaving only the words Seagate and Hitachi. What seems evident from those LVM labels is that at some point the BIOS, and thus likely the 11.3 installer during installation, had the Seagate enumerated as the #2 HD, explaining a piece of the puzzle that caused this 11.3 mess in the first place. http://fm.no-ip.com/Tmp/Dfsee/sgdfswork2.txt is your log with the clutter trimmed away. -- "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 Sunday 07 November 2010 17:05:19 Felix Miata wrote:
On 2010/11/07 16:22 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
Are you sure? Did you hit ESC at startup instead of typing in DFSWORK2.TXT and hitting<enter>? Did you start DFSee from floppy or CD and have no writable space available to save the log?
As always, you are right. Clearly at some point I zigged when I should have zagged. The log file is at<http://susepaste.org/29420363>. It will be up for one day, which I hope is sufficient. (I can repost it later if necessary.)
I don't know where those spurrious line feeds came from. Maybe next paste try pastebin.com. The wrapping in susepaste.org's narrow window is uncool too.
You will also notice that the labels of the two HDs are not Seagate and Hitachi. But it is clear from the disk numbers that the first is the Seagate disk and the second is the Hitachi.
Actually, the labels do include Seagate & Hitachi, as the following excerpt from the log shows:
+-<disk 1>--</dev/hda >--<Disk2 - D1Seagate>----- ... +-<disk 2>--</dev/hdb >--<Disk2 - D2Hitachi>-----
I'll take your word for it.
It's just that the table DFSDOS.EXE outputs doesn't provide space for labels so long. I suggest next time you open DFSee that you delete the misleading prefaces in those LVM disk labels, leaving only the words Seagate and Hitachi.
What seems evident from those LVM labels is that at some point the BIOS, and thus likely the 11.3 installer during installation, had the Seagate enumerated as the #2 HD, explaining a piece of the puzzle that caused this 11.3 mess in the first place.
I made those labels to remind that they were both being called Disk2. None of it is an artefact of the BIOS or of 11.3.
http://fm.no-ip.com/Tmp/Dfsee/sgdfswork2.txt is your log with the clutter trimmed away.
So what have we learned from the log? -- 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/11/07 18:04 (GMT+0200) Stan Goodman composed:
Felix Miata wrote:
I made those labels to remind that they were both being called Disk2. None of it is an artefact of the BIOS or of 11.3.
http://fm.no-ip.com/Tmp/Dfsee/sgdfswork2.txt is your log with the clutter trimmed away.
So what have we learned from the log?
From that and more, that precision in descriptive written communication can be absolutely vital to reach success. Context matters, as disk 1 can actually mean HD 2. Whether you write "disk2" or "disk 2" also can matter. It also seems to confirm that identical partitioning on two different HDs could conceivably interplay with BIOS disk order to produce a botched installation of Grub and/or /. -- "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
participants (2)
-
Felix Miata -
Stan Goodman