[opensuse] Confused by hard drive naming/position /dev/sda vs hd0 etc,
OK, I'm really going around in circles here, and I'm just getting confused by it all... maybe someone here could clear the mud for me? Hang in there with me... this is a bit hard to explain :-P My main computer has five SATA hard drives, one SATA DVD drive, and zero PATA drives. The drives are all physically connected to the motherboard SATA controller (no extra controller card etc): 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) openSUSE 11.2 is mounting the drives by ID, and this always works fine. The order openSUSE sees the drives (using fdisk -l) on /dev is different than the physical connect order: /dev/sda = SATA2 /dev/sdb = SATA3 /dev/sdc = SATA4 /dev/sdd = SATA0 /dev/sde = SATA1 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. Now here is where it gets weird. 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: /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. This causes me all sorts of problems.. including a complete failure to boot with an error about no valid root device - which is what led me to start poking into this drive stuff. Next I installed Ubuntu 9.10 on the 5th partition of SATA0. Grub from Ubuntu is set to boot (hd3,5). hd3? Where did that come from? Ubuntu boots fine with this Grub line.... but... how? The SATA0 drive is not hd3 in any way I understand it could be. As well, it picked up openSUSE at (hd3,6), and Windows at (hd2,1)..... yet when I do an fdisk -l it shows the exact same info as openSUSE. So.. with all this conflicting information.. it's making it really hard for me to figure out what Grub in openSUSE should be set to (since I want to use the openSUSE boot menu for all of the installed OSes). Each install thinks the drives are different in some way.. which is making life... difficult to say the least. Why is SATA0 attached to /dev/sdd? Why not /dev/sda? (minor issue since I'm using mount by id, but still... doesn't make sense) Why is one Linux seeing SATA0 as /dev/sdd and the other seeing it as /dev/hdc? Why would Grub in openSUSE see SATA0 as hd0 (which makes sense to me) and Grub in Ubuntu see that same drive as hd3 (which makes no sense at all to me)? Does anyone have any hints or clues for me here? C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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 why we (SuSE) create symlinks in /dev/disk/by-id which point to the corresponding device via an udev rule.
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.
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. 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. Otherwise let David explain you the intricacies of linux booting :) Philipp -- 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 20:14 +0100, Philipp Thomas wrote:
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 why we (SuSE) create symlinks in /dev/disk/by-id which point to the corresponding device via an udev rule.
Related to this, I have a curiosity. I mount by label, and I have noticed that sometimes a drive does not appear; I mean, the label does not appear. It can be the boot drive, in which case grub complains and stops; I just ctrl-alt-supr, and it works. On other times, it is a data drive, and the script that does the fsck fails because it can not find a partition and prompts the admin to do a manual fsck. I just pres ^D, it reboots, and things are fine. What do you think? Hardware? Something is slow and the labeling code times out? It is very sporadic. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuaotsACgkQtTMYHG2NR9W8SQCdFsf8FV8MHp77ILNv44zXup63 xMoAnjX74jxh1XGejW6M1oti0bBGONMu =XTfO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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
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.
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 simply have /dev/sda3 in fstab and as kernel-parameter and didn't have to change a thing.
Pure luck.
Three!
Grmbl, your right of cause :)
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). Philipp -- 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. <fx:moves mouse, try to select the id> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 06:11 +0100, David Haller wrote:
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. <fx:moves mouse, try to select the id> 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 ;)
Yes, that's a nuisance, not having an editor that read those. Except the suse partition manager in YaST.
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.
Again: pure luck. Meaning: you are lucky. Me, my computer changes the names on each boot depending on which external drives are powered up.
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?
Exactly. I take care to change to verbose as soon as I can. What use are progress bars for, when you can watch a cute verbose logging text? >:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuc7fsACgkQtTMYHG2NR9Wb9gCeISkitm3axZnCdsozR9BpvzW+ IPEAn3EqZT4TjoCsrdL559335PJ27aPZ =eO2W -----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 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
Philipp Thomas wrote:
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.
Because they're most focused on the goal, less so on the process? /Per -- Per Jessen, Zürich (4.2°C) -- 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
Per Jessen wrote:
Philipp Thomas wrote:
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.
Because they're most focused on the goal, less so on the process?
/Per
Very astute. 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. I have occasionally written that into scripts in fact. For some big batch jobs I'll have a little step at the beginning that just counts all the things that the job is about to do, so that it can print a little progress thingy as part of it's output at every step showing percent-done. It's not just pretty. It's useful for estimating how long something will take before it's done. That can be really important some times. I may be able to think of several ways to handle some emergency, but often the best way takes the longest, and often I don't know for a one-off emergency measure how long it will take, but if I have it displaying percent complete along the way, I WILL know within a minute if it will take too long and I should abort it and do one of the other solutions instead. It's also good for regular non-emergency jobs, especially if they are big, so that when someone occasionally has to run it manually instead of from cron, it's less frustrating waiting for even a big 1/2 hour job if you can see or deduce a reasonable estimated finish time instead of just "I don't know it's been chugging for 10 minutes already, will it run forever? is it done in 2 more seconds..??? do I go to lunch and let this run? do I sit here and wait 5 minutes and get the result back to my boss an hour or a day earlier than if I left? Do I abort it and restart it before going home because it's tying up records and screwing up everyone else in the company until it's done???" Having some kind of clue for percent-complete is not just an anal pointy-haired-boss thing because they just like it because they're just like that. As for simply booting a box.. it really doesn't matter either way. I want to see boot messages only when diagnosing a problem or setting up a new box for the first time. The rest of the time I don't need 'em. Being able to hit a key to see them on-demand once in a while when needed is good enough. Conversely, they might as well display all the time because it's just booting. Over & done with in a few seconds even if you don't know what they mean and never read them. (And in my case, where all my opensuse boxes are servers, Either no one sees the box boot at all, or they are watching it via serial console where they want the text and it must be specifically non-graphical text) I allow my personal non-server boxes (couple netbooks/laptop/couple desktops), all ubuntu, to do their default graphical boots. The way ubuntu does it is actually the worst of both worlds. They hide the info of the text output from the rc scripts, but they don't even supply a progress bar in it's place. Instead it's just what they call a throbber, a looping animation. That is a busy-indicator, but not a progress or percent-complete indicator. -- bkw -- 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
* 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 :( Philipp -- 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
* 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. Philipp -- 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
On Tue, 16 Mar 2010 13:52:00 +0000, Dave Howorth <dhoworth@mrc-lmb.cam.ac.uk> wrote:
That's a shame; I'd say thanks otherwise :)
As you can see above, thaare in order :) Philipp -- 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 <dhoworth@mrc-lmb.cam.ac.uk> 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
* Philipp Thomas <pth@suse.de> [03-16-10 08:34]:
* 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 :(
in your ~/.muttrc: set attribution="* %n <%a> [%(%m-%d-%y %H:%M)]:" # how to attribute replies ain't mutt wunderful :^) -- 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
* 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 2010/03/16 18:23 (GMT+0100) Philipp Thomas composed:
* Patrick Shanahan (p a k a at opens...) [20100316 15:14]:
ain't mutt wunderful :^)
Yepp, though I prefer
set attribution='* %n (%a) [%(%y%m%d %H:%M)]:'
as you can see :)
Shameful that you think archives should be offering up email addresses to spammers, or that everyone should think your time zone is the only. 15:14 EDT is a whole different day in AU. BTW, you're typing anyway, so, assuming you can't copy & paste 1/4 line, very no big deal to type 10h or so extra characters you see right there in front of you if using a MUA that isn't so configurable. -- "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 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
On 2010/03/16 17:39 (GMT-0500) Rajko M. composed:
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 :)
Just one of tens of thousands of newsgroup and mailing list admins. 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. -- "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
* Felix Miata <mrmazda@earthlink.net> [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 <mrmazda@earthlink.net> * Felix Miata <mrmazda@earthlink.net> [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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkugMNoACgkQtTMYHG2NR9WijgCeNX5z2Cp6F9CyIjuYk5cfM8Y/ mgkAn16hEZL2oSq5RmCb3yO4cbI9Ew0u =5AYA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Carlos E. R. <robin.listas@telefonica.net> [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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-03-17 02:44, Patrick Shanahan wrote:
* 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.
Our archive is not the only one. - -- 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/ iF4EAREIAAYFAkug7NkACgkQja8UbcUWM1yFpwD9FDaG6VfrA4lP8wF5MytYx4dG ZODiCYkO+UY2/dYrQdUA/2+6uEIKOnqvQNNm/jAya9YueVfsdHpprzfe+Ct2YlsO =DaYS -----END PGP SIGNATURE----- -- 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 Wed, 2010-03-17 at 10:45 +0000, Dave Howorth wrote:
Henne is again one step ahead :) Unfortunately Henne is not the only one who publishes archives of this
Rajko M. wrote: list and others are not so careful. But I don't care anyway ...
+1 I don't care. E-Mail hiding is stupid and pointless. awilliam@whitemice.org awilliam@whitemiceconsulting.com awilliam@opengroupware.us awilliam@wmmi.net awilliam@whitemice.org awilliam@whitemiceconsulting.com awilliam@opengroupware.us awilliam@wmmi.net awilliam@whitemice.org awilliam@whitemiceconsulting.com awilliam@opengroupware.us awilliam@wmmi.net awilliam@whitemice.org awilliam@whitemiceconsulting.com awilliam@opengroupware.us awilliam@wmmi.net And I won't get any more or less SPAM than I did before. People who believe in e-mail hiding need to do some research into how all this actually works - you are making a PITA for yourself and others who legitimately want to communicate with you - and accomplishing nothing measurable. But if it makes you feel better - obfuscate away! -- Adam Tauno Williams <awilliam@whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba -- 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
On Tue, 16 Mar, 2010 at 18:23:12 +0100, 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 :)
...should have noticed Patrick's post, though I'll consider myself excused since neither of you changed the subj: ;) <returns to lurk mode> -- YMMV -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-03-14 at 16:39 +0100, Philipp Thomas wrote:
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.
Yeah. Details are for the technician lowly masses >:-p user: My computer is stuck. help desk: What do you see? user: Just a frozen progess bar. help desk: (crumbs) Er... reset the machine and call back if it doesn't work. {crossed fingers on the back} - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkudFV0ACgkQtTMYHG2NR9U8/QCfWfGtGrbS3PtMCAACCaTqO8OF TpwAnRlNPHFsb93j09KqEMYmD2D5UtqU =Ke15 -----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-03-12 19:25, C wrote:
OK, I'm really going around in circles here, and I'm just getting confused by it all... maybe someone here could clear the mud for me? Hang in there with me... this is a bit hard to explain :-P
My main computer has five SATA hard drives, one SATA DVD drive, and zero PATA drives.
The drives are all physically connected to the motherboard SATA controller (no extra controller card etc):
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? :-)
openSUSE 11.2 is mounting the drives by ID, and this always works fine. The order openSUSE sees the drives (using fdisk -l) on /dev is different than the physical connect order:
/dev/sda = SATA2 /dev/sdb = SATA3 /dev/sdc = SATA4 /dev/sdd = SATA0 /dev/sde = SATA1
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.
Now here is where it gets weird.
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:
/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
This causes me all sorts of problems.. including a complete failure to boot with an error about no valid root device - which is what led me to start poking into this drive stuff.
Next I installed Ubuntu 9.10 on the 5th partition of SATA0. Grub from Ubuntu is set to boot (hd3,5). hd3? Where did that come from? Ubuntu boots fine with this Grub line.... but... how? The SATA0 drive is not hd3 in any way I understand it could be. As well, it picked up openSUSE at (hd3,6), and Windows at (hd2,1)..... yet when I do an fdisk -l it shows the exact same info as openSUSE.
The names grub sees are listed in /boot/grub/device.map. I tried to change the mapping to reflect what I thought correct, looking at the bios and the cables - and then the system would not boot correctly.
So.. with all this conflicting information.. it's making it really hard for me to figure out what Grub in openSUSE should be set to (since I want to use the openSUSE boot menu for all of the installed OSes). Each install thinks the drives are different in some way.. which is making life... difficult to say the least. Why is SATA0 attached to /dev/sdd? Why not /dev/sda? (minor issue since I'm using mount by id, but still... doesn't make sense) Why is one Linux seeing SATA0 as /dev/sdd and the other seeing it as /dev/hdc? Why would Grub in openSUSE see SATA0 as hd0 (which makes sense to me) and Grub in Ubuntu see that same drive as hd3 (which makes no sense at all to me)?
Does anyone have any hints or clues for me here?
My current method is to install each grub to its own boot partition, and have a generic mbr code. This means that the grub that will boot is the one on a primary partition marked bootable. Then each grub's configuration can change the bootable marking of a partition. Of course, you can only have three. Perhaps four, installing a grub in the extended. This entry loads another grub menu.lst file, but the first one remains in control: title another -- (via configfile in /dev/sda1) root (hd0,0) configfile /boot/grub/menu.lst This one changes the active partition and boots the grub code there. Also, on next reboot, the main grub will be that one, so it has to have a corresponding entry to revert things: title another -- via chainload - changes active boot to /dev/sda1 rootnoverify (hd0,0) makeactive chainloader +1 Then you can have entries booting the kernel from another partition, booting another system, acording to the naming in the first one. This method allows each installation to control its own boot code. 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. - -- 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/ iF4EAREIAAYFAkuan5UACgkQja8UbcUWM1wYiwD9HG3k5xFZlrwwzhFlmiuCLPSu xR7RMhhNIkydcVI0bWMA+wQ5AK99AUwCg6Sr7QpuarULMRImUevNsk0R5aHjUrjL =J6f7 -----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 21:09, Carlos E. R. <robin.listas@telefonica.net> 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 Saturday, 2010-03-13 at 12:10 +0100, C wrote:
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 :-)
Ah, yes. Makes sense :-) Mine are not labeled, or I can't see the labels. I figured them out by unpluging one by one. Then, I wrote labels on the metal sheet nearby and the cables.
/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.
I think it is similar to what I have. I made photos or the bios screens (American megatrends), to aid me. It says it has an "on board e-sata controller", set to mode "ide" (the exact text on the bios display says: "Raid mode: ide"). There is an "extra raid/ide controller", also on mode "ide". And there is an "on-chip sata controller", also mode "ide". The modes can be ide, raid or ahci. I think I should use ahci, but if I do, the drives dissapear even from the bios and the board does not boot. If I set all to pci, then the bios lists sata1 to sata6, then ide primary master and slave (not plugged), then sata7 and 8, and finally, e-sata1 and 2. They only work if set to "ide". Go figure. And correspondingly, linux (oS 11.2) does not load sata drivers: lsmod: ide_pci_generic 5484 0 ide_core 148064 1 ide_pci_generic ata_generic 6508 0 pata_jmicron 4552 0 However, I get features like hopluging drives, which I use. Using lspci, I see: 00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller 00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller 04:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 04:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 05:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 05:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03)
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
Good luck :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkubewYACgkQtTMYHG2NR9XIhQCeMlB+OKOLswJMXosA+kjkYqs3 MYcAnjOgLsWvpvpJnFdDncL4FfTpDt1A =ox5v -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010/03/12 19:25 (GMT+0100) C composed:
Does anyone have any hints or clues for me here?
You have a complex configuration. Few answers will be simple. I certainly don't have them all, but hopefully here's some help: *buntu 9.10 uses Grub 2. No version of openSUSE uses that yet, although it is an option in Factory. Grub 2 (actually 1.9x) is more complex, and possesses some significant differences from Grub 1 used by openSUSE. hd3 has different meanings to the kernel, to Grub 1, and to Grub 2. What hd3 means to Grub 1 depends on the content of /boot/grub/device.map. Grub 1 counts from 0, while Grub 2 counts from 1. More differences than that I won't get into. Grub 1 is good enough for me that I haven't yet been compelled to learn Grub 2. A modern PC BIOS has several settings options that affect which HD gets priority. Commonly there's one to assign two SATA ports to a separate group from four other SATA ports, and an ability to switch the priority between the two groups, as in earlier BIOS with both SATA and PATA support. Also whether AHCI, by whatever name the BIOS assigns it, is enabled, affects which devices can have priority, priority which won't necessarily agree with what either Grub or the kernel thinks. On top of those and any other normal BIOS settings, most have a boot time menu option to boot from, which IOW means assign top priority regardless of other settings. The results possible from this matrix for any particular BIOS can only be learned through trial and error. In your case of using so many devices, you probably need to spend some time experimenting and documenting the possibilities. The foregoing is why device names for boot and mount purposes have had to be deprecated, replaced by UUID, label, path and ID as optional ways around the problems of unstable and unpredictable device priority. I suggest attempting to master either or both Grubs, create a boot partition as host for one Grub and a master Grub menu, but once initially configured, never mount that personal boot partition as /boot. It'll be up to you to maintain it with configfile and/or chainloader stanzas for your various distros, and if you want, graft in stanzas from your various distros' boot menus. Each distro in turn should have its own Grub installed to its / (or to a separate /boot dedicated to use exclusively by that installation if you want). Once you have Grub configured suitably, there should be no reason either to change BIOS settings, or use the BIOS boot menu. Each distro can be allowed to do whatever it pleases with whatever interpretation of BIOS priorities it perceives, and boot and mount by UUID, device name, or whatever it deems best. The main thing you need to do with each is ensure it does nothing with any HD's MBR, or with _your_ special Grub host/boot partition. If you don't, each will assume it's job is to hijack everything related to booting anything, and your's is far too complex to let that can of worms be opened. FWIW, I mount both realboot and non-booted distros' / partitions in a tree called /disks, in subdirs named ./hd[1-x]/, to directories with descriptive names, such as boot, suse112, fedora12, mdv2010, kubuntu, etc. I also label each partition, usually the same as the dirs used in /disks/hd[1-x]/, and use the labels for manual mounting & unmounting, and fstab entries. UUIDs were not made for human manipulation. :-p I also do all partitioning and formatting prior to beginning any Linux installation, and only _use_ "existing" partitions from within any distro's installation program. There's yet another option that can be used instead of a personally maintained custom boot partition - use Windows as primary bootloader. A basic HOWTO is on http://fm.no-ip.com/install-doz-after.html but I don't recommend using that method on so complex a system as yours unless you actually install Windows to a logical and keep only its boot files on its C: primary. Otherwise, Windows could turn your ability to boot anything else into a mess you wouldn't want to think about. ;-) The nice thing about this method though is configuration menu access is available from anything you can get to boot, including a 25 year old DOS floppy disk (as long as C: is the first partition on the first BIOS HD). :-) -- "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
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:
/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. This causes me all sorts of problems.. including a complete failure to boot with an error about no valid root device - which is what led me to start poking into this drive stuff.
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. And to the best of my knowledge there is no /dev/hdx interface in linux for controllers in AHCI mode. There is for some of the other modes which attempt to export your new SATA drives out via older legacy interfaces. Fixing this is just the first step, but I suggest you go ahead and fix it first, then try to resolve the other issues you have. Greg -- 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
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. There _are_ good reasons not to use AHCI. And there are good reasons to use it. YMMV. As I've implicated: I've used the non-AHCI mode on the three year old "new box" (sata_nv + sata_sil) until the MoBo broke. Three years ago _is_ three years ago though, and I just didn't have the time to test the switch to AHCI under 10.2/11.1/11.2 before that mobo-change. But now, with the HW change and 11.2, I thought, heck, just let's try it. So, now, I use ahci for the AMD/ATI onboard chip and sata_sil as before for the offboard controller. And well, it just works just like it did (with /dev/sda being what it was, the HDD switch was a bit later). Mind you: on the old box, I use 2.4.x and the old legacy IDE drivers (i.e. not even pata_* but the real old generic IDE non-libata stuff). I also use the OSS sound drivers, never got Alsa working ok with that ISA soundcard I got, even though Alsa's supposed to support it and I think I got some noise out of it using Alsa under some SUSE 8.x-10.1 or so, but not reliably. Probably because even isapnp/pnpdump see nothing of that card. So I stick with OSS. -dnh -- Me: "This message in the Messages and Codes Manual says that I should consult my systems programmer." IBMer: "Yes. What's wrong with that?" Me: "I _am_ my systems programmer." -- Mike A. -- 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
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)
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 ...
I'm just pointing out that not everybody can use ahci, or that not all boards implement things correctly. Whatever.
ACK. -dnh -- Listen, three eyes, don't you try to outweird me. I get stranger things than you free with my breakfast cereal. -- Zaphod Beeblebrox -- 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
Hello, On Mon, 15 Mar 2010, Carlos E. R. wrote:
On Sunday, 2010-03-14 at 06:16 +0100, David Haller wrote:
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:
I followed up there.
Board is MSI P45 Diamond, (dmidecode says: MS-7516). Bios is "American Megatrends Inc.", which I assume is "AMI", V1.5, 10/10/2008.
Ah.
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.
Weird. It shouldn't, as IDE-mode does not support connect/reconnect, maybe your board cheats :))
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. Without NCQ it might be: process1: get sector 600 process2: get sector 160000 process1: get sector 601 process2: get sector 160001 ... With NCQ, the disk can change that to process1: get sector 600 process1: get sector 601 ... process2: get sector 160000 process2: get sector 160001 ... You get the gist? More here: http://en.wikipedia.org/wiki/NCQ HTH, -dnh -- "Any setuid root program that does an exec() somewhere is just a less user friendly version of su." -- Olaf Kirch on bugtraq 2000-08-07 -- 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
On Fri, Mar 12, 2010 at 7:10 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----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 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. Tejun Heo is a Novell employee and one of the core ATA developers for mainline, so if it was me I'd assign the bug to him when I created it. <tj at kernel.org> If he doesn't want to treat it as a regression, he can always change the priority as he sees fit. Greg -- 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: <alpine.LSU.2.00.1003150112040.16913@nimrodel.valinor> 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-----
On 2010/03/14 01:24 (GMT+0100) Carlos E. R. composed:
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.
I change to AHCI mode:
This are the possibilities the bios offers:
And finally, this is what the bios says it sees with the three interfaces in AHCI mode. ¡All hard disks have disapeared!
Now, what?
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? -- "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
-----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
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 need the machine to boot from HD
What's the difference if you can boot from USB instead to (possibly) achieve better performance? -- "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
-----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
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.
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. -- "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
-----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
Hello, On Mon, 15 Mar 2010, Carlos E. R. wrote:
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. :-/
*ouch*
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?
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, 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). 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). You just need to add 'ahci' into your initrd before that so that you can actually boot if above is similar with your BIOS. Darn. Can't remember when I did add ahci to the initrd, but IIRC I switched to AHCI on first boot, so I must have added it before the mobo change. I think you can safely boot to grub / to where grub should apear, and then just press ctrl+alt+del to reboot (+ del/F2 after reboot) and reenter the BIOS. AFAIK you can actually switch drivers under linux without problems, I used sata_nv on the old mobo and use AHCI-mode/ahci-driver on the new mobo for a bunch of disks, without ill effects. It's just Windows that's (as usual) too stupid to switch drivers. So you you should not have to fear for your data switching to AHCI (only eSATA at first should work, but you might need a disk there). HTH, -dnh -- Vala: Thank you. I apologize for ever doubting [Mitchells] masterful skills at negotiation. Daniel: He's doing the best he can. Vala: That's what terrifies me. -- Stargate SG-1, 9x05 - The Powers That Be -- 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
On Sun, Mar 14, 2010 at 8:24 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.00.1003150112040.16913@nimrodel.valinor>
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!
Bizarre. Looks like a bios bug to me. If you care enough you could check for bios updates. Greg -- 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 2010/03/12 17:37 (GMT-0500) Greg Freemyer composed:
You must not have your MB controller set to use AHCI. You control that via you bios settings.
Not infrequently easier said than done. Not all BIOS offer the term "AHCI" among selectable ATA controller modes. Often the only choices are enhanced and compatible. Enhanced may or may not actually be fully or even partially AHCI compliant. -- "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 Fri, Mar 12, 2010 at 23:37, Greg Freemyer <greg.freemyer@gmail.com> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2010-03-13 at 12:57 +0100, C wrote:
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.
Lucky you :-)
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 :-)
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. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkubjMEACgkQtTMYHG2NR9V9cwCgghjnpaG5yo5PMcdC2/FV3uxP DG4An0RVHlV1AOV2pSH9El+Vbj/2Vrr4 =6w30 -----END PGP SIGNATURE-----
On Sat, Mar 13, 2010 at 14:01, Carlos E. R. <robin.listas@telefonica.net> 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 Sat, 13 Mar 2010 14:11:21 +0100, you 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. Philipp -- 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 <Philipp.Thomas2@gmx.net> 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
Hello, On Sat, 13 Mar 2010, C wrote:
:-) 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.
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). -dnh -- Q: "Excession is particularly popular because of its copious detail concerning the Ships and Minds of the Culture, its great AIs: their outrageous names, their dangerous senses of humour. Is this what gods would actually be like?" A: "If we're lucky." -- Iain M. Banks -- 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 <dnh@opensuse.org> 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 Sat, Mar 13, 2010 at 6:57 AM, C <smaug42@gmail.com> wrote:
Does setting to use AHCI do anything for drive access speeds?
AHCI is the most functional of the typical controller modes. (Marvell has it's own highly functional modes, but in general Marvell is less common and does not support AHCI I don't believe.) If you have a heavy disk i/o load it should also be faster, because linux knows it is talking to a sata drive and can have the drive do things a traditional IDE drive can't. Also, since AHCI is a Intel defined interface, you have a team of Intel engineers supporting the driver and optimizing its performance. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Fri, 12 Mar 2010, C wrote:
The drives are all physically connected to the motherboard SATA controller (no extra controller card etc):
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)
How did you get to these names? Do they correspond to the labels on the motherboard?
openSUSE 11.2 is mounting the drives by ID, and this always works fine. The order openSUSE sees the drives (using fdisk -l) on /dev is different than the physical connect order:
/dev/sda = SATA2 /dev/sdb = SATA3 /dev/sdc = SATA4 /dev/sdd = SATA0 /dev/sde = SATA1
Please show the output of lspci. Many motherboards with more than 4 SATA-Ports have 2 onboard-controllers! And please also show the output of: dmidecode | grep 'Product: '
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.
Now here is where it gets weird.
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:
/dev/sda = SATA2 /dev/sdb = SATA3 /dev/sdc = SATA4 /dev/hdc = SATA0 /dev/hdd = SATA1
And here you seem to use the one with SATA{0,1} with a PATA driver. Please compare the outputs of lsmod on both distributions.
Next I installed Ubuntu 9.10 on the 5th partition of SATA0. Grub from Ubuntu is set to boot (hd3,5). hd3? Where did that come from?
Grub's devices are mapped to devices of the system that you install grub from. Please show the /boot/grub/device.map of both systems. And tell us what grub you want where to boot what.
Ubuntu boots fine with this Grub line.... but... how? The SATA0 drive is not hd3 in any way I understand it could be. As well, it picked up openSUSE at (hd3,6), and Windows at (hd2,1)..... yet when I do an fdisk -l it shows the exact same info as openSUSE.
It's all a matter of how devices are mapped to grub's devices.
So.. with all this conflicting information.. it's making it really hard for me to figure out what Grub in openSUSE should be set to (since I want to use the openSUSE boot menu for all of the installed OSes).
If you use just one grub in the MBR, e.g. openSUSEs, you need to use the grub-devices from the device.map of the openSUSE grub. As root= kernel-parameter though, you have to use the one as seen from e.g. Ubuntu to boot Ubuntu.
Each install thinks the drives are different in some way.. which is making life... difficult to say the least. Why is SATA0 attached to /dev/sdd?
It's on the first port of the second controller initialized. You can adjust that by having only the driver for the controller on which the boot-partition (the partition containing /boot) resides.
Why not /dev/sda? (minor issue since I'm using mount by id, but still... doesn't make sense) Why is one Linux seeing SATA0 as /dev/sdd and the other seeing it as /dev/hdc?
See above. It depends on which driver is used.
Why would Grub in openSUSE see SATA0 as hd0 (which makes sense to me) and Grub in Ubuntu see that same drive as hd3 (which makes no sense at all to me)?
Ubuntu doesn't see the drive as hd3. Its grub may seems to. And what that maps to depends on it's device.map.
Does anyone have any hints or clues for me here?
info grub ;P -dnh -- Information moves, or we move to it. Moving to it has rarely been popular and is growing unfashionable; nowadays we demand that the information come to us. -- Neal Stephenson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 13 Mar 2010 00:19:09 David Haller wrote:
Hello,
On Fri, 12 Mar 2010, C wrote:
The drives are all physically connected to the motherboard SATA controller (no extra controller card etc):
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)
How did you get to these names? Do they correspond to the labels on the motherboard?
openSUSE 11.2 is mounting the drives by ID, and this always works fine. The order openSUSE sees the drives (using fdisk -l) on /dev is different than the physical connect order:
/dev/sda = SATA2 /dev/sdb = SATA3 /dev/sdc = SATA4 /dev/sdd = SATA0 /dev/sde = SATA1
Please show the output of lspci. Many motherboards with more than 4 SATA-Ports have 2 onboard-controllers!
And please also show the output of: dmidecode | grep 'Product: '
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.
Now here is where it gets weird.
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:
/dev/sda = SATA2 /dev/sdb = SATA3 /dev/sdc = SATA4 /dev/hdc = SATA0 /dev/hdd = SATA1
And here you seem to use the one with SATA{0,1} with a PATA driver.
Please compare the outputs of lsmod on both distributions.
Next I installed Ubuntu 9.10 on the 5th partition of SATA0. Grub from Ubuntu is set to boot (hd3,5). hd3? Where did that come from?
Grub's devices are mapped to devices of the system that you install grub from. Please show the /boot/grub/device.map of both systems. And tell us what grub you want where to boot what.
Ubuntu boots fine with this Grub line.... but... how? The SATA0 drive is not hd3 in any way I understand it could be. As well, it picked up openSUSE at (hd3,6), and Windows at (hd2,1)..... yet when I do an fdisk -l it shows the exact same info as openSUSE.
It's all a matter of how devices are mapped to grub's devices.
So.. with all this conflicting information.. it's making it really hard for me to figure out what Grub in openSUSE should be set to (since I want to use the openSUSE boot menu for all of the installed OSes).
If you use just one grub in the MBR, e.g. openSUSEs, you need to use the grub-devices from the device.map of the openSUSE grub. As root= kernel-parameter though, you have to use the one as seen from e.g. Ubuntu to boot Ubuntu.
Each install thinks the drives are different in some way.. which is making life... difficult to say the least. Why is SATA0 attached to /dev/sdd?
It's on the first port of the second controller initialized. You can adjust that by having only the driver for the controller on which the boot-partition (the partition containing /boot) resides.
Why not /dev/sda? (minor issue since I'm using mount by id, but still... doesn't make sense) Why is one Linux seeing SATA0 as /dev/sdd and the other seeing it as /dev/hdc?
See above. It depends on which driver is used.
Why would Grub in openSUSE see SATA0 as hd0 (which makes sense to me) and Grub in Ubuntu see that same drive as hd3 (which makes no sense at all to me)?
Ubuntu doesn't see the drive as hd3. Its grub may seems to. And what that maps to depends on it's device.map.
Does anyone have any hints or clues for me here?
info grub ;P
-dnh 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 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 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 this device by name thing can we please get rid of this deranged 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 nicley We would not have this continual hassle with devices getting strange mappings from one distro to another that makes NO SENSE at all we are all supposed to be Linux so lets get everything talking correctly this we are going to do it this way because they have done another way is crap yes CRAP and dont come the innovation line cus that sucks that big it's unreal , Every distro should see a collection of drives in a computer the same way not each to their own 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 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 . 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" 06:55 up 48 days 21:38, 3 users, load average: 0.03, 0.08, 0.02
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 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.
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.
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.
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?
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.
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 -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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.
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"? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuc8EEACgkQtTMYHG2NR9WyAwCfVYTor5k0d3V1Fr7HwreuUBEk lKoAmQGWhitP5TIfD3uxCJRF3585FKsD =GUnO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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
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=<some_usb_device> 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]. -dnh -- It took us fifteen years and three supercomputers to MacGyver a way to power the gate. -- Samantha Carter, Stargate -- 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: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=<some_usb_device> 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
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. /Per -- Per Jessen, Zürich (7.2°C) -- 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
Carlos E. R. wrote:
-----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.
Okay, got it. Yes, in that situation, only mount-by-id or -by-label works. Personally I prefer labels, they allow me to move a system without updating the configuration (except for running lilo). /Per -- Per Jessen, Zürich (0.9°C) -- 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
On Sun, 14 Mar 2010 12:40:36 +0000, you wrote:
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
No, parallel interfaces are a thing of the past as preventing crosstalk at current and future transfer speeds would make the technology far too costly. Guess why almost all current interface technologies (e.g. PCIe, SATA, SSA) are serial in nature?
if they are stable why are there so many complaints about names and allocations that change
You seem to misunderstand on purpose! The names the kernel assigns to devices are dynamic. Things like /dev/disk/by-id help at linking these dynamic names to stable ones that are constructed from internal device names and partition numbers.
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 now tell me how software can read the print on your motherboard. And no, the way normal realmode BIOSes enumerate disks is not something you want to depend on blindly as nothing in the world guarantees you that it matches the print on your mobo.
And Guess what they have been proved correct time and time again
This is so wrong that it's really funny.
but a small minority choose to ignore a majority so cus i aint afraid of any of you i speak up
But you still choose the wrong place for your soapbox so for me it's EOD from here onwards. Philipp -- 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
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. Philipp -- 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
Hello, 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. BTW: I have '(hd0) /dev/sda' in my device.map, and it worked over a mobo- and later hdd-switch, as described elsewhere. -dnh -- "Does anyone else sense the deep irony in a 'Family size' pack of condoms?" -- 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
Why would Grub in openSUSE see SATA0 as hd0 (which makes sense to me) and Grub in Ubuntu see that same drive as hd3 (which makes no sense at all to me)?
Ubuntu doesn't see the drive as hd3. Its grub may seems to. And what that maps to depends on it's device.map.
I've no idea whether it's relevant but Ubuntu 9.10 (karmic) uses grub2 Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (15)
-
Adam Tauno Williams -
Brian K. White -
C -
Carlos E. R. -
Dave Howorth -
David Haller -
Felix Miata -
Greg Freemyer -
Jon Clausen -
Patrick Shanahan -
Per Jessen -
Peter Nikolic -
Philipp Thomas -
Philipp Thomas -
Rajko M.