Re: ata controller problem
Gerhard Schmidt writes: > Labels are good for naming Drives but how does it help me if the root > filesystem changing device ids. I don't think the boot loader is able to > use the label for the root Filesystem. >From my fstab: /dev/ufs/Oak / ufs rw,noatime 1 1 /dev/label/OakSwap none swapsw 0 0 I think any of the other label schemes will also work. If you don't remember which label is which device id, then 'glabel status' will show that, but you shouldn't need to. -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem / AHCI numbering
On 2012.10.26 14:18, Gerhard Schmidt wrote: >> if there is a Drive in one of the HotSwap Bays the >> PCI-Express controller is detected as ahci0 and the onboard is detected >> as ahci1. >> So Far i could have set some devices.hints entries to sort the scsi >> busses. But the problem is that if there are no drives in the Bays the >> PCI-Expresscard is detected as ahci1 On 2012.10.27 10:22, Gerhard Schmidt wrote: > Am 26.10.2012 18:33, schrieb Jeremy Chadwick: >> The proper way to solve this problem is to user /boot/loader.conf >> tie-downs to assign each disk to each individual controllers' device >> number (e.g. ada0 --> scbus0 --> ahcich0, or whatever you want). Please >> note I said ahcichX, not ahciX. Different things. > Sorry this doesn't work because the numbering of the ahci change with > the occupancy of the Hot-Swap Bays. I'm surprised and curious about this... Don't all devices, including SATA/AHCI controllers, get probed and numbered in the order they are presented to a kernel ? What can cause that presentation order to vary when physical connections don't change ? How could even an intrusive x86 BIOS "feature" change that presentation order based on whether or not a disk is connected to a peripheral device ? Doesn't a BIOS stay ignorant of what is plugged into external controllers, which have their own boot ROM ? Certainly FreeBSD's kernel would not bother to reorder device numbers based on what is connected to them lower down the chain after it's discovered these "children", right ? (I'd be curious to take a look at your dmesg, Gerhard) I wish I could test this and figure it out on my own, but I don't have the right hardware available to replicate it and VirtualBox only supports a single virtual SATA controller. Using two identical (crappy) ASMedia AHCI 6Gbps PCIe adapters, I wasn't able to get their ahci numbering reversed by plugging or unplugging disks from them before booting. But the mainboard's SATA controllers are driven by atapci instead of ahci, so it's not quite the same... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
Am 27.10.2012 10:39, schrieb Erich Dollansky: > Hi, > > On Sat, 27 Oct 2012 10:22:01 +0200 > Gerhard Schmidt wrote: > >>> hint.ada.3.at="scbus3" >>> hint.ada.4.at="scbus4" >>> hint.ada.5.at="scbus5" >>> >>> See CAM(4) man page (read it, don't skim!) for full details. Just >>> please for the love of god do not use labels to solve this. >>> >> Sorry this doesn't work because the numbering of the ahci change with >> the occupancy of the Hot-Swap Bays. >> >> And that is my Problem. This i have tried first. >> >> Any idea how i can fix which controller gets which number. >> > just you labels. Chose the labelling method which fits best your file > system. gpt seems to fit most scenarios. > > Labels came up to solve your problem. Can I mount the root filesystem via label. That's the problem here. Regard Estartu -- - Gerhard Schmidt | E-Mail und JabberID: TU-München| schm...@ze.tum.de WWW & Online Services | Tel: 089/289-25270| Fax: 089/289-25257| PGP-Publickey auf Anfrage signature.asc Description: OpenPGP digital signature
Re: ata controller problem
Hi, On Sat, 27 Oct 2012 10:25:41 +0200 Gerhard Schmidt wrote: > On 26.10.2012 18:00, Polytropon wrote: => > I'm not sure if this can be done, but using labels should > > make the question go away, and the problem causing it. :-) > > Labels are good for naming Drives but how does it help me if the root > filesystem changing device ids. I don't think the boot loader is able > to use the label for the root Filesystem. > put a root file system on all drives and make it bootable. I use this trick also. You do not need that much space there to get the system up compared to the size of current media. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
Hi, On Sat, 27 Oct 2012 10:22:01 +0200 Gerhard Schmidt wrote: > > hint.ada.3.at="scbus3" > > hint.ada.4.at="scbus4" > > hint.ada.5.at="scbus5" > > > > See CAM(4) man page (read it, don't skim!) for full details. Just > > please for the love of god do not use labels to solve this. > > > Sorry this doesn't work because the numbering of the ahci change with > the occupancy of the Hot-Swap Bays. > > And that is my Problem. This i have tried first. > > Any idea how i can fix which controller gets which number. > just you labels. Chose the labelling method which fits best your file system. gpt seems to fit most scenarios. Labels came up to solve your problem. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
On 26.10.2012 18:00, Polytropon wrote: > On Fri, 26 Oct 2012 14:18:16 +0200, Gerhard Schmidt wrote: >> The Problem is that, if there is a Drive in one of the HotSwap Bays the >> PCI-Express controller is detected as ahci0 and the onboard is detected >> as ahci1. Therefore any drives in the HotSwap Bays become ada0-3 and the >> drives on the mainboard controller are the upper numbers which causes >> the boot to fail as the Root Partition isn't there where it's expected. >> The BIOS has the PCI-Express Card as second Card only so the Kernel is >> Booted but the RootFS is not Found. > > You can use labels (GPT or UFS labels) or UFSIDs to become > independent of the actual device name where things are stored > on. You could also use this to make disks easier to identify > (e. g. "/dev/label/red1root" = the disk with a red "1" on it, > carrying the root file system). > > I suggest those pages for more detailed information: > > http://www.wonkity.com/~wblock/docs/html/disksetup.html > > http://www.freebsd.org/doc/handbook/geom-glabel.html > > Maybe as well (specific and general notes and inspiration): > > http://www.daemonforums.org/showthread.php?t=2666 > > http://www.freebsdonline.com/content/view/731/506/ > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html > > I assume that you are using UFS. > > > >> Is there a way to ensure that the onboard SATA Controller is always >> probed first. > > I'm not sure if this can be done, but using labels should > make the question go away, and the problem causing it. :-) Labels are good for naming Drives but how does it help me if the root filesystem changing device ids. I don't think the boot loader is able to use the label for the root Filesystem. Regards Estartu -- - Gerhard Schmidt | E-Mail und JabberID: TU-München| schm...@ze.tum.de WWW & Online Services | Tel: 089/289-25270| Fax: 089/289-25257| PGP-Publickey auf Anfrage ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
Am 26.10.2012 18:33, schrieb Jeremy Chadwick: > Regarding this: > > http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html > > No no NO *NO*! > > I wish people would stop recommending this utter garbage. There is > absolutely no justification behind using the highly convoluted labelling > mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) > different "label" mechanisms which do nothing but confuse the user, or > cause other oddities/complexities. Good grief, there is so much hard > evidence on the mailing lists over the past 5 (maybe even 7?) years > talking about the utter mess that is filesystem/device/geom/blahblah > labels that to recommend this is borderline insane. > > The proper way to solve this problem is to user /boot/loader.conf > tie-downs to assign each disk to each individual controllers' device > number (e.g. ada0 --> scbus0 --> ahcich0, or whatever you want). Please > note I said ahcichX, not ahciX. Different things. > > I have helped others in the past do this; Randy Bush is one such person. > > Taken directly from my /boot/loader.conf with a single SATA controller, > but obviously this can be adjusted to whatever you want. > > # "Wire down" device names (ada[0-5]) to each individual port > # on the SATA/AHCI controller. This ensures that if we reboot > # with a disk missing, the device names stay the same, and stay > # attached to the same SATA/AHCI controller. > # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html > # > hint.scbus.0.at="ahcich0" > hint.scbus.1.at="ahcich1" > hint.scbus.2.at="ahcich2" > hint.scbus.3.at="ahcich3" > hint.scbus.4.at="ahcich4" > hint.scbus.5.at="ahcich5" > hint.ada.0.at="scbus0" > hint.ada.1.at="scbus1" > hint.ada.2.at="scbus2" > hint.ada.3.at="scbus3" > hint.ada.4.at="scbus4" > hint.ada.5.at="scbus5" > > See CAM(4) man page (read it, don't skim!) for full details. Just > please for the love of god do not use labels to solve this. > Sorry this doesn't work because the numbering of the ahci change with the occupancy of the Hot-Swap Bays. And that is my Problem. This i have tried first. Any idea how i can fix which controller gets which number. Regard Estartu -- - Gerhard Schmidt | E-Mail und JabberID: TU-München| schm...@ze.tum.de WWW & Online Services | Tel: 089/289-25270| Fax: 089/289-25257| PGP-Publickey auf Anfrage ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
Hi, On Fri, 26 Oct 2012 09:33:38 -0700 Jeremy Chadwick wrote: > Regarding this: > > http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html > > No no NO *NO*! > YES, YES, YES, YES! > The proper way to solve this problem is to user /boot/loader.conf How does this help when media is moved between machines? Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
On Fri, 26 Oct 2012, Jeremy Chadwick wrote: Regarding this: http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html No no NO *NO*! I wish people would stop recommending this utter garbage. There is absolutely no justification behind using the highly convoluted labelling mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) different "label" mechanisms which do nothing but confuse the user, or cause other oddities/complexities. Good grief, there is so much hard evidence on the mailing lists over the past 5 (maybe even 7?) years talking about the utter mess that is filesystem/device/geom/blahblah labels that to recommend this is borderline insane. Hmm. Six months to April 1? Seriously, labels provide a simple, relocatable identification mechanism that works across machines. If someone finds them confusing, it can be cleared up easily: use GPT labels when possible, otherwise use filesystem labels or glabel. The proper way to solve this problem is to user /boot/loader.conf tie-downs to assign each disk to each individual controllers' device number (e.g. ada0 --> scbus0 --> ahcich0, or whatever you want). Please note I said ahcichX, not ahciX. Different things. Labels work on different machines or controllers without added configuration, and stay with the partition or filesystem. Your static config appears to not share those properties. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
On Fri, Oct 26, 2012 at 06:43:28PM +0200, Polytropon wrote: > > I wish people would stop recommending this utter garbage. There is > > absolutely no justification behind using the highly convoluted labelling > > mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) > > different "label" mechanisms which do nothing but confuse the user, or > > cause other oddities/complexities. Good grief, there is so much hard > > evidence on the mailing lists over the past 5 (maybe even 7?) years > > talking about the utter mess that is filesystem/device/geom/blahblah > > labels that to recommend this is borderline insane. > > Yes, the amount of different, present (in parallel) and > differently implemented and accessible labeling mechanisms > can be confusing. There is no "the one true way" to do it. > Especially when dealing with metadata (e. g. for rare cases > of data recovery) it might make things more complicated. > > I don't agree that labels in general "do nothing but confuse > the user" - the same could be said about controllers, devices > and how they are partitioned (again, many different ways here). > But users usually don't deal with that. Sysadmins do. And they > should be able to deal with it, as it's not _that_ complicated > (from their educated and experienced point of view, I assume). > > That's why I would still say labels have their place, especially > in settings with many disks (10 and more) where concluding > "which disk?" is sometimes required, in terms of disk, not > disk _bay_. Let me make myself extra clear here -- and I won't be replying past this point (privately or publicly): What the OP wanted was to have a static mapping between a physical SATA port (e.g. Card #1 Port #0) and a device name (e.g. ada0) -- one which never changes no matter if there's a disk attached to the port or not. The wire-down method described above does this. Using labels does not. Here's a list of the wonderful fun things labels offer: - You get to remember or write down the label; don't forget it - You get to change /etc/fstab - You get to pray you never have to replace a disk, and if you do, that you remember which labelling method you used, and/or deal with partitioning complexities (see last item) - You get to be subjected to bugs in the GEOM layer or UFS layer when it comes to labels (this has happened!) - If using GPT (the only present way to align a partition properly to a 1MByte boundary -- matters greatly for SSDs due to NAND erase page size!), you're subjected to the problem where GEOM stores its metadata in the last sector, which is also where GPT stores its backup table. This is even documented in the Handbook, which is both good *and* hilarious at the same time And don't forget about the automatic vs. manual GEOM label method (but for this case I'm assuming automatic is used, since that method stores metadata). Every one of these situations has happened to at least one person in the past 5 (7?) years. They CONTINUE to happen. It cannot be denied. We FreeBSD users way too often shove our fingers into our ears and yell "LALALA" when people point out shortcomings. Blind advocacy of any kind of technology these days is something to be wary of. All that said: labels have a very, very specific purpose, backed by a list of many caveats. But "I want to ensure controller port X maps to device X at all times" is not one of those purposes. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
On Fri, 26 Oct 2012 09:33:38 -0700, Jeremy Chadwick wrote: > Regarding this: > > http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html > > No no NO *NO*! No? :-) > I wish people would stop recommending this utter garbage. There is > absolutely no justification behind using the highly convoluted labelling > mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) > different "label" mechanisms which do nothing but confuse the user, or > cause other oddities/complexities. Good grief, there is so much hard > evidence on the mailing lists over the past 5 (maybe even 7?) years > talking about the utter mess that is filesystem/device/geom/blahblah > labels that to recommend this is borderline insane. Yes, the amount of different, present (in parallel) and differently implemented and accessible labeling mechanisms can be confusing. There is no "the one true way" to do it. Especially when dealing with metadata (e. g. for rare cases of data recovery) it might make things more complicated. I don't agree that labels in general "do nothing but confuse the user" - the same could be said about controllers, devices and how they are partitioned (again, many different ways here). But users usually don't deal with that. Sysadmins do. And they should be able to deal with it, as it's not _that_ complicated (from their educated and experienced point of view, I assume). That's why I would still say labels have their place, especially in settings with many disks (10 and more) where concluding "which disk?" is sometimes required, in terms of disk, not disk _bay_. > The proper way to solve this problem is to user /boot/loader.conf > tie-downs to assign each disk to each individual controllers' device > number (e.g. ada0 --> scbus0 --> ahcich0, or whatever you want). Please > note I said ahcichX, not ahciX. Different things. > > I have helped others in the past do this; Randy Bush is one such person. > > Taken directly from my /boot/loader.conf with a single SATA controller, > but obviously this can be adjusted to whatever you want. > > # "Wire down" device names (ada[0-5]) to each individual port > # on the SATA/AHCI controller. This ensures that if we reboot > # with a disk missing, the device names stay the same, and stay > # attached to the same SATA/AHCI controller. > # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html > # > hint.scbus.0.at="ahcich0" > hint.scbus.1.at="ahcich1" > hint.scbus.2.at="ahcich2" > hint.scbus.3.at="ahcich3" > hint.scbus.4.at="ahcich4" > hint.scbus.5.at="ahcich5" > hint.ada.0.at="scbus0" > hint.ada.1.at="scbus1" > hint.ada.2.at="scbus2" > hint.ada.3.at="scbus3" > hint.ada.4.at="scbus4" > hint.ada.5.at="scbus5" That's a very nice contribution to the topic - I hadn't thought it was that easy, and it actually solves the "who comes first" kind of problems. > See CAM(4) man page (read it, don't skim!) for full details. Just > please for the love of god do not use labels to solve this. Thanks, this contains inspiration of maybe how to make access to USB devices and memory card readers more efficient (i. e. making sure they are always represented by one and the same device, instead of "the next free one"). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
Regarding this: http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html No no NO *NO*! I wish people would stop recommending this utter garbage. There is absolutely no justification behind using the highly convoluted labelling mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) different "label" mechanisms which do nothing but confuse the user, or cause other oddities/complexities. Good grief, there is so much hard evidence on the mailing lists over the past 5 (maybe even 7?) years talking about the utter mess that is filesystem/device/geom/blahblah labels that to recommend this is borderline insane. The proper way to solve this problem is to user /boot/loader.conf tie-downs to assign each disk to each individual controllers' device number (e.g. ada0 --> scbus0 --> ahcich0, or whatever you want). Please note I said ahcichX, not ahciX. Different things. I have helped others in the past do this; Randy Bush is one such person. Taken directly from my /boot/loader.conf with a single SATA controller, but obviously this can be adjusted to whatever you want. # "Wire down" device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at="ahcich0" hint.scbus.1.at="ahcich1" hint.scbus.2.at="ahcich2" hint.scbus.3.at="ahcich3" hint.scbus.4.at="ahcich4" hint.scbus.5.at="ahcich5" hint.ada.0.at="scbus0" hint.ada.1.at="scbus1" hint.ada.2.at="scbus2" hint.ada.3.at="scbus3" hint.ada.4.at="scbus4" hint.ada.5.at="scbus5" See CAM(4) man page (read it, don't skim!) for full details. Just please for the love of god do not use labels to solve this. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ata controller problem
On Fri, 26 Oct 2012 14:18:16 +0200, Gerhard Schmidt wrote: > The Problem is that, if there is a Drive in one of the HotSwap Bays the > PCI-Express controller is detected as ahci0 and the onboard is detected > as ahci1. Therefore any drives in the HotSwap Bays become ada0-3 and the > drives on the mainboard controller are the upper numbers which causes > the boot to fail as the Root Partition isn't there where it's expected. > The BIOS has the PCI-Express Card as second Card only so the Kernel is > Booted but the RootFS is not Found. You can use labels (GPT or UFS labels) or UFSIDs to become independent of the actual device name where things are stored on. You could also use this to make disks easier to identify (e. g. "/dev/label/red1root" = the disk with a red "1" on it, carrying the root file system). I suggest those pages for more detailed information: http://www.wonkity.com/~wblock/docs/html/disksetup.html http://www.freebsd.org/doc/handbook/geom-glabel.html Maybe as well (specific and general notes and inspiration): http://www.daemonforums.org/showthread.php?t=2666 http://www.freebsdonline.com/content/view/731/506/ http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html I assume that you are using UFS. > Is there a way to ensure that the onboard SATA Controller is always > probed first. I'm not sure if this can be done, but using labels should make the question go away, and the problem causing it. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
