Note: sdd and sde are (new config) are usb input, rest are scsi.
I plug in new 1TB seagate internal drive and it becomes sdc, old sdc becomes
sdd and old sdd becomes sde.
Problem on boot(11.3) get error message no Hard drive information. Watching
boot messages. see fsck is failing looking at new sdc drive (It’s not
partitioned yet). Want for release of 11.3 tommorrow.
Checked BIOS, boot order is Lite-On scsi, sda, sdb, sdd (old sdc), then new
drive (now sdc). Boots into repair command line screen. Ran fsck and
badblocks, no errors on sdb (11.3) and won’t see sdc (new drive) because its
not partitioned. Grub menu presented looks correct with link to 11.2. 11.2
boots with no errors, YaST on it sees new drive with no partitions.
The BIOS sees all the scsi drive on correct scsi port.
If I unplug the new drive everything boots correctly.
Can anyone point me to a how too or see what I’m doing wrong. Is there a way
to modify menu.lst from the repair screen?
In past I just plugged in new drive and went installed from the dvd and it
worked.
Thanks for any pointers, etc. If this should be on hardware list, can
someone move it?
upscope
Intel core 2 duo (E7200) | Intel motherboard (DX48BT2)| Geforce 8400GS |
4GB | SATA 320 GB (2)KDE 4.4.4.
The problem is being caused because the added drive is changing which drive is which in the device.map file located in /boot/grub. Here is an example of my device.map. Normally, if you are booting from a partition on /sda then HD0=sda, sdb = HD1, sdc = HD2 and so forth.
Further, the problem causes issues in your menu.lst also located in /boot/grub. Here is an example of my menu.lst file:
# Modified by YaST2. Last modification on Sun Jul 11 15:46:53 CDT 2010
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader
default 0
timeout 30
gfxmenu (hd0,2)/boot/message
##YaST - activate
###Don't change this comment - YaST2 identifier: Original name: windows 1###
title Windows 7 Ultimate
rootnoverify (hd0,0)
chainloader +1
###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop -- openSUSE 11.3 - 2.6.34-12
root (hd0,2)
kernel /boot/vmlinuz-2.6.34-12-desktop root=/dev/disk/by-id/ata-WDC_WD3000GLFS-01F8U0_WD-WXL408720641-part3 resume=/dev/disk/by-id/ata-WDC_WD3000GLFS-01F8U0_WD-WXL408720641-part2 splash=silent quiet showopts vga=0x314 nomodeset
initrd /boot/initrd-2.6.34-12-desktop
###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.3 - 2.6.34-12
root (hd0,2)
kernel /boot/vmlinuz-2.6.34-12-desktop root=/dev/disk/by-id/ata-WDC_WD3000GLFS-01F8U0_WD-WXL408720641-part3 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x314
initrd /boot/initrd-2.6.34-12-desktop
###Don't change this comment - YaST2 identifier: Original name: floppy###
title Floppy
rootnoverify (fd0)
chainloader +1
Notice that all lines reference the HD0, HD1 and HD2 drives. The partition is setup in the second number. So, loading Linux from the 3rd partition on sda would use the designation (HD0,2) as partition 1 is 0, partition 2 is 1 and so forth.
When you add this drive, you could fake it out through modifications of the device.map file or you could add the new drive in its correct order but you will need to modify your menu.lst file as well. Remember that what ever drive you are booting from IS HD0.
I suggest you remove the new drive and download and make a live CD you can boot from and then make a backup of your device,map and menu.lst files for safe keeping and then modify the active ones, before the new drive is added and then reboot with the new drive to see if it works. I suggest you might post a copy of these two files before adding in the new drive for us to look at here.
<snip>
> The problem is being caused because the added drive is changing which
> drive is which in the device.map file located in /boot/grub. Here is an
> example of my device.map. Normally, if you are booting from a partition
> on /sda then HD0=sda, sdb = HD1, sdc = HD2 and so forth.
</snip>
Thanks I got things figured out. It was mainly menu.lst and getting it
straightened out.
Happy to help upscope. I was not sure if placing a copy of my device.map and menu.lst files would really help except I have several drives in the mix. In any event I love to hear that it helped provide a solution for you. Please do not hesitate to come back and ask for more advice when you need it.
>
> Happy to help upscope. I was not sure if placing a copy of my
> device.map and menu.lst files would really help except I have several
> drives in the mix. In any event I love to hear that it helped provide a
> solution for you. Please do not hesitate to come back and ask for more
> advice when you need it.
>
> Thank You,
> First thanks again. What I found was each version of the OS I had
installed had its own menu.lst. When I installed the new version (11.3 -
released) it created links to the other two but they had links to each other
so it got totally confused. Now I have Links from the new install to 11.3
Rc2 (still moving data to new install) and to 11.2 but they only have normal
boot and fail safe in their menu.lst now. All appears to work great.
No I am not an expert on Akonadi, something new that has shown up in KDE 4.4.4. For those that wonder just what it is I found this description to read.
** Akonadi**
The data storage access mechanism for all PIM (Personal Information Manager) data in KDE SC 4. One single storage and retrieval system allows efficiency and extensibiliy not possible under KDE 3, where each PIM component had its own system. Note that use of Akonadi does not change data storage formats (vcard, iCalendar, mbox, maildir etc.) - it just provides a new way of accessing and updating the data. The main reasons for design and development of Akonadi are of technical nature, e.g. having a unique way to access PIM-data (contacts, calendars, emails…) from different applications (e.g. kmail, kword…), thus eliminating the need to write similar code here and there. Another goal is to de-couple GUI applications like kmail from the direct access to external resources like mail-servers - which was a major reason for bug-reports/wishes with regard to performance/responsiveness in the past.