Prev: Simple hack to get $500 to your home.
Next: compiled apache module doesn't show.
From: J.O. Aho on 13 Jun 2010 05:04
nomail@_INVALID_no.org wrote:
> On 06/11/2010 01:20 AM, J.O. Aho wrote:
>> nomail@_INVALID_no.org wrote:
>
>> Just unplug all the other SATA except your boot disk, move it to another SATA
>> port, until you see in the dmesg that it does end up in ata1.00.
>
> Did that. If I plug any drive into the different sata connectors in turn
> I get:
>
> ata3.00: ATA-8: WDC WD20EARS-00S8B1, 80.00A80, max UDMA/133
> ata4.00: ATA-8: WDC WD20EARS-00S8B1, 80.00A80, max UDMA/133
> ata1.00: ATA-8: WDC WD20EARS-00S8B1, 80.00A80, max UDMA/133
> ata2.00: ATA-8: WDC WD20EARS-00S8B1, 80.00A80, max UDMA/133
>
> Sata Bios Grub Kernel
> Plug # hd hd
> 1 sata1 0 ata3
> 2 sata2 1 ata4
> 3 sata3 2 ata1
> 4 sata4 3 ata2

May I ask, have you reset the boot order of disk in your BIOS?


> For a moment I thought that not only you were right but that maybe the
> board connectors had been misprinted, so I swapped the 1-2 & 3-4 cable
> sets and yes, I could now boot with all 4 drives connected but not off
> the root sector of (hd0) and booting a partition on hd0, only with
>
> root (hd2,0)
> kernel /boot/vmlinuz
> initrd /boot/initrd
> boot
>
> This alone would require me to edit too many scripts, it's nowhere near
> a rational standard nor does it resolve the other problem of disks 3-4
> showing up as sdg-sdh instead of sdc-sdd regardless of the above.

It don't requier any of your script to be rewritten, just EDIT your
/boot/grub/device.map
I don't know how many times I have mentioned this file and you keep on
_ignoring_ it all the time.

The different naming of the devices is a minor thing and you can use udev to
name those differently, you know those files you have in /etc/udev.d


> ALL of
> these are unacceptable so I'll just consider this board as a 2-disk one
> with the ability to hot-plug 3 of 4 for data use.



>> And your /boot/grub/device.map?
>> Without that your hd0 could be /dev/sdq as far as we know.
>
> Didn't have one because it's generally not needed.
>
> http://forums.fedoraforum.org/showthread.php?t=153679
>
> Grub doesn't read it except if it cannot determine the partition to be
> booted (hardly ever happens) and neither does the OS. But I forced it to
> write one after a boot with only two disks folowed by hotplugging the 3
> & 4. It wrote out disk ID's instead of device names.

Create one, use it, for you have trouble, you need it.

> (hd2) /dev/disk/by-id/ata-WDC_WD5000AAKS-00V1A0_WD-WMAWF1325726
> (hd1) /dev/disk/by-id/ata-WDC_WD20EARS-00S8B1_WD-WCAVY2992781
> (hd0) /dev/disk/by-id/ata-WDC_WD20EARS-00S8B1_WD-WCAVY2963859
> (fd0) /dev/fd0
> (hd3) /dev/disk/by-id/ata-WDC_WD3200KS-00PFB0_WD-WCAPD2725230
>
> Besides the problem isn't with grub or booting. The correct partition
> does gets booted, it's the kernel that screws it up after loading.

See what you wrote before:

---quote---
I could now boot with all 4 drives connected but not off
the root sector of (hd0) and booting a partition on hd0, only with

root (hd2,0)
kernel /boot/vmlinuz
initrd /boot/initrd
boot
--- eoq ---

>> See your dmesg, it tells you a completely different thing, and as long as it
>> thinks differently, you will have the problem you have.
>>
>>
>> Example from my machine with most SATA hard drives
>>
>> dmesg:
>> ata1.00: ATA-8: WDC WD1001FALS-00J7B1, 05.00K05, max UDMA/133
>> ata2.00: ATA-7: SAMSUNG HD753LJ, 1AA01113, max UDMA7
>> ata4.00: ATA-7: SAMSUNG HD753LJ, 1AA01113, max UDMA7
>> ata3.00: ATA-7: SAMSUNG HD753LJ, 1AA01110, max UDMA7
>> ata5.00: ATA-8: WDC WD1001FALS-00J7B1, 05.00K05, max UDMA/133
>
> Just curious, how do those compare to the relative sata pinouts? Maybe
> I'll have to evaluate future motherboards by their knack to anticipate
> linux kernel behaviour :-)

In my case ataX is always SATA port X and yes I do have PATA devices on the
machine too.

>> In my case everything works as my boot disk is ata1.00, I would have the same
>> problem as you, if I had plugged it into ata2.00.
>
> I understand, you keep saying "plug into ataX" but the user has no ata
> plugs, only sata. You are (or would be prepared to) follow a workaround
> to arrive at what you want.

Do you understand this better:

Plug in the SATA device in port X until it appears as ata1.00 in your dmesg



--

//Aho
From: nomail on 13 Jun 2010 21:14
On 06/13/2010 05:04 AM, J.O. Aho wrote:
> nomail@_INVALID_no.org wrote:


> May I ask, have you reset the boot order of disk in your BIOS?

No, it's pretty standard

Removable
Optical
HD (sata1)
Disabled

>> For a moment I thought that not only you were right but that maybe the
>> board connectors had been misprinted, so I swapped the 1-2 & 3-4 cable
>> sets and yes, I could now boot with all 4 drives connected but not off
>> the root sector of (hd0) and booting a partition on hd0, only with
>>
>> root (hd2,0)
>> kernel /boot/vmlinuz
>> initrd /boot/initrd
>> boot
>>
>> This alone would require me to edit too many scripts, it's nowhere near
>> a rational standard nor does it resolve the other problem of disks 3-4
>> showing up as sdg-sdh instead of sdc-sdd regardless of the above.
>
> It don't requier any of your script to be rewritten, just EDIT your
> /boot/grub/device.map
> I don't know how many times I have mentioned this file and you keep on
> _ignoring_ it all the time.

In a worst case scenario a device.map will be written only once when
grub is installed as part of an original OS installation and never
again. So what if the next day all my disks are new ones except the main
one or maybe that too? All but one of the disks in my machine may be
different ones on every boot. I have to be able to know that whatever I
put into drive bay 3 WILL be /dev/sdc. This is why (even if the map file
were a universal one in which case it wouldn't be needed) I would STILL
run into the other unacceptable obstacle of not having sdc & sdd for #3
& #4.


>> Besides the problem isn't with grub or booting. The correct partition
>> does gets booted, it's the kernel that screws it up after loading.
>
> See what you wrote before:
>
> ---quote---
> I could now boot with all 4 drives connected but not off
> the root sector of (hd0) and booting a partition on hd0, only with
>
> root (hd2,0)
> kernel /boot/vmlinuz
> initrd /boot/initrd
> boot
> --- eoq ---

Yes, I went through the ritual to MAKE it work but the process and
result are unacceptable. Having to get the only appropriate system
script to write out a device.map file after every disk change is already
a workaround, and having to then edit that file because it doesn't work
either is a workaround squared.

I help out clueless users, write guides and helper scripts so ALL so
called workarounds are off limits. EVERYTHING has to be as simple as
possible but mostly predictable on any machine in any configuration. If
I have to guide someone through a 'simplified' use of multi disk/OS
usage, grub and such things and then I have to explain the relationship
between particular motherboards/kernels or WHATEVER (any or all of which
might change the next day) then I'd just be wasting my time.

>> Just curious, how do those compare to the relative sata pinouts? Maybe
>> I'll have to evaluate future motherboards by their knack to anticipate
>> linux kernel behaviour :-)
>
> In my case ataX is always SATA port X and yes I do have PATA devices on the
> machine too.

I of course meant 'without special interventions or workarounds', if so
then which board and what disk/raid chip?


From: J.O. Aho on 14 Jun 2010 00:39
nomail@_INVALID_no.org wrote:
> On 06/13/2010 05:04 AM, J.O. Aho wrote:
>> nomail@_INVALID_no.org wrote:
>
>
>> May I ask, have you reset the boot order of disk in your BIOS?
>
> No, it's pretty standard
>
> Removable
> Optical
> HD (sata1)
> Disabled
>
>>> For a moment I thought that not only you were right but that maybe the
>>> board connectors had been misprinted, so I swapped the 1-2 & 3-4 cable
>>> sets and yes, I could now boot with all 4 drives connected but not off
>>> the root sector of (hd0) and booting a partition on hd0, only with
>>>
>>> root (hd2,0)
>>> kernel /boot/vmlinuz
>>> initrd /boot/initrd
>>> boot
>>>
>>> This alone would require me to edit too many scripts, it's nowhere near
>>> a rational standard nor does it resolve the other problem of disks 3-4
>>> showing up as sdg-sdh instead of sdc-sdd regardless of the above.
>>
>> It don't requier any of your script to be rewritten, just EDIT your
>> /boot/grub/device.map
>> I don't know how many times I have mentioned this file and you keep on
>> _ignoring_ it all the time.
>
> In a worst case scenario a device.map will be written only once when
> grub is installed as part of an original OS installation and never
> again. So what if the next day all my disks are new ones except the main
> one or maybe that too? All but one of the disks in my machine may be
> different ones on every boot. I have to be able to know that whatever I
> put into drive bay 3 WILL be /dev/sdc. This is why (even if the map file
> were a universal one in which case it wouldn't be needed) I would STILL
> run into the other unacceptable obstacle of not having sdc & sdd for #3
> & #4.

The device.map isn't depending on the the exact model of the disk, it depends
on the device as the "disk location" is detected as in the kernel, so if you
set it once while having IBM disks and then switch to Samsung, the device.map
should look the same.

To remap device "names", use udev rules, creating your custom udev rule file
will make it won't be removed when the user does update udev package.


>>> Besides the problem isn't with grub or booting. The correct partition
>>> does gets booted, it's the kernel that screws it up after loading.
>>
>> See what you wrote before:
>>
>> ---quote---
>> I could now boot with all 4 drives connected but not off
>> the root sector of (hd0) and booting a partition on hd0, only with
>>
>> root (hd2,0)
>> kernel /boot/vmlinuz
>> initrd /boot/initrd
>> boot
>> --- eoq ---
>
> Yes, I went through the ritual to MAKE it work but the process and
> result are unacceptable. Having to get the only appropriate system
> script to write out a device.map file after every disk change is already
> a workaround, and having to then edit that file because it doesn't work
> either is a workaround squared.
>
> I help out clueless users, write guides and helper scripts so ALL so
> called workarounds are off limits. EVERYTHING has to be as simple as
> possible but mostly predictable on any machine in any configuration. If
> I have to guide someone through a 'simplified' use of multi disk/OS
> usage, grub and such things and then I have to explain the relationship
> between particular motherboards/kernels or WHATEVER (any or all of which
> might change the next day) then I'd just be wasting my time.

Who does the initial installation?
If you do, then you can do all the things that are necessary to ensure that
things works as they should.
I don't think it will be more difficult to explain for someone to create
device.map than partition the new hard drive into millions small slices.

In your case, use disk labels, this will make things a lot easier for you, and
then it don't matter if a device is sdb once, sda next time and sdq the time
after that. Nowadays it's possible to use disk UUID too, but that can be
tougher to do.


>>> Just curious, how do those compare to the relative sata pinouts? Maybe
>>> I'll have to evaluate future motherboards by their knack to anticipate
>>> linux kernel behaviour :-)
>>
>> In my case ataX is always SATA port X and yes I do have PATA devices on the
>> machine too.
>
> I of course meant 'without special interventions or workarounds', if so
> then which board and what disk/raid chip?

Asus crosshair ii formula, nvidia 780a.

--

//Aho
First  |  Prev  | 
Pages: 1 2 3
Prev: Simple hack to get $500 to your home.
Next: compiled apache module doesn't show.