Trying to install, but SATA drive not recognized (solved)

[WharfRat]

I don't see a menu.lst file on my bootable USB, so not sure where to put this command....

The joys of being unique

Use this post http://forums.linuxmint.com/viewtopic.php?f=46&t=122257 as a guide for editing the boot parameters.

Good luck

[jps286]

Possible success! I edited the syslinux.cfg file on my USB drive to include the command pci=nomsi. Then I booted into Mate from the USB drive and found that Linux now recognizes my new SATA hard drive and existing SATA dvd burner. I'm not going to proceed with installation tonight, but will try tomorrow night and report my results. Wish me luck...

[Cosmo.]

The article you referred to is about using legacy grub, in the meantime we have grub2 and some things have changed.

Read the comments of the article, especially the comment from Mongo on March 20, 2010 21:43 Uhr. This should work.
Some addition from me: Where hes says in the beginning "Edit /etc/default/grub" you actually enter the following command in the terminal:

Code: Select all

gksudo gedit /etc/default/grub

Also update-grub has to be run with root-permissions, so the last command where he says "run update-grub" is actually:

Code: Select all

sudo update-grub

[jps286]

The article you referred to is about using legacy grub, in the meantime we have grub2 and some things have changed.

Read the comments of the article, especially the comment from Mongo on March 20, 2010 21:43 Uhr. This should work.
Some addition from me: Where hes says in the beginning "Edit /etc/default/grub" you actually enter the following command in the terminal:

Code: Select all

gksudo gedit /etc/default/grub

Also update-grub has to be run with root-permissions, so the last command where he says "run update-grub" is actually:

Code: Select all

sudo update-grub

Thanks for pointing this out. Probably saved me from some puzzling later.

Another question. Where should the bootloader be installed in the first place, and which one to use (Windows vs Grub2)? My vague understanding is that BIOS is basically starting/running the bootloader, not Linux, and BIOS is seeing the SATA drive fine. Does that mean that it's ok to put the bootloader on the SATA drive? (I'm basically wondering if there is a chicken and egg problem here. If the computer was unable to see Grub2 on the SATA drive, then the edited file with the pci=nomsi command would never run, and Linux wouldn't boot because the drive would remain invisible. I'm sort of becoming convinced that this won't be a problem, but verification would help....)

[AlbertP]

Please put the bootloader on the SATA drive where Mint is installed (not on a partition - use that only if you have another bootloader which you want to be shown before Grub).

[WharfRat]

I'm basically wondering if there is a chicken and egg problem here. If the computer was unable to see Grub2 on the SATA drive, then the edited file with the pci=nomsi command would never run, and Linux wouldn't boot because the drive would remain invisible. I'm sort of becoming convinced that this won't be a problem, but verification would help

Now that's thinking ahead

Since the problem stems from the kernel grub should load OK. However once the kernel loads it appears that the drive will get lost.

What you can do, before rebooting to the installed kernel, is mount the partition to /mnt and add that parameter to /mnt/boot/grub/grub.cfg. Then immediately after booting add the pci=nomsi to /etc/default/grub. You don't need to update grub at this time since the parameter is already in p;ace, but if you get a kernel update the change will be carried forward.

Good luck again

[jps286]

The article you referred to is about using legacy grub, in the meantime we have grub2 and some things have changed.

Read the comments of the article, especially the comment from Mongo on March 20, 2010 21:43 Uhr. This should work.
Some addition from me: Where hes says in the beginning "Edit /etc/default/grub" you actually enter the following command in the terminal:

Code: Select all

gksudo gedit /etc/default/grub

Also update-grub has to be run with root-permissions, so the last command where he says "run update-grub" is actually:

Code: Select all

sudo update-grub

Hey there Cosmo,

I tried to do this procedure. I edited the file as directed, saved, and then ran the command "sudo update-grub". It returned "/usr/sbin/grub-probe: error: failed to get canonical path of '/cow'."

Is that a problem? Did this fail?

EDIT: It failed. I've tried this a couple more times. I get to the grub menu, select Linux Mate, the Mint logo comes up for a long time, then I get a message saying it took too long for the root device to respond. I think that means that the pci=nomsi command didn't "take", and the drive is invisible.

WharfRat - also tried editing /boot/grub/grub.cfg first and rebooting, with the same result as described above.

Not sure what to do next....

EDIT 2: Should I try to write a script to place in /etc/grub.d similar to that described in the comments of the linked article?

[WharfRat]

I get to the grub menu, select Linux Mate, the Mint logo comes up for a long time, then I get a message saying it took too long for the root device to respond. I think that means that the pci=nomsi command didn't "take", and the drive is invisible.

Boot the live media and mount the mint partition to /mnt. Then return

Code: Select all

grep vmlinuz /mnt/boot/grub/grub.cfg

[AlbertP]

Hey there Cosmo,

I tried to do this procedure.

It is probably a better idea if you just install Mint. Then you can use pci=nomsi in Grub to boot your new Mint the first time (press the E key in the Grub menu, and add the text to the next-to-last line), after which you can edit the grub files normally as described by Cosmo. After Cosmo's procedure, the pci=nomsi argument should be there by default.

By the way, I'm still wondering which SATA controller & driver combination could cause this: Could you post the output of:

Code: Select all

lspci -knn

P.S. if I don't respond quickly to forum posts, it's because I'm moving homes at the moment.

[Cosmo.]

then I get a message saying it took too long for the root device to respond.

This means, that grub was not able to find the partition, where the system ("root") is expected to be.
I cannot imagine, that you did delete the partition. So I assume (sorry, I have nothing more than assumption), that the inserted boot-parameter has the effect, that the hard drive with the root partition does not get recognized any more.

For getting back into your system do the following:
If the grub menu gets shown when booting press the key E, the edit the relevant line and delete the pci=nomsi parameter, than press F10. This should bring you back into the system, where you edit /etcdefault/grub again and remove the parameter, after that an update-grub.

For solving the problem: Sorry, at the moment I have no additional idea.

In the article, where you did find this parameter from, the SATA controller is named. Do you have the same controller? If not, it may be the cause, why the parameter does not work for you. You should answer the question of AlbertP.

[jps286]

Hey there Cosmo,

I tried to do this procedure.

It is probably a better idea if you just install Mint. Then you can use pci=nomsi in Grub to boot your new Mint the first time (press the E key in the Grub menu, and add the text to the next-to-last line), after which you can edit the grub files normally as described by Cosmo. After Cosmo's procedure, the pci=nomsi argument should be there by default.

By the way, I'm still wondering which SATA controller & driver combination could cause this: Could you post the output of:

Code: Select all

lspci -knn

P.S. if I don't respond quickly to forum posts, it's because I'm moving homes at the moment.

Sorry if I wasn't clear. I installed Mint before doing this. At this point, I had completed installation but was still running Mint in live mode off the USB.

[jps286]

then I get a message saying it took too long for the root device to respond.

This means, that grub was not able to find the partition, where the system ("root") is expected to be.
I cannot imagine, that you did delete the partition. So I assume (sorry, I have nothing more than assumption), that the inserted boot-parameter has the effect, that the hard drive with the root partition does not get recognized any more.

For getting back into your system do the following:
If the grub menu gets shown when booting press the key E, the edit the relevant line and delete the pci=nomsi parameter, than press F10. This should bring you back into the system, where you edit /etcdefault/grub again and remove the parameter, after that an update-grub.

For solving the problem: Sorry, at the moment I have no additional idea.

In the article, where you did find this parameter from, the SATA controller is named. Do you have the same controller? If not, it may be the cause, why the parameter does not work for you. You should answer the question of AlbertP.

The command pci=nomsi does work to make my drive visible to Linux. I was able to boot from USB using that parameter, the drive was visible, and I finally completed installation. Then I ran the command: gksudo gedit /etc/default/grub, edited the file, ran sudo update-grub, and got the error previously described.

I think what happened is that this procedure did not cause grub.cfg to update with the new parameter. Therefore, when I reboot, it's still using the old grub.cfg without the pci=nomsi command.

Maybe I can interrupt grub, as you and AlbertP described, during boot and *add* the parameter. Then hopefully it will boot fully into Mint from the HD. Then maybe I can make grub.cfg update permanently.

I'll post the info AlbertP asked for tonight....

[Cosmo.]

Now I'm getting confused:

The command pci=nomsi does work to make my drive visible to Linux. I was able to boot from USB using that parameter, the drive was visible, and I finally completed installation. Then I ran the command: gksudo gedit /etc/default/grub, edited the file, ran sudo update-grub, and got the error previously described.

I think what happened is that this procedure did not cause grub.cfg to update with the new parameter. Therefore, when I reboot, it's still using the old grub.cfg without the pci=nomsi command.

I tell you with my words, how I understand - or maybe misunderstand - this:
You edited the grub-paramater for the live-system. Now you was able to see the SATA hard drive in the live system and consequently you was able to install Mint on this drive. So far so clear.

But now, what did you now? You wrote, that you edited /etc/default/grub and ran update-grub. Does this mean you did that inside the live system? In this case it is clear, that we got a misunderstanding here. This advice is meant to get done inside the installed system.

Please confirm or correct my understanding.

What you plan to do (not quoted here) - what you named your idea - should be the correct solution and work.

BTW: Please do not quote a post fully. Quote only the parts, where you do refer to, that makes understanding easier and removes the need to scroll down for text, that readers have already read before. If no quotes are necessary, use the Post reply button below the last post.

[jps286]

Now I'm getting confused:

I tell you with my words, how I understand - or maybe misunderstand - this:
You edited the grub-paramater for the live-system. Now you was able to see the SATA hard drive in the live system and consequently you was able to install Mint on this drive. So far so clear.

Correct.

But now, what did you now? You wrote, that you edited /etc/default/grub and ran update-grub. Does this mean you did that inside the live system? In this case it is clear, that we got a misunderstanding here. This advice is meant to get done inside the installed system.

Please confirm or correct my understanding.

I tried to do it within the live system. I didn't understand that it was supposed to be inside the installed system. I actually didn't know how to get the installed system to work following reboot. Now I think I understand the process for changing the necessary parameter during Grub loading (based on what you and AlbertP described), so hopefully I can get this done tonight after work.

Thanks for hanging with me on this. It's been a big help.

[WharfRat]

This will be my last intrusion here to prevent further confusion, but I'm fairly confident if you followed my recommendation here http://forums.linuxmint.com/viewtopic.p ... 14#p999329 it would have worked.

[jps286]

This will be my last intrusion here to prevent further confusion, but I'm fairly confident if you followed my recommendation here http://forums.linuxmint.com/viewtopic.p ... 14#p999329 it would have worked.

I actually tried what you suggested. I couldn't get it to work, but it's highly likely I wasn't doing it right. I really appreciate your input throughout this thread.

[jps286]

By the way, I'm still wondering which SATA controller & driver combination could cause this: Could you post the output of:

Code: Select all

lspci -knn

Here it is:

lspci -knn
00:00.0 Host bridge [0600]: VIA Technologies, Inc. K8T890 Host Bridge [1106:0238]
Subsystem: ASUSTeK Computer Inc. Device [1043:815d]
Kernel driver in use: agpgart-amd64
00:00.1 Host bridge [0600]: VIA Technologies, Inc. K8T890 Host Bridge [1106:1238]
00:00.2 Host bridge [0600]: VIA Technologies, Inc. K8T890 Host Bridge [1106:2238]
00:00.3 Host bridge [0600]: VIA Technologies, Inc. K8T890 Host Bridge [1106:3238]
00:00.4 Host bridge [0600]: VIA Technologies, Inc. K8T890 Host Bridge [1106:4238]
00:00.5 PIC [0800]: VIA Technologies, Inc. K8T890 I/O APIC Interrupt Controller [1106:5238]
00:00.7 Host bridge [0600]: VIA Technologies, Inc. K8T890 Host Bridge [1106:7238]
00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237/8251 PCI bridge [K8M890/K8T800/K8T890 South] [1106:b188]
00:02.0 PCI bridge [0604]: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller [1106:a238]
Kernel driver in use: pcieport
00:03.0 PCI bridge [0604]: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller [1106:c238]
Kernel driver in use: pcieport
00:03.1 PCI bridge [0604]: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller [1106:d238]
Kernel driver in use: pcieport
00:03.2 PCI bridge [0604]: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller [1106:e238]
Kernel driver in use: pcieport
00:03.3 PCI bridge [0604]: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller [1106:f238]
Kernel driver in use: pcieport
00:0f.0 SATA controller [0106]: VIA Technologies, Inc. VT8251 AHCI/SATA 4-Port Controller [1106:3349]
Subsystem: ASUSTeK Computer Inc. Device [1043:81b5]
Kernel driver in use: ahci
00:0f.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 07)
Subsystem: ASUSTeK Computer Inc. Device [1043:81b5]
Kernel driver in use: pata_via
00:10.0 USB controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90)
Subsystem: ASUSTeK Computer Inc. Device [1043:81b5]
Kernel driver in use: uhci_hcd
00:10.1 USB controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90)
Subsystem: ASUSTeK Computer Inc. Device [1043:81b5]
Kernel driver in use: uhci_hcd
00:10.2 USB controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90)
Subsystem: ASUSTeK Computer Inc. Device [1043:81b5]
Kernel driver in use: uhci_hcd
00:10.3 USB controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90)
Subsystem: ASUSTeK Computer Inc. Device [1043:81b5]
Kernel driver in use: uhci_hcd
00:10.4 USB controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 90)
Subsystem: ASUSTeK Computer Inc. Device [1043:81b5]
Kernel driver in use: ehci-pci
00:11.0 ISA bridge [0601]: VIA Technologies, Inc. VT8251 PCI to ISA Bridge [1106:3287]
Subsystem: ASUSTeK Computer Inc. Device [1043:81b5]
00:11.7 Host bridge [0600]: VIA Technologies, Inc. VT8237/8251 Ultra VLINK Controller [1106:287e]
Subsystem: VIA Technologies, Inc. VT8237/8251 Ultra VLINK Controller [1106:287e]
00:13.0 PCI bridge [0604]: VIA Technologies, Inc. VT8251 Host Bridge [1106:287b]
00:13.1 PCI bridge [0604]: VIA Technologies, Inc. VT8251 PCI to PCI Bridge [1106:287a]
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
Kernel driver in use: k8temp
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G72 [GeForce 7300 LE] [10de:01d1] (rev a1)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:0275]
Kernel driver in use: nouveau
07:00.0 PCI bridge [0604]: VIA Technologies, Inc. VT8251 PCIE Root Port [1106:287c]
Kernel driver in use: pcieport
07:00.1 PCI bridge [0604]: VIA Technologies, Inc. VT8251 PCIE Root Port [1106:287d]
Kernel driver in use: pcieport
07:01.0 Audio device [0403]: VIA Technologies, Inc. VT8237A/VT8251 HDA Controller [1106:3288]
Subsystem: ASUSTeK Computer Inc. Device [1043:818f]
Kernel driver in use: snd_hda_intel
0a:0c.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter [10ec:8139] (rev 10)
Subsystem: Belkin F5D5000 PCI Card/Desktop Network PCI Card [1799:5000]
Kernel driver in use: 8139too
0a:0d.0 FireWire (IEEE 1394) [0c00]: NEC Corporation uPD72874 [Firewarden] IEEE1394a OHCI 1.1 Link/3-port PHY Controller [1033:00f2] (rev 01)
Subsystem: NEC Corporation uPD72874 [Firewarden] IEEE1394a OHCI 1.1 Link/3-port PHY Controller [1033:00f2]
Kernel driver in use: firewire_ohci

[jps286]

My PC now successfully boots in Linux Mint Mate!

A million thanks to everyone who responded to the thread!

Now if anyone has questions about bicycles or woodworking, I might be able to help with that....