Hello, On Fri, 12 Mar 2010, Philipp Thomas wrote:

On Fri, 12 Mar 2010 19:25:57 +0100, you wrote:

...

fine. The order openSUSE sees the drives (using fdisk -l) on /dev is different than the physical connect order:

Wellcome to the new dynamic world. Device names get assigned dynamically so the drives get names according to the order in which drives are probed or respond to probes and can't be relied on. That's

That depends. If you have just one SATA-Driver in the initrd (e.g. ahci or sata_nv), the devices get reliably enumerated here. I've recently switched motherboards and simultaneously from SATA-IDE-mode to AHCI-mode (i.e. sata_nv -> ahci), but /dev/sda was and is the same disk. And I use that in grub's device.map and /dev/sda3 in fstab. Anyway: I reliably get /dev/sda to be the disk on the first onboard controller. The driver for the second controller is sata_sil and not in the initrd. In fstab, I use labels for the rest of the partitions.

why we (SuSE) create symlinks in /dev/disk/by-id which point to the corresponding device via an udev rule.

That sucks IMHO. Imagine your bootdisk developing defective sectors. So you replace it (how the data is moved is irrelevevant, even how grub is installed on the new disk). But look at the "fun" you'll have fixing your fstab and grub menu.lst (root= kernel-parameter). I simply have /dev/sda3 in fstab and as kernel-parameter and didn't have to change a thing. Just reinstall grub, as usual. /dev/disk/by-label/ might work as root= parameter.

...

openSUSE is installed on the 6th partition of SATA0 (/dev/sdd6). Grub in openSUSE is set to boot (hd0,5)... which is correct (as I understand Grub) and which boots fine.

The mapping between device names and grub devices is controlled by /boot/grub/device.map or in absence of that by the order the BIOS enumerates them.

And exclusively by grub. And it's only the "view" from the system that grub is installed from that's relevant.

...

I installed Gentoo on the 7th partition of SATA0 (dev/sdd7)... but fdisk -l from the Gentoo install sees the drives differently than openSUSE... it sees the drives like this:

You have two choices. Either you let one grub instance boot all other Linux installations or you install one grub in the master boot record and the other grubs in the boot sector of their respective partition.

Three! You can have a grub for each distribution (let them install to their bootsectors, unless it's an XFS, in that case you can use the MBR or the extended partition BR and IIRC any BR of a logical partition, which is NOT the first sector of that partition, but the sector containing the partitiontable that chains the logical partitions). And then install _one_ grub in the mbr, copy the entries from the other distros and adjust the grub hdX,N devices (see my other mail). And of course, add chainloder entries for "the other grubs". So it's both of the choices Philipp told of. It's also a nice fallback. Especially if you add chainloder entries to the other grubs as well. I've been juggling 3 distros + grubs that way.

In the former case you have to edit the mast menu.list to contain the boot lines from all other Linux installations, in the latter you have to make chainloader entries in the master menu.lst.

In the third case, you can have those chainloaders in addition / as fallback.

Otherwise let David explain you the intricacies of linux booting :)

*heh* Haven't looked at grub2 yet and the kernel lately, and especially not at udev and stuff (I hate automatisms). And I dislike huge initrds. And loading modules "at boot". But at least up to "get the kernel and running" I can elaborate. When you've recreated a MBR-partitiontable from scratch by only using DOS debug.com, pen and a piece of paper and a pocket calculator for some of the hex/dec conversions and bit-shifting, using data from the still existing filesystems, you tend to lose the awe or fear about the whole boot-process, even if you don't really have an idea how the actual boot-code works (e.g. grub stage1, a random DOS boot- sector etc.), it's enough to know _what_ the code does[0] and that it's replaceable i.e. recreatable with a bunch of tools like any bootmanager install or fixmbr etc. BTW: splash=native is a must! :) Don't ever nobody hide no useful kernel messages from me![1] -dnh [0] DOS: load first sector of active primary partition to mem and execute it Grub/Lilo/$otherBM: read rest of itself from whereever, show menu, load relevant Kernel/Sector and execute it. I wonder if a DOS BS could load a Linux if you put a kernel in just the right place (and have root= parameter compiled in) ;) [1] not sure how that goes in english, you get the gist, I hope ;) -- When the SysAdmin answers the phone politely, say "sorry", hang up and run awaaaaay! Informal advice to users at Karolinska Institutet, 1993-1994 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Hello, On Sat, 13 Mar 2010, Philipp Thomas wrote:

On Sat, 13 Mar 2010 00:48:36 +0100, you wrote:

...

That depends. If you have just one SATA-Driver in the initrd (e.g. ahci or sata_nv), the devices get reliably enumerated here.

At least according to our kernel developers it's still nothing to rely on.

Of course not. But if so, it's easy to change. Here it's stable, as I take care of having only one driver in the initrd, and unless that driver does things differently at times, no worries.

...

But look at the "fun" you'll have fixing your fstab and grub menu.lst (root= kernel-parameter).

There really isn't such a problem. Boot a rescue system and look into its /dev/disk/by-id and use the name matching your disk. But I agree that by-id doesn't help in all cases.

I meant: ok, now you've booted e.g. the SUSE rescue-system and want to change the IDs in fstab and grub's menu.lst. $ ls /dev/disk/by-id/... Hm. Which one of those is it? Ok, it should be .....-part3. Darn. No gpm. So, how do you get the id into the two files? Of course, you could boot a live DVD/CD with X and Mouse, or a console-livesystem with GPM. Or save the ls output to a file, and use an editor opening both files to do the C&P. Still sucks. Or write down the ID and enter it manually (good luck with tyops). I'd rather change e.g. /dev/sda3 into /dev/sde3 or whatever and can do that with just about any editor or even plain bash and a bit of pattern matching/replacing magic ;)

...

I simply have /dev/sda3 in fstab and as kernel-parameter and didn't have to change a thing.

Pure luck.

Not really ;) I've only had disks "moving" when I booted a live-DVD (Ubuntu or Knoppix) that loaded both drivers in reversed order, so my sda3 became sdg3.

...

BTW: splash=native is a must! :) Don't ever nobody hide no useful kernel messages from me![1]

There's a IMNSHO better way and that's splash=verbose. That way you keep the background image (in case you choose something more pleasing than the default).

Image? What image? Is there an image? Oh, I remember a "verbose" boot during installation. Horrid. Guess what's just about the first thing I change during bootmanager installation? -dnh -- "Power corrupts, but the power of duct tape corrupts absolutely" -- "Florence Ambrose", on noticing the roof panels of the space ship being only duct-taped in place; from "Freefall" [http://freefall.purrsia.com/ff600/fv00575.htm] -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sun, 14 Mar 2010 15:08:57 +0100 (CET), you wrote:

What use are progress bars for, when you can watch a cute verbose logging text? >:-)

Many executives tend to find progress ars more pleasing though it beats me why. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sun, 14 Mar 2010 16:45:35 +0100, you wrote:

Because they're most focused on the goal, less so on the process?

Could be an explanation. But then they'd need to have somebody at hand if something fails. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Brian K. White wrote:

Per Jessen wrote:

...

Philipp Thomas wrote:

...

On Sun, 14 Mar 2010 15:08:57 +0100 (CET), you wrote:

Philipp, is there any chance you could persuade your mailer to include the poster's name. It's really tiresome having to chase back through the thread to discover who you're quoting :(

Ideally I'd like both myself. Blow-by-blow of the regular text output AND something that estimated percent complete, ie progress bar or circle.

While we're in wishlist mode :) I wish that the blow-by-blow account was reformatted to make it easy to associate the 'failed' with the correct text. At the moment there's a huge blank space between the two that makes it difficult to line them up. Possible solutions would be filling the space with rows of dots, rearranging the lines so the status was at the left-hand edge or just reducing the blanks to 5 or so. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Philipp Thomas wrote:

* Dave Howorth (dhoworth@mrc-lmb.cam.ac.uk) [20100316 11:31]:

...

Philipp, is there any chance you could persuade your mailer to include the poster's name.

No, AFAIK that's not configurable :(

That's a shame; I'd say thanks otherwise :) Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tue, 16 Mar, 2010 at 18:17:03 +0100, Philipp Thomas wrote:

* Dave Howorth (dhoworth@mrc-lmb.cam.ac.uk) [20100316 14:52]:

...

That's a shame

Yes, but most MUAs aren't as configurable as mutt. But when I'm home I'll see how far mine is tweekable.

I don't have anything set in ~/.muttrc - so the above is inherited from /etc/Muttrc, which has: # set attribution="On %d, %n wrote:" # # Name: attribution # Type: string # Default: "On %d, %n wrote:" This is on 11.2, but I think it's been like that more or less forever...? /jon -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Philipp Thomas wrote:

On Tue, 16 Mar 2010 13:52:00 +0000, Dave Howorth wrote:

...

That's a shame; I'd say thanks otherwise :)

As you can see above, thaare in order :)

Thanks :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

* Patrick Shanahan (paka@opensuse.org) [20100316 15:14]:

ain't mutt wunderful :^)

Yepp, though I prefer set attribution='* %n (%a) [%(%y%m%d %H:%M)]:' as you can see :) Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 16 March 2010 13:09:36 Felix Miata wrote:

Shameful that you think archives should be offering up email addresses to spammers,

Check this: http://lists.opensuse.org/opensuse/2010-03/msg00791.html the domain part is removed. Henne is again one step ahead :) -- Regards Rajko, -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

* Felix Miata [03-16-10 19:37]:

There's really no need for a MUA to by default include an email address in an attribution line, or a time that lacks any TZ corrector.

What broken email client provides a "default include an email address in an attribution line" as for TZ (from mutt docs): %d date and time of the message in the format specified by $date_format converted to sender's time zone Date: Tue, 16 Mar 2010 19:35:49 -0400 From: Felix Miata * Felix Miata [03-16-10 19:37]: ps: any spammer mining email addresses may obtain your address as easily from the email header as from the body. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

* Carlos E. R. [03-16-10 21:32]:

On Tuesday, 2010-03-16 at 21:15 -0400, Patrick Shanahan wrote:

...

ps: any spammer mining email addresses may obtain your address as easily from the email header as from the body.

No, because the web pages storing the list archive do not store the headers, only the body text of the emails.

That's the point.

Well, he *implied* a broken MUA/email-client, but. Our list archives obscure the posters email address in the attribution as per your example, so there's still no reason not to provide a "source" for your posting. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Rajko M. wrote:

Henne is again one step ahead :)

Unfortunately Henne is not the only one who publishes archives of this list and others are not so careful. But I don't care anyway ... Carlos E. R. wrote:

On Tuesday, 2010-03-16 at 21:15 -0400, Patrick Shanahan wrote:

...

ps: any spammer mining email addresses may obtain your address as easily from the email header as from the body.

No, because the web pages storing the list archive do not store the headers, only the body text of the emails.

That's the point.

Well any spammer can just subscribe to the list and get all the addresses anyway, which is why I don't really care what's in the archive. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 17 March 2010 09:29:00 Adam Tauno Williams wrote:

+1 I don't care. E-Mail hiding is stupid and pointless.

I can agree with that too. My experience with all accounts that I have is that I see more spam on almost not used accounts, but some people follow advices found on the net and are afraid of publishing email. For them Henne is doing good job to help them not panic. -- Regards Rajko, -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-03-16 18:23, Philipp Thomas wrote:

* Patrick Shanahan (paka@opensuse.org) [20100316 15:14]:

...

ain't mutt wunderful :^)

Yepp, though I prefer

set attribution='* %n (%a) [%(%y%m%d %H:%M)]:'

as you can see :)

IMO, it is preferable not to show the real email address of the previous poster. Our mails are stored in web archives, so it is better if the emails do not show in the text. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkuf4A4ACgkQja8UbcUWM1w8lAD+K3YJk4qqIsoKA1C/F9HP1D5h sQ1P2lNA0wE1KzoSNxoBAJEVZVOZoPdjnzP9BNNcfJYERDi6t8RKUEh0HlvX2g3B =VxAA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sun, 14 Mar 2010 06:11:14 +0100, you wrote:

Image? What image? Is there an image?

Yes, the background image is exchangable and IMHO it does make a difference. The default (grey swirl) isn't very pleasing. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, Mar 12, 2010 at 21:09, Carlos E. R. wrote:

...

SATA0 = 1TB (main drive with 4 partitions for various Linux distributions, 1 swap and 1 /home) SATA1 = 1TB (data drive1, single partition) SATA2 = 500GB (data drive2, single partition) SATA3 = 500GB (data drive3, single partition) SATA4= 320GB (Windows drive)

And how do you know that SATA 0 is 0 and not, say, 3? :-)

Ummm.. well.. Based on the SATA0 label on the motherboard, and the fact that the drive is the first one detected by the BIOS... so based on that.. I am calling it SATA0 :-)

...

/dev/sda = SATA2 /dev/sdb = SATA3 /dev/sdc = SATA4 /dev/hdc = SATA0 /dev/hdd = SATA1

Note that this time the two 1TB drives are picked up as hdc and hdd instead of sdd and sde.

huh? :-o

Exactly. But.. the replies on this thread got me to poke the BIOS a bit more, and I think maybe I've uncovered part of the reason for this... maybe. I have three advanced options for my onboard SATA controler(s).... One to enable it... One to set the SATA type (Native IDE, RAID, or AHCI) and the third... which might be the root of the weird drive order and detection... it's called "OnChip SATA Port4/5 Type" and I can choose between As SATA Type and IDE. The help for the IDE setting says that the SATA Port 4/5 Work at IDE mode. So.. guessing here... what I've been calling SATA0 and SATA1 are on Port4/5... and it was set to IDE mode... so in the case of Gentoo, it picked up the drives as IDE... thus hdc and hdd. The reason.. and I'm guessing here.. that it's hdc and hdd is because that controller looks to be sharing with the PATA controller in some way and the unused IDE0 and IDE1 would be picked up as hda and hdb? As I said.... just guessing while I try to figure this all out.

Otherwise, you have one grub in the MBR, as master grub, and this will load another grub (in any boot partition) as needed, chaining menus - but "makeactive" will not work. The advantage is that you need not use primary partitions and the number of grubs is not limited.

This might be ultimately the way I'll go with it... once I can get it all sorted :-P C . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2010-03-12 at 17:37 -0500, Greg Freemyer wrote:

You must not have your MB controller set to use AHCI. You control that via you bios settings.

I strongly suggest you use AHCI if you can. It is the linux preferred way to talk to a SATA drive.

In my case, if I do that the disks dissapear. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuayfEACgkQtTMYHG2NR9XZ9ACfa8rZU+XGfR/RH0WpVBZ7I4ET w0gAn2uTJ0ihoTmOlJ4767myxQrtogeq =YD5K -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2010-03-13 at 10:25 +0100, David Haller wrote:

Hello,

On Sat, 13 Mar 2010, Carlos E. R. wrote:

...

On Friday, 2010-03-12 at 17:37 -0500, Greg Freemyer wrote:

...

You must not have your MB controller set to use AHCI. You control that via you bios settings.

I strongly suggest you use AHCI if you can. It is the linux preferred way to talk to a SATA drive.

In my case, if I do that the disks dissapear.

What exactly do you not understand about 'if you can'?

Do you have 'ahci' in your initrd? If not: it's your own fault.

Is it my fault that SATA drives dissapear from the bios if ahci is activated in the bios? The choices I have, and it is a new board, are "ide, raid, ahci". I have to use "ide", which in fact means sata, hotplug and all working fine. I'm just pointing out that not everybody can use ahci, or that not all boards implement things correctly. Whatever. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAkubbw0ACgkQtTMYHG2NR9UOWACfa9RgGEIMw2F6AAO68yhg0vE9 g/IAlAsop856KDGQFLGGSbhrU7g3lwo= =NuZE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 06:16 +0100, David Haller wrote:

Hello,

On Sat, 13 Mar 2010, Carlos E. R. wrote:

...

Is it my fault that SATA drives dissapear from the bios if ahci is activated in the bios?

Weird. Do you get a "AHCI Controller" screen after the normal BIOS screen and before the resource listing (that with the IRQs)? I get that with the AMI Bios on a Gigabyte board. What board/BIOS do you have? (just curious)

See my other post wit links to photos to what I see. When I attempt to boot in AHCI mode I see this: http://picpaste.com/Imagen0152.jpg when I attempt to boot - if I remember the correct photo. In IDE mode I see a lot of things in the boot sequence that go too fast for me to remember. I'll try to record a video with my nokia celular phone another day. Quality may be too bad to read, though. Board is MSI P45 Diamond, (dmidecode says: MS-7516). Bios is "American Megatrends Inc.", which I assume is "AMI", V1.5, 10/10/2008.

...

The choices I have, and it is a new board, are "ide, raid, ahci". I have to use "ide", which in fact means sata, hotplug and all working fine.

AFAIR hotplug and NCQ work only in AHCI mode ...

Hotplug is indeed working for me, and it is in in IDE mode. See photos. NCQ I don't know what it is. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkudgpEACgkQtTMYHG2NR9UNKQCeMDdOnKYw4i3V2ziiW4E2dTVh crgAnAhd5vrxjiw7yAhIZaXQtHeBh5df =A0jt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2010-03-15 at 22:09 +0100, David Haller wrote:

...

Hotplug is indeed working for me, and it is in in IDE mode. See photos.

Weird. It shouldn't, as IDE-mode does not support connect/reconnect, maybe your board cheats :))

Or the naming is confusing. Perhaps it is raid in ahci mode only. Who knows... mobo documentation is useless, it just says something like press ahch button to get ahci mode or equivalent useless text.

...

NCQ I don't know what it is.

"Native Command Queueing", i.e. the Controller can reorder requests to better fit data-layout on disk, i.e. it can reduce head movement significantly if e.g. two processes request data from opposite ends of the disk.

Cute! :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuewjMACgkQtTMYHG2NR9URNACdFcT03y3q9ysMoFy/vc+dS6bN PNIAn3QLw59zEtVHux62a9A9wZj2P0l6 =v5T/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Sunday, 2010-03-14 at 12:03 -0400, Greg Freemyer wrote:

On Fri, Mar 12, 2010 at 7:10 PM, Carlos E. R. <> wrote:

...

On Friday, 2010-03-12 at 17:37 -0500, Greg Freemyer wrote:

...

You must not have your MB controller set to use AHCI.  You control that via you bios settings.

I strongly suggest you use AHCI if you can.  It is the linux preferred way to talk to a SATA drive.

In my case, if I do that the disks disappear.

I would seriously file a bug and qualify it as a regression. The core linux ata devs are pushing AHCI as the preferred interface and working to get it fully supported.

They dissapear from the BIOS. The bios sees no disk in the system, so there is no grub, so there is no kernel, so there is no system. To whom do I report? Kernel guys?... good grief, they can't do anything. This is what the bios sees in IDE mode. http://picpaste.com/Imagen0148.jpg I change to AHCI mode: http://picpaste.com/Imagen0150.jpg This are the possibilities the bios offers: http://picpaste.com/Imagen0151.jpg And finally, this is what the bios says it sees with the three interfaces in AHCI mode. ¡All hard disks have disapeared! http://picpaste.com/Imagen0152.jpg Now, what? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkudfk0ACgkQtTMYHG2NR9WN5QCfUFnmR6P/vsYxwSsre2nLhRaQ sM8An09OTmqmfcV4bJO2K1kl8zxvsqcC =ASET -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 20:38 -0400, Felix Miata wrote:

Have you tried putting Grub, kernel and initrd on USB or CD to get booted, and let the AHCI drivers find the disks that the BIOS pretends aren't there?

To what purpose? I need the machine to boot from HD, not CD. Ah, no, the CD also dissapears, it is sata6 in the first photo. See the third photo. Impossible to boot. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkudg9UACgkQtTMYHG2NR9VMAwCdHQQC1QloABkQbF4WoKnHVhyd nYMAnRGiQmEYIbwNaXteh4+fssUiGUvE =twTF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 21:11 -0400, Felix Miata wrote:

On 2010/03/15 01:48 (GMT+0100) Carlos E. R. composed:

...

On Sunday, 2010-03-14 at 20:38 -0400, Felix Miata wrote:

...

...

Have you tried putting Grub, kernel and initrd on USB or CD to get booted, and let the AHCI drivers find the disks that the BIOS pretends aren't there?

...

To what purpose?

Acquiring otherwise unavailable data that might ultimately lead to a better future.

I have done my bit of investigation, and I have been burned in the process. A few weeks ago we finally found a resource lock bug in xfs / kernel loop devices that crashed the kernel. Testing this caused my entire root filesystem (different from the xfs data filesystem being tested) to be destroyed entirely. I had to reinstall from scratch. I lost weeks of configuration work. The xfs bug has been found, but the cause of data destruction in the root (reiserfs) has not being investigated. I'm now very wary of doing tests. :-/

...

I need the machine to boot from HD

What's the difference if you can boot from USB instead to (possibly) achieve better performance?

USB is far slower than the HD. Look, tomorrow (now it is past 2 AM, and I get up at 6) I'll set the external sata drives to AHCI, and try to boot from the remaining internal disks, on IDE mode. I'll try to see if the external disks can be found. Is that good enough for you? - -- Cheers, -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkudjSAACgkQtTMYHG2NR9VJ7gCghJPbGNHNaKeS2QzYuCArNDTb 6iQAn1LxmHzWPpRXGyIBAksv/eV4CBTz =GOW/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 21:57 -0400, Felix Miata wrote:

0On 2010/03/15 02:27 (GMT+0100) Carlos E. R. composed:

...

I'm now very wary of doing tests. :-/

What I suggested wouldn't be a very involved "test". Just copy two files to a stick that you've installed Grub onto, and capture some log files that result from using AHCI instead of IDE BIOS settings, to see if others' recommendation to use AHCI has any real payoff.

I don't have any stick with grub on it, nor any free (ie, available) one.

...

USB is far slower than the HD.

Far slower in this case maybe amounts to 10 seconds at most increase in boot time. Kernel and initrd only need to be read once per boot. Nothing but those two, and Grub, need to load from the slower source. After that, all reads and writes depend on what's been mounted and what if anything you choose to do.

...

Look, tomorrow (now it is past 2 AM, and I get up at 6) I'll set the external sata drives to AHCI, and try to boot from the remaining internal disks, on IDE mode. I'll try to see if the external disks can be found.

...

Is that good enough for you?

I'm just putting some thoughts to words that might be useful. Nothing I need to do depends on what you choose to do with your system. :-) That said, I expect you'll be pleased with what results from your plan for the morning.

Ok, I tested. In the bios setup screen, in the "standard cmos features" I get the list of disks found (ide mode, the default mode for this board): sata 1 \ sata 2 | sata 3 | (C) sata 4 | sata 5 | sata 6 / ide primary master ide primary slave sata 7 \ (B) sata 8 / e-sata 1 \ e-sata 2 / (A) The "integrated peripheral" section, contains these options: On board E-sata controller enabled raid mode ide (options: ide, raid, ahci) (A) Extra raid/ide controller enabled raid mode ide (options: ide, raid, ahci) (B) on-chip ata devices pci ide bus master disabled on chip sata controller enabled raid mode ide (options: ide, raid, ahci) (C) If in this last one I set "ahci" I get a new line: AHCI devices group Pressing enter on this one I see AHCI settings (not enterable) AHCI CD/DVD boot time out 35 (options: 0, 5, 10,..,35) AHCI Port 1 [Not detected] AHCI Port 2 [Not detected] ... AHCI Port 6 [Not detected] If I enter any of these ports, I see: AHCI port 1 Auto (options: auto/not installed) hard disk smart enabled (options: enabled/disabled) Now, if I set the group (C) to "ahci", the system does not boot. I get a black screen with a blinking cursor. If, instead, I set group (A) (two identical 500GB external disks) to ahci, and group (B) to ahci (one 320GB refurbished HD), the system boots, but not normally. After the bios post test, I get: http://picpaste.com/Imagen0192.jpg and after I press the key, I get: http://picpaste.com/Imagen0194.jpg My guess is that it is scanning for a raid setup. This is slow, about 20". After this the system boots. All disks are accesable. The one on "sata 1" is /dev/sdd, and the one on "e-sata 2" is now "/dev/sda". Notice that if the external disks are not powered on during boot, sda is sata1 (as it should be). This is why we can no longer use the classical device names in fstab, except on a few lucky systems. /dev/disk/by-label/Jazz_2 -> ../../sda1 I do a speed test on it (hdparm -tT /dev/sda), and I get: /dev/sda: Timing cached reads: 13528 MB in 2.00 seconds = 6772.15 MB/sec Timing buffered disk reads: 340 MB in 3.00 seconds = 113.19 MB/sec Now I reboot, and change back the settings to "IDE". I redo the speed test: /dev/sda: Timing cached reads: 14162 MB in 2.00 seconds = 7089.54 MB/sec Timing buffered disk reads: 340 MB in 3.00 seconds = 113.17 MB/sec Thus, your claims that I would get a speed advantage using AHCI is not valid on my system. And I actually can plug/unplug it "hot". The log is quite verbose: hd power off event: Mar 15 22:13:42 Elessar kernel: [ 4958.121689] ata1: exception Emask 0x10 SAct 0x0 SErr 0x990000 action 0xe frozen Mar 15 22:13:42 Elessar kernel: [ 4958.121700] ata1: irq_stat 0x00400000, PHY RDY changed Mar 15 22:13:42 Elessar kernel: [ 4958.121707] ata1: SError: { PHYRdyChg 10B8B Dispar LinkSeq } Mar 15 22:13:42 Elessar kernel: [ 4958.121716] ata1: hard resetting link Mar 15 22:13:43 Elessar kernel: [ 4958.844030] ata1: SATA link down (SStatus 0 SControl 300) Mar 15 22:13:48 Elessar kernel: [ 4963.844011] ata1: hard resetting link Mar 15 22:13:48 Elessar kernel: [ 4964.149026] ata1: SATA link down (SStatus 0 SControl 300) Mar 15 22:13:48 Elessar kernel: [ 4964.149042] ata1: limiting SATA link speed to 1.5 Gbps Mar 15 22:13:53 Elessar kernel: [ 4969.149010] ata1: hard resetting link Mar 15 22:13:54 Elessar kernel: [ 4969.455025] ata1: SATA link down (SStatus 0 SControl 310) Mar 15 22:13:54 Elessar kernel: [ 4969.455039] ata1.00: disabled Mar 15 22:13:54 Elessar kernel: [ 4969.455052] ata1: EH complete Mar 15 22:13:54 Elessar kernel: [ 4969.455060] ata1.00: detaching (SCSI 0:0:0:0) Mar 15 22:13:54 Elessar kernel: [ 4969.455824] sd 0:0:0:0: [sda] Synchronizing SCSI cache Mar 15 22:13:54 Elessar kernel: [ 4969.455879] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Mar 15 22:13:54 Elessar kernel: [ 4969.455889] sd 0:0:0:0: [sda] Stopping disk Mar 15 22:13:54 Elessar kernel: [ 4969.455903] sd 0:0:0:0: [sda] START_STOP FAILED Mar 15 22:13:54 Elessar kernel: [ 4969.455910] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK hd power on event: Mar 15 22:17:47 Elessar kernel: [ 5202.656925] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen Mar 15 22:17:47 Elessar kernel: [ 5202.656937] ata1: irq_stat 0x00000040, connection status changed Mar 15 22:17:47 Elessar kernel: [ 5202.656944] ata1: SError: { DevExch } Mar 15 22:17:47 Elessar kernel: [ 5202.656953] ata1: hard resetting link Mar 15 22:17:53 Elessar kernel: [ 5208.582023] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 15 22:17:53 Elessar kernel: [ 5208.582039] ata1.00: link online but device misclassifed Mar 15 22:17:53 Elessar kernel: [ 5208.582042] ata1: link online but 1 devices misclassified, retrying Mar 15 22:17:53 Elessar kernel: [ 5208.582049] ata1: reset failed (errno=-11), retrying in 5 secs Mar 15 22:17:57 Elessar kernel: [ 5212.656012] ata1: hard resetting link Mar 15 22:17:58 Elessar kernel: [ 5213.584020] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 15 22:17:58 Elessar kernel: [ 5213.587938] ata1.00: ATA-8: ST3500418AS, CC38, max UDMA/133 Mar 15 22:17:58 Elessar kernel: [ 5213.587947] ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) Mar 15 22:17:58 Elessar kernel: [ 5213.589250] ata1.00: configured for UDMA/133 Mar 15 22:17:58 Elessar kernel: [ 5213.589262] ata1: EH complete Mar 15 22:17:58 Elessar kernel: [ 5213.589358] scsi 0:0:0:0: Direct-Access ATA ST3500418AS CC38 PQ: 0 ANSI: 5 Mar 15 22:17:58 Elessar kernel: [ 5213.589548] sd 0:0:0:0: Attached scsi generic sg0 type 0 Mar 15 22:17:58 Elessar kernel: [ 5213.589565] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB) Mar 15 22:17:58 Elessar kernel: [ 5213.589631] sd 0:0:0:0: [sda] Write Protect is off Mar 15 22:17:58 Elessar kernel: [ 5213.589639] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 Mar 15 22:17:58 Elessar kernel: [ 5213.589666] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Mar 15 22:17:58 Elessar kernel: [ 5213.589856] sda: sda1 sda2 < sda5 sda6 sda7 > Mar 15 22:17:58 Elessar kernel: [ 5213.652364] sd 0:0:0:0: [sda] Attached SCSI disk Notice the "SATA link up 3.0 Gbps" above, and the partitions found correctly, so hotpluging works as it should. What could I gain by setting ahci mode in the bios? A failed boot, perhaps having to boot from a usb stick, no speed advantage... All sort of problems. My guess is that it is some type of RAID configuration, not really AHCI setup. And if it is AHCI, the bios can not find the disks, specially the group (C), the internal main disks. Perhaps it needs sometype of special disk for it to work on this system. And as far as I can see, I got the latest bios. I don't know if it came that way, or the chaps than assembled my computer did it for me. They took their time... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkueqCMACgkQtTMYHG2NR9Vb/ACcDENuFHKOGTf9u7gWw57m2q8j 8jsAnjWgt9tPc8tt0Ss2sSY6ucnhfWqS =VupK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2010-03-15 at 22:03 +0100, David Haller wrote:

...

Look, tomorrow (now it is past 2 AM, and I get up at 6) I'll set the external sata drives to AHCI, and try to boot from the remaining internal disks, on IDE mode. I'll try to see if the external disks can be found.

(see my other post with the result of this test)

...

Is that good enough for you?

Good enough for me. Anyway: when I set the onboard controller to AHCI, the drives too disappear from the BIOS. And they reappear as IDE-Drives in the BIOS-screen when I set to IDE-mode. But, in AHCI-mode, when I boot, I get the BIOS screen (without(!) the drives), then the RAID-BIOS screen from the extra SATA-Controller,

Yes, something like this. I made a photo. But no prompt for another configuration screen.

and _THEN_ an "AHCI BIOS" screen from AMI, showing my "disappeared drives" and telling me to press ctrl-a to get into the "Hyper Drive Utility" (which is useless).

This one I do not get. See photo on the other post.

Then Grub loads normally (IIRC I didn't need to reinstall grub after the mobo switch and IDE->AHCI change, same drive, reconnected to SATA0 / /dev/sda).

If I set to ahci the group where the boot disk is, that one holding sata1 to sata6, grub does not start. I just get a blank screen, with a blinking cursor near the top left corner.

You just need to add 'ahci' into your initrd before that so that you can actually boot if above is similar with your BIOS.

Adding modules to initrd is pointless, as I don't even get the grub screen. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuewOsACgkQtTMYHG2NR9URaACfRrynrLyXSBEEp8pSZYQeyIbR O6sAn1jPR2Shzy8ORyyc/78OEzN4NxFk =wvWT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 20:44 -0400, Greg Freemyer wrote:

Bizarre.

Looks like a bios bug to me. If you care enough you could check for bios updates.

Well... I guess I could. I assumed that the behaviour I get was the correct behaviour. [...] No, there is no update, I have the latest. Dmidecode says: BIOS Information Vendor: American Megatrends Inc. Version: V1.5 <==== Release Date: 10/10/2008 <==== Address: 0xF0000 Runtime Size: 64 kB ROM Size: 4096 kB Characteristics: ISA is supported PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.15 I have version V1.5, and the last version is 1.5, according to the official info page: http://eu.msi.com/index.php?func=downloaddetail&type=bios&maincat_no=1&prod_no=1478 BIOS Type AMI BIOS File Size 789KB Version 1.5 Update Date 2008-10-10 Description - Update CPU Module. Download 7516v15.zip - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkudhz4ACgkQtTMYHG2NR9XEsgCfRu7A5nYQgHV7qTkiWWsrkzGq vPsAnA7QB5GFH8YOKOuuIQd9GcfsXthG =8qrF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, Mar 12, 2010 at 23:37, Greg Freemyer wrote:

You must not have your MB controller set to use AHCI.  You control that via you bios settings.

I strongly suggest you use AHCI if you can.  It is the linux preferred way to talk to a SATA drive.

You nailed it. I set the controller to use AHCI (and set SATA Port4/5 to SATA instead of the default IDE), reset the drive order so that my boot drive was first... and rebooted. Each installed Linux distribution now sees the drives in the same order, assigns the same /dev node (not that critical I know, but nice to see) etc. Gentoo no longer sees two of the drives as IDE... it's all SATA now, and identical across all installs. That's the result I was aiming for. Does setting to use AHCI do anything for drive access speeds? Next step is putting all the advice here to work, and getting the various Grubs sorted out. I would prefer a single GRUB with all possible bootable OSes in the list... and the openSUSE one is what I'm aiming to get working (since openSUSE is my main OS, the others are just to tinker with) - right now I'm booting all OSes off the Ubuntu Grub. Either way... sep Grubs or a single Grub... I think... I think with all the info in this thread, I should be able to get it sorted :-) C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sat, Mar 13, 2010 at 14:01, Carlos E. R. wrote:

...

You nailed it.  I set the controller to use AHCI (and set SATA Port4/5 to SATA instead of the default IDE), reset the drive order so that my boot drive was first... and rebooted.  Each installed Linux distribution now sees the drives in the same order, assigns the same /dev node (not that critical I know, but nice to see) etc.  Gentoo no longer sees two of the drives as IDE... it's all SATA now, and identical across all installs.  That's the result I was aiming for.

Lucky you :-)

:-) Ha... well... I spent a little time and effort picking the motherboard, and so far it's done me well... Gigabyte GA-MA770-UD3. It has loads of USB ports, SATA ports etc. It's not a good board though if you've got a newer nVidia card and still want to use the IDE ports.. the IDE socket is in a terrible spot.. right under where the vid card extends across the board. You can't plug in the IDE ribbon cable and the vid card at the same time.. the IDE connector is too high and you can't seat the vid card. not a prob for me though since I don't have any IDE drives.. all SATA including the DVD burner.

The problem is updates and upgrades. Each install will modify what it thinks is the correct grub, which is not... so you have to remember to adapt the correct one each time.

Yup. That's partly why I want to use the openSUSE Grub. It's my preferred OS by a long shot anyway... and I'd just have to copy the newlines if any into the boot grub... I actually prefer to set up a link to the kernel (if I can) and then point Grub at the link.. eg /boot/vmlinuz where vmlinuz points at the real kernel... and /boot/initrd etc... then Grub doesn't need an update... that's what openSUSE does... makes life a LOT easier.. just update the link and life is good. C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sun, Mar 14, 2010 at 01:58, Philipp Thomas wrote:

...

You can't plug in the IDE ribbon cable and the vid card at the same time..

The flat ribbon cables? Judging by the height of the PCIe slot on my mobo it should still fit. But granted, a PATA port directly in line with a PCIe video slot *is* a rather dumb idea.

Yes... the connector height is enough when you add up the combined height of the plug and socket, that it gets in the way of the new long profile nVidia cards. If you have an older style video card that isn't much longer than the PCIe slot, then it's fine. I knew of this issue when I bought the board... I have all SATA, so it wasn't a problem. C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sun, Mar 14, 2010 at 06:30, David Haller wrote:

...

motherboard, and so far it's done me well... Gigabyte GA-MA770-UD3. It has loads of USB ports, SATA ports etc.  It's not a good board though if you've got a newer nVidia card and still want to use the IDE ports.. the IDE socket is in a terrible spot.. right under where the vid card extends across the board.  You can't plug in the IDE ribbon cable and the vid card at the same time.. the IDE connector is too high and you can't seat the vid card.

What revision do you have? I have the same board, rev 2.0 it seems, and there the IDE-Slot is "flat" pointing away from the board, thus the IDE-Connector shows to the right (if you're looking at the board).

Looking at

http://www.gigabyte.de/FileList/Image/motherboard_productimage_ga-ma770-ud3_...

it depends on how "fat" the PEG card is at that spot. Anyway: on my board, the green IDE-slot is rotated 90° "downwards", so the connector and cable will leave parallel to the mobo / case "downwards" (in the pic).

It the same motherboard layout as shown in the image you linked. I've got this video card: http://www.blogcdn.com/www.engadget.com/media/2008/07/geforce-gtx-280-07-03-... and once it's plugged in, it covers almost all the way down to the CMOS battery. The clearance over the IDE connector is almost zero. I did experiment a little when I first set up the board, and there is no way you can plug both a GTX card and a standard IDE connector... maybe it's possible with some low profile connector on the ribbon cable... it'd have to be a very low profile connector though :-P If they've redesigned it and rotated the IDE connector 90 degrees... that's a good thing :-) C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2010/03/13 07:12 (GMT) Peter Nikolic composed:

Since people started messing around trying to be clever with this stupid SATA

The "clever" people are the kernel devs upstream. Few if any kernel devs pay any attention to complaints on this distro user list.

and forcing IDE drives to become SCSI devices there has been nothing but continual trouble with drives getting brain dead allocations and this device by name thing is well bin fodder .

Can we all stop trying to prove just how twisted our minds can work and just get back to

Confine your device voodoo rants to the linux-ide mailing list, and _maybe_ someone capable of doing anything about it _might_ listen. Ranting on this subject here is just more list pollution, no more useful than complaints about *buntu popularity, .sigs, or lack of reply-to munging. -- "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 14 Mar 2010 00:49:02 Philipp Thomas wrote:

On Sat, 13 Mar 2010 07:12:28 +0000, you wrote:

...

Since people started messing around trying to be clever with this stupid SATA and forcing IDE drives to become SCSI devices there has been nothing but continual trouble with drives getting brain dead allocations

You're barking up the completely wrong tree. If you want to complain go to linux-ide or the general kernel development list as you won't reach anybody that could change anything here on this list.

And people haven't messed around but rather tried to match hardware and software as best as they could. SATA drives have a lot in common with SCSI drives ( that's the reason why SSA (serial SCSI) controllers can handle both SSA and SATA drives), so it was rather natural to handle them as scsi devices. And for the dynamic nature of device names you also have to blame hardware. Static device handling has no place in modern dynamic hardware.

Maybe thats why Sata is such a PITA and those stupid pathetic connections who the hell dreamt those weak excuses up needs locking away and frying

...

and this device by name thing is well bin fodder .

Only in your eyes. Others regard it as a welcome help to get stable device names.

Now your taking the pith thats a FACT if they are stable why are there so many complaints about names and allocations that change

...

get back to drive on the first interface hda second hdb ect get rid of this stupid enforced scsi rubbish if sata devices need a seperate name then sata satb satc satd makes far more sense

What do you call first interface? Motherboards normally have more then one controller onboard, at least one in the chipset and additional controllers for PATA and/or eSATA drives. Where do you start counting? And how do you want to order the loading of drivers?

...

this device by name thing can we please get rid of this deranged junk ,

It's neither deranged nor junk.

It IS both deranged and junk

...

If devices are read in the order they are on the MB IDE1 is hda and hdb IDE2 is hdc and hdd sata1 is sata sata2 is satb ect it would all work very nicely.

Who defines which port is ide1 or sata1?

Look at the mother board they ARE Marked 0and 1 or 1 and 2 and if your Mobo is not i suggest you send it back as it obviously missed a silk screen process

...

this is one of the things that is holding Linux back it is too difficult to setup and once setup it makes no sense the way drives have been named

In the beginning people said that naming devices other then by drive letter would be too difficult. It all depends on ones POV and the willingness to adapt to new ways of doing things.

And Guess what they have been proved correct time and time again

...

I know there are certain people that are so far up their own backsides that they cant see this but there is our problem pure and simple .

As I said in the beginning, go to opensuse-offtopic if you want to rant or go to the upstreams linu devel mailing lists if you do want to talk top those that could change things. Opensuse is the completely wrong tree to bark up.

Philipp

Not ranting just pointing a few things out but a small minority choose to ignore a majority so cus i aint afraid of any of you i speak up Pete . -- Powered by openSUSE 11.2 Milestone 2 (x86_64) Kernel: 2.6.30-rc6-git3-4- default KDE: 4.2.86 (KDE 4.2.86 (KDE 4.3 >= 20090514)) "release 1" 12:31 up 50 days 3:13, 2 users, load average: 0.38, 0.19, 0.07

On Sunday 14 Mar 2010 14:18:40 Carlos E. R. wrote:

On Sunday, 2010-03-14 at 12:40 -0000, Peter Nikolic wrote:

...

...

...

and this device by name thing is well bin fodder .

Only in your eyes. Others regard it as a welcome help to get stable device names.

Now your taking the pith thats a FACT if they are stable why are there so many complaints about names and allocations that change

Device names are not stable. In my machine one day sda is /dev/sda, another it is /dev/sdd. It depends on the external disks being powered up or not. If I used such names in fstab my machine would not boot.

If your devices do not change, you are just lucky.

...

...

...

this device by name thing can we please get rid of this deranged junk ,

It's neither deranged nor junk.

It IS both deranged and junk

It is not. Go complain to the hardware manufacturers and developpers, not here. And you'd better be able to propose a better piece of code.

That is so simple it is untrue we go back to the days of sanity before people started faffing around forcing IDE to be SCSI it worked very well if you connected a drive to the IDE0 port it was either hda or hdb depending on wether it was the master or slave drive

...

...

Who defines which port is ide1 or sata1?

Look at the mother board they ARE Marked 0and 1 or 1 and 2 and if your Mobo is not i suggest you send it back as it obviously missed a silk screen process

And how do you read those labels in software? Perhaps you propose the motherboard has a camera pointing at the cables, so that the kernel can read them and adapt the names "correctly"?

Well if the interface is the first one on the chip then one would expect the software to CORRECTLY identify it as such no strange witch craft there -- Powered by openSUSE 11.2 Milestone 2 (x86_64) Kernel: 2.6.30-rc6-git3-4- default KDE: 4.2.86 (KDE 4.2.86 (KDE 4.3 >= 20090514)) "release 1" 16:55 up 50 days 7:38, 2 users, load average: 0.80, 0.45, 0.33

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2010-03-15 at 21:35 +0100, David Haller wrote:

Hello,

On Sun, 14 Mar 2010, Carlos E. R. wrote:

...

Device names are not stable. In my machine one day sda is /dev/sda, another it is /dev/sdd. It depends on the external disks being powered up or not. If I used such names in fstab my machine would not boot.

Do you have 'usb-storage' in your initrd? If so: you need that only to boot from usb-attached stuff, i.e. as long as you don't have root= in your menu.lst for that kernel/initrd, through out usb-storage from that initrd. No usb-storage, no /dev/sd*. So, as you need the driver (ahci, sata_*) in your initrd to boot, the devices on the controller with that driver should reliably get /dev/sda to /dev/sd[whatever].

Huh? No, I'm talking about external sata drives, ie, on e-sata cables. If they are not powered, sata1 gets the name /dev/sda. If they are powered, eSATA-1 is named /dev/sda instead, but machine still boots from sata-1 as it should. I don't have on that computer disks on usb. Currently. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuexJQACgkQtTMYHG2NR9UpvQCcDN97UdrvdBXZYQ3tOcxKFtCQ 6aIAnA2dto6J+PHEyPcYVyL2uQz08Aaw =LtJg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-03-16 16:51, Per Jessen wrote: I'm not talking about the possible difference of (e-)sata. I'm talking about the same disk, labeled sata1 in the mobo, is sda or sdd if another different cable has the disk connected or not. If my fstab, grub, etc were using /dev/sda names, my system would not be bootable everyday. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkuf4yAACgkQja8UbcUWM1x9lAD/YKZiGrnmHLNzppboWpVjTF4U w4kPlJ7ycsVyqFnG+AABAJswSjPzF/sPvVsu3adQuqEa1iIz2LxvIVg1zG1mz2Gc =6SuK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-03-16 16:51, Per Jessen wrote:

Carlos E. R. wrote:

...

No, I'm talking about external sata drives, ie, on e-sata cables. If they are not powered, sata1 gets the name /dev/sda. If they are powered, eSATA-1 is named /dev/sda instead, but machine still boots from sata-1 as it should.

The only difference between eSATA and SATA is the interface cable and the signalling levels. What you seeing is normal, AFAICT.

I'm not talking about the possible difference of (e-)sata. I'm talking about the same disk, labeled sata1 in the mobo, is sda or sdd if another different cable has the disk connected or not. If my fstab, grub, etc were using /dev/sda names, my system would not be bootable everyday. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkuf4yMACgkQja8UbcUWM1xxowD8CaIJp3c9HcPoTYMiIvNkRkjw Prc69dIiFVtXVkoJzBkA/Av73163uMeIBqUknqx3MlWvBnPLkLsFqDNy1aW9/C5J =GsZz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 01:49 +0100, Philipp Thomas wrote:

On Sat, 13 Mar 2010 07:12:28 +0000, you wrote:

...

get back to drive on the first interface hda second hdb ect get rid of this stupid enforced scsi rubbish if sata devices need a seperate name then sata satb satc satd makes far more sense

What do you call first interface? Motherboards normally have more then one controller onboard, at least one in the chipset and additional controllers for PATA and/or eSATA drives. Where do you start counting? And how do you want to order the loading of drivers?

It is impossible to know. The motherboard has a number of connectors, but there is no way for the software to know wich is number one, which number two... perhaps it should be by the number of plugs, but as you say, there are several sets of sockets, and some can be disabled or enabled on the bios. There is no way for the software to learn the order, and it is not fixed. There is no other way but use names related to some identificator inside the disks, like labels, model/serial, uids... whatever. Now, my doubt, is how grub relates its names, like hd0, hd1, hd2 to the kernel naming like sda, sdb, sdc... there is a device-map file, but that comes later. What logic is used to create that file? is the file used during boot, or is it simply for our information, as I think? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuc7qYACgkQtTMYHG2NR9VCWwCfeBWwAysikUgzd638iPMcW2lZ DP4AoI11ZUc2HL50WjkoQPR5zJqXxcGT =Xab1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 17:51 +0100, Philipp Thomas wrote:

On Sun, 14 Mar 2010 15:11:49 +0100 (CET), you wrote:

...

Now, my doubt, is how grub relates its names, like hd0, hd1, hd2 to the kernel naming like sda, sdb, sdc... there is a device-map file, but that comes later. What logic is used to create that file? is the file used during boot, or is it simply for our information, as I think?

It is created either manually or by YaST during installation and used by grub when booting. Just edit that file and then try to boot but have a rescue system at hand to undo your changes.

On one machine, I have: (hd0) /dev/disk/by-id/ata-ST3500418AS_5VM2RSY4 (hd2) /dev/disk/by-id/ata-ST3500418AS_5VM2RW2E (hd1) /dev/disk/by-id/ata-ST3500418AS_9VM7ZCQQ On another install in the same machine, I got sda, sdc, sdb (from memory). On another disk of that machine, I have: (hd0) /dev/sda (hd1) /dev/sdb (hd2) /dev/sdc All done by oS 11.2 Go figure. I tried to change the order to hd0, hd1, hd2, in the order of the connectors of the motherboard... and then it would not boot. Now I leave things as they are, changes are too unpredictable. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkudGGAACgkQtTMYHG2NR9VA0QCeIjcLBATpWQbQBfrPyxN7v1+i JFQAnR7ieB0Pgg9wgO+7Aup23QKpc+ZO =dJF8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2010-03-15 at 21:40 +0100, David Haller wrote:

On Sun, 14 Mar 2010, Carlos E. R. wrote:

...

...

It is created either manually or by YaST during installation and used by grub when booting. Just edit that file and then try to boot but have a rescue system at hand to undo your changes.

On one machine, I have:

(hd0) /dev/disk/by-id/ata-ST3500418AS_5VM2RSY4 (hd2) /dev/disk/by-id/ata-ST3500418AS_5VM2RW2E (hd1) /dev/disk/by-id/ata-ST3500418AS_9VM7ZCQQ

On another install in the same machine, I got sda, sdc, sdb (from memory). On another disk of that machine, I have:

(hd0) /dev/sda (hd1) /dev/sdb (hd2) /dev/sdc

All done by oS 11.2

Go figure. I tried to change the order to hd0, hd1, hd2, in the order of the connectors of the motherboard... and then it would not boot. Now I leave things as they are, changes are too unpredictable.

You may need to reinstall grub (at least) if you change the mapping of the disk that grub's stuff resides on. Grub needs to know what actual drive his stuff resides on.

No, I left hd0 intact, I tried to reorder hd2 and hd1, which are "inverted". Or so it seems. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuexTkACgkQtTMYHG2NR9XK9ACglwUI7tKaTN5gM1S2tWZ5bdR6 g40Ani2ho3+fXr4z3LzjvCU/R5FHRey0 =ahkc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org