Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #205644 > unrolled thread

Swapping Drives - Sanity Check

Back to article view | Back to linux.debian.user

Contents

  Swapping Drives - Sanity Check "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-02-22 14:20 +0100
    Re: Swapping Drives - Sanity Check songbird <songbird@anthive.com> - 2019-02-22 15:20 +0100
      Re: Swapping Drives - Sanity Check David Christensen <dpchrist@holgerdanske.com> - 2019-02-23 09:00 +0100
        Re: Swapping Drives - Sanity Check songbird <songbird@anthive.com> - 2019-02-23 13:10 +0100
          Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-23 17:20 +0100
            Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 19:00 +0100
              Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-23 20:20 +0100
                Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 23:00 +0100
                Re: Swapping Drives - Sanity Check Felix Miata <mrmazda@earthlink.net> - 2019-02-23 23:40 +0100
                  Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-24 16:50 +0100
                    Re: Swapping Drives - Sanity Check Felix Miata <mrmazda@earthlink.net> - 2019-02-24 18:40 +0100
        Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 14:00 +0100
          Re: Swapping Drives - Sanity Check rhkramer@gmail.com - 2019-02-23 15:50 +0100
            Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 17:00 +0100
              Re: Swapping Drives - Sanity Check rhkramer@gmail.com - 2019-02-23 17:30 +0100
                Re: Swapping Drives - Sanity Check <tomas@tuxteam.de> - 2019-02-23 18:10 +0100
                  Re: Swapping Drives - Sanity Check mick crane <mick.crane@gmail.com> - 2019-02-23 22:00 +0100
                    Re: Swapping Drives - Sanity Check <tomas@tuxteam.de> - 2019-02-23 22:10 +0100
                Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 19:10 +0100
            Re: Swapping Drives - Sanity Check <tomas@tuxteam.de> - 2019-02-23 17:00 +0100
              Re: Swapping Drives - Sanity Check rhkramer@gmail.com - 2019-02-23 17:20 +0100
            Re: Swapping Drives - Sanity Check <tomas@tuxteam.de> - 2019-02-23 17:20 +0100
            Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-23 17:20 +0100
            Re: Swapping Drives - Sanity Check John Hasler <jhasler@newsguy.com> - 2019-02-23 18:00 +0100
          Re: Swapping Drives - Sanity Check David Christensen <dpchrist@holgerdanske.com> - 2019-02-23 23:20 +0100
            Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 23:40 +0100
    Re: Swapping Drives - Sanity Check Dan Ritter <dsr@randomstring.org> - 2019-02-22 15:20 +0100
      Re: Swapping Drives - Sanity Check "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-02-22 15:30 +0100
        Re: Swapping Drives - Sanity Check David Wright <deblis@lionunicorn.co.uk> - 2019-02-22 16:10 +0100
          Re: Swapping Drives - Sanity Check "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-02-22 17:40 +0100
            Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-22 20:20 +0100
            Re: Swapping Drives - Sanity Check Michael Stone <mstone@debian.org> - 2019-02-22 20:30 +0100
              Re: Swapping Drives - Sanity Check David Wright <deblis@lionunicorn.co.uk> - 2019-02-23 03:00 +0100
                Re: Swapping Drives - Sanity Check Jimmy Johnson <field.engineer@gmail.com> - 2019-02-23 09:00 +0100
                  Re: Swapping Drives - Sanity Check Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-23 09:40 +0100
            Re: Swapping Drives - Sanity Check Felix Miata <mrmazda@earthlink.net> - 2019-02-22 23:40 +0100

Page 1 of 2  [1] 2  Next page →

#205644 — Swapping Drives - Sanity Check

My Debian Stretch system has three HD's. I want to remove one of the 
HD's (not sda) and replace it with a new HD..

What I need to be sure of is, if I remove the old drive from the fstab 
and delete the mount point will the system boot after I put in the new 
HD. so that I can edit the fstab and create a mount point for the new 
drive?

Hence, the request for the sanity check.

Thanks in advance.

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

[toc] | [next] | [standalone]

#205646

Stephen P. Molnar wrote:

> My Debian Stretch system has three HD's. I want to remove one of the 
> HD's (not sda) and replace it with a new HD..
>
> What I need to be sure of is, if I remove the old drive from the fstab 
> and delete the mount point will the system boot after I put in the new 
> HD. so that I can edit the fstab and create a mount point for the new 
> drive?
>
> Hence, the request for the sanity check.

  as long as you don't have anything on the
current one that is being used by the system
it should be ok.

  for the short term, just to make sure you
don't have to track the stuff down again you
can just comment the lines out in the fstab
but leave them there until you are sure things
are ok.


  songbird

[toc] | [prev] | [next] | [standalone]

#205678

On 2/22/19 6:17 AM, songbird wrote:
> Stephen P. Molnar wrote:
>> My Debian Stretch system has three HD's. I want to remove one of the
>> HD's (not sda) and replace it with a new HD..
>>
>> What I need to be sure of is, if I remove the old drive from the fstab
>> and delete the mount point will the system boot after I put in the new
>> HD. so that I can edit the fstab and create a mount point for the new
>> drive?
>>
>> Hence, the request for the sanity check.
> 
>    as long as you don't have anything on the
> current one that is being used by the system
> it should be ok.

So long as the system and/or any programs are not using a drive, then 
you can remove that drive.


>    for the short term, just to make sure you
> don't have to track the stuff down again you
> can just comment the lines out in the fstab
> but leave them there until you are sure things
> are ok.

Leave the old drive installed, comment out its entry in fstab, leave the 
mount point intact, reboot, and test if everything still works.


If everything still works, then power down, remove the old drive, 
install the new drive, boot, and configure the new drive.


If something is broken, then you will need to trouble-shoot.


On 2/22/19 6:19 AM, Stephen P. Molnar wrote:
 > The OS is on dev/sda.  The disk I changing is /dev/sdc

As other readers have noted, device nodes for drives are unpredictable.


On 2/22/19 8:36 AM, Stephen P. Molnar wrote:
 > Here is my fstab:
 >
 > # /etc/fstab: static file system information.
 > #
 > # Use 'blkid' to print the universally unique identifier for a
 > # device; this may be used with UUID= as a more robust way to name 
devices
 > # that works even if disks are added and removed. See fstab(5).
 > #
 > # <file system> <mount point>   <type> <options>       <dump>  <pass>
 > # / was on /dev/sda1 during installation
 > UUID=ce25f0e1-610d-4030-ab47-129cd47d974e /               ext4
 > errors=remount-ro 0       1
 > # swap was on /dev/sda5 during installation
 > UUID=a8f6dc7e-13f1-4495-b68a-27886d386db0 none            swap
 > sw              0       0
 > /dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0 0
 >
 > UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 errors=remount-ro
 > 0       1
 >
 > UUID=d65867da-c658-4e35-928c-9dd2d6dd5742 /sdc1 ext4 errors=remount-ro
 > 0       1
 >
 > UUID=007c1f16-34a4-438c-9d15-e3df601649ba /sdc2 ext4 errors=remount-ro
 > 0       1

As other readers have noted, using UUID's for the fstab first field 
(fs_spec) is okay.  Newer Linux kernels offer more meaningful options, 
such as GPT labels and drive make/ model/ serial number (ID) strings.


As other readers have noted, using device node base names such as 
'/sdb1' for the fstab second field (fs_file) is confusing and could 
cause you to make a painful mistake.  I agree with the suggestions of 
using names based upon what the drive contains -- '/data', '/music', 
'/sneaker', etc..  I also physically mark my drives with the exact same 
name.


 > Before disconnection the power to the drives,

Understand that if you disconnect the power cable to a motherboard, 
drive, peripheral, etc., but not all the other cables (e.g. SATA cable), 
you can fry electronics.  If you're going to unplug something, 
completely unplug it.


 > I edited out their lines
 > in fstab. I disconnecting the power to sdb and sdc and started the
 > computer.  It booted for a few lines until it encountered the line
 > starting with 'start job fgfor device disk by . . .' (at least that what
 > i jotted down). then t\iot Then it through the three HD's, two of which
 > had the power unplugged) for 1 minute and 30 seconds and then went on to
 > tell me that I could log on as root or ctrl-D to continue.  Ctrl-D
 > didn't work so I logged oh as root

You need to capture exact error messages and type them exactly into your 
posts.  Use a digital camera, smart phone, tablet PC, etc..


 > At that point I did 'journalctl -xb and got 1237 lines which were
 > meaningless to me.

Take a bunch of pictures, then RTFM, STFW, and/or post here.


 > startx got me to the Root Desktop.

I avoid running X as root.


 > The only option open to me at that point was to logout as root, the
 > options of restart and shutdown were grayed out as being unavailable.
 >
 > At this point I admitted defeat did 'shutdown -h now' in a terminal and
 > put the system back in its original state.
 >
 > Obviously, I'm missing something!

Does the machine work now?

If so, follow my suggestion above "Leave the old drive installed...".


David

[toc] | [prev] | [next] | [standalone]

#205681

David Christensen wrote:
...
> On 2/22/19 6:19 AM, Stephen P. Molnar wrote:
> > The OS is on dev/sda.  The disk I changing is /dev/sdc
>
> As other readers have noted, device nodes for drives are unpredictable.

  i've hated UUIDs since they arrived so i've
always used LABELS instead.  for people with a simple
layout it makes so much more sense to use legible
and much shorter id's.


  songbird

[toc] | [prev] | [next] | [standalone]

#205697

On Sat, Feb 23, 2019 at 06:57:05AM -0500, songbird wrote:
>David Christensen wrote:
>...
>> On 2/22/19 6:19 AM, Stephen P. Molnar wrote:
>> > The OS is on dev/sda.  The disk I changing is /dev/sdc
>>
>> As other readers have noted, device nodes for drives are unpredictable.
>
>  i've hated UUIDs since they arrived so i've
>always used LABELS instead.  for people with a simple
>layout it makes so much more sense to use legible
>and much shorter id's.

I never use labels because if I want to attach a drive to another 
computer for some reason it's extremely common for the labels to 
collide. 

[toc] | [prev] | [next] | [standalone]

#205705

Le 23/02/2019 à 17:10, Michael Stone a écrit :
> On Sat, Feb 23, 2019 at 06:57:05AM -0500, songbird wrote:
>>
>>  i've hated UUIDs since they arrived so i've
>> always used LABELS instead.  for people with a simple
>> layout it makes so much more sense to use legible
>> and much shorter id's.
> 
> I never use labels because if I want to attach a drive to another 
> computer for some reason it's extremely common for the labels to collide.

Good point. Labels are not as unique as UUIDs. But you can choose labels 
which are unique enough to avoid collisions, for instance by including a 
substring which identifies the host system or the drive. See Felix's 
example above.

[toc] | [prev] | [next] | [standalone]

#205707

On Sat, Feb 23, 2019 at 06:51:12PM +0100, Pascal Hambourg wrote:
>Le 23/02/2019 à 17:10, Michael Stone a écrit :
>>On Sat, Feb 23, 2019 at 06:57:05AM -0500, songbird wrote:
>>>
>>> i've hated UUIDs since they arrived so i've
>>>always used LABELS instead.  for people with a simple
>>>layout it makes so much more sense to use legible
>>>and much shorter id's.
>>
>>I never use labels because if I want to attach a drive to another 
>>computer for some reason it's extremely common for the labels to 
>>collide.
>
>Good point. Labels are not as unique as UUIDs. But you can choose 
>labels which are unique enough to avoid collisions, for instance by 
>including a substring which identifies the host system or the drive. 
>See Felix's example above.

You can, but it isn't the default. UUIDs tend to just work to a greater 
extend. 

[toc] | [prev] | [next] | [standalone]

#205712

Le 23/02/2019 à 20:14, Michael Stone a écrit :
> On Sat, Feb 23, 2019 at 06:51:12PM +0100, Pascal Hambourg wrote:
>> Le 23/02/2019 à 17:10, Michael Stone a écrit :
>>>
>>> I never use labels because if I want to attach a drive to another 
>>> computer for some reason it's extremely common for the labels to 
>>> collide.
>>
>> Good point. Labels are not as unique as UUIDs. But you can choose 
>> labels which are unique enough to avoid collisions, for instance by 
>> including a substring which identifies the host system or the drive. 
>> See Felix's example above.
> 
> You can, but it isn't the default. UUIDs tend to just work to a greater 
> extend.

What default ?

[toc] | [prev] | [next] | [standalone]

#205714

Michael Stone composed on 2019-02-23 14:14 (UTC-0500):

> On Sat, Feb 23, 2019 at 18:51:12 +0100, Pascal Hambourg wrote:

>> Michael Stone composed:

>>>I never use labels because if I want to attach a drive to another 
>>>computer for some reason it's extremely common for the labels to 
>>>collide.

>>Good point. Labels are not as unique as UUIDs. But you can choose 
>>labels which are unique enough to avoid collisions, for instance by 
>>including a substring which identifies the host system or the drive. 
>>See Felix's example above.

> You can, but it isn't the default. UUIDs tend to just work to a greater 
> extend. 

Depends on context. In a fully automated context, UUIDs do indeed work great, when humans are
working with them, not so great. Most humans cannot remember 32 character or longer strings of
randomly generated characters for associating with devices or usage. Also they make fstab lines
much longer, tending to wrap when pasting into email or view in an 80 character terminal.

Almost exclusively, I've been using labels in fstabs and bootloader configs for more than 12 years.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#205733

On Sat, Feb 23, 2019 at 05:37:06PM -0500, Felix Miata wrote:
>Depends on context. In a fully automated context, UUIDs do indeed work great, when humans are
>working with them, not so great. Most humans cannot remember 32 character or longer strings of
>randomly generated characters for associating with devices or usage.

Yeah, thankfully copy & paste is also a feature. :)

[toc] | [prev] | [next] | [standalone]

#205735

Michael Stone composed on 2019-02-24 10:46 (UTC-0500):

> On Sat, Feb 23, 2019 at 05:37:06PM -0500, Felix Miata wrote:

>>Depends on context. In a fully automated context, UUIDs do indeed work great, when humans are
>>working with them, not so great. Most humans cannot remember 32 character or longer strings of
>>randomly generated characters for associating with devices or usage.

> Yeah, thankfully copy & paste is also a feature. :)

Sometimes the copy from location is accessible too. :)

I just cloned two logical partitions to and from the only HD in the system and used

	tune2fs -U random -L <label>

on the clones. No bootloader is installed on either source or clone partitions. X won't run
and gpm isn't installed. I want to adjust their fstabs now, and boot either subsequently
through a configfile menu entry on a filesystem that was neither source nor destination in
the cloning processes. What do I do next?
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#205683

Le 23/02/2019 à 08:53, David Christensen a écrit :
> 
> As other readers have noted, using UUID's for the fstab first field 
> (fs_spec) is okay.  Newer Linux kernels offer more meaningful options, 
> such as GPT labels and drive make/ model/ serial number (ID) strings.

AFAIK, these options have nothing to do with the kernel. They are 
provided by libblkid. The only related option added to "newer" (it was 
3.x so not really new) kernels is the ability to specifiy the root 
filesystem by PARTUUID instead of device node name or major:minor 
numbers when not using an initrd or initramfs to mount the root filesystem.

> Understand that if you disconnect the power cable to a motherboard, 
> drive, peripheral, etc., but not all the other cables (e.g. SATA cable), 
> you can fry electronics.

Right. This is why power pins are longer than data pins in plug&play 
connectors, so that they are connected first and disconnected last.

[toc] | [prev] | [next] | [standalone]

#205685

On Saturday, February 23, 2019 07:53:23 AM Pascal Hambourg wrote:
> Le 23/02/2019 à 08:53, David Christensen a écrit :
> > Understand that if you disconnect the power cable to a motherboard,
> > drive, peripheral, etc., but not all the other cables (e.g. SATA cable),
> > you can fry electronics.
> 
> Right. This is why power pins are longer than data pins in plug&play
> connectors, so that they are connected first and disconnected last.

Hmm, that surprises me -- I guess I would have expected that you want the data 
pins connected first (while no power is applied), and disconnected last (again, 
while no power is applied).  Interesting, 

I guess I am behind the times (and I will have to find some Plug-n-PLay device 
and look at the connectors).

[toc] | [prev] | [next] | [standalone]

#205691

Le 23/02/2019 à 15:41, rhkramer@gmail.com a écrit :
> On Saturday, February 23, 2019 07:53:23 AM Pascal Hambourg wrote:
>> Le 23/02/2019 à 08:53, David Christensen a écrit :
>>> Understand that if you disconnect the power cable to a motherboard,
>>> drive, peripheral, etc., but not all the other cables (e.g. SATA cable),
>>> you can fry electronics.
>>
>> Right. This is why power pins are longer than data pins in plug&play
>> connectors, so that they are connected first and disconnected last.

Oops, I meant "hotplug connectors".

> Hmm, that surprises me -- I guess I would have expected that you want the data
> pins connected first (while no power is applied), and disconnected last (again,
> while no power is applied).

Why would you want this ? From an electrical or logical point of view, 
it makes no sense.

> I guess I am behind the times (and I will have to find some Plug-n-PLay device
> and look at the connectors).

See my mistake above : hotplug, not plug-n-play.

[toc] | [prev] | [next] | [standalone]

#205698

On Saturday, February 23, 2019 10:52:20 AM Pascal Hambourg wrote:
> Le 23/02/2019 à 15:41, rhkramer@gmail.com a écrit :
> > On Saturday, February 23, 2019 07:53:23 AM Pascal Hambourg wrote:
> >> Le 23/02/2019 à 08:53, David Christensen a écrit :
> >>> Understand that if you disconnect the power cable to a motherboard,
> >>> drive, peripheral, etc., but not all the other cables (e.g. SATA
> >>> cable), you can fry electronics.
> >> 
> >> Right. This is why power pins are longer than data pins in plug&play
> >> connectors, so that they are connected first and disconnected last.
> 
> Oops, I meant "hotplug connectors".
> 
> > Hmm, that surprises me -- I guess I would have expected that you want the
> > data pins connected first (while no power is applied), and disconnected
> > last (again, while no power is applied).
> 
> Why would you want this ? From an electrical or logical point of view,
> it makes no sense.

Well, two reasons:

   * in most cases (other than hot plug) you want to make connections first, 
before you turn on the power  (I mean, for example, you don't assemble your 
computer with the power on)

   * and somewhat similarly (but in a very different context) in a 3 pin power 
plug for an ordinary household outlet (in the US), the ground pin is longer 
than the power pins so that the ground is connected before power is applied. 

[toc] | [prev] | [next] | [standalone]

#205702

[Multipart message — attachments visible in raw view] — view raw

On Sat, Feb 23, 2019 at 11:21:39AM -0500, rhkramer@gmail.com wrote:

[...]

> > Why would you want this ? From an electrical or logical point of view,
> > it makes no sense.
> 
> Well, two reasons:
> 
>    * in most cases (other than hot plug) you want to make connections first, 
> before you turn on the power  (I mean, for example, you don't assemble your 
> computer with the power on)
> 
>    * and somewhat similarly (but in a very different context) in a 3 pin power 
> plug for an ordinary household outlet (in the US), the ground pin is longer 
> than the power pins so that the ground is connected before power is applied. 

Good point, so the hotplug case seems counterintuitive. But consider that
in the first case, components are designed to handle the case of power
coming and going. If you connect them with power running, you can run
into exactly that situation that one data pin is connected before the
circuit is powered up: the best thing happening is that the input's
overvoltage protection (imagine a diode going up from the input to
the positive rail) conducts more current than it's designed for.

In the second case, the first contact is *protective ground*. It's there
to protect you from a defective device shorting the hot end to its
chassis. The power carrying pins are connected "at the same time" (i.e.
in some random order, and possibly a couple of times, if you chose
your time resolution high enough).

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#205709

On 2019-02-23 17:03, tomas@tuxteam.de wrote:
> On Sat, Feb 23, 2019 at 11:21:39AM -0500, rhkramer@gmail.com wrote:
> 
> [...]
> 

>>    * and somewhat similarly (but in a very different context) in a 3 
>> pin power
>> plug for an ordinary household outlet (in the US), the ground pin is 
>> longer
>> than the power pins so that the ground is connected before power is 
>> applied.
> 

> In the second case, the first contact is *protective ground*. It's 
> there
> to protect you from a defective device shorting the hot end to its
> chassis. The power carrying pins are connected "at the same time" (i.e.
> in some random order, and possibly a couple of times, if you chose
> your time resolution high enough).
> 

I'm not very good at electricity. As I've had it explained the neutral 
is driven into the ground at the generating station.
The Earth/ground circuit is supposed to be driven into the ground at 
your house, it's purpose to allow enough electrons to flow to trip the 
RCB/fuse in case there is a short in the local device/wiring and also a 
break in the neutral transmission line between you and the generating 
station.


mick
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#205710

[Multipart message — attachments visible in raw view] — view raw

On Sat, Feb 23, 2019 at 08:50:08PM +0000, mick crane wrote:
> On 2019-02-23 17:03, tomas@tuxteam.de wrote:

[...]

> I'm not very good at electricity. As I've had it explained the
> neutral is driven into the ground at the generating station.
> The Earth/ground circuit is supposed to be driven into the ground at
> your house, it's purpose to allow enough electrons to flow to trip
> the RCB/fuse in case there is a short in the local device/wiring and
> also a break in the neutral transmission line between you and the
> generating station.

More or less: what the RCB (residual-current breaker) does is to
sense a difference in current flowing between the phase (aka "hot")
and the neutral conductor. If there's a difference, there must be
some current flowing to ground (possibly through you, but hopefully
through the ground conductor) -- that means there is a path to
ground (not necessarily a short, though). Then the RCB trips.

But this is becoming somewhat... OT I guess :)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#205706

Le 23/02/2019 à 17:21, rhkramer@gmail.com a écrit :
> On Saturday, February 23, 2019 10:52:20 AM Pascal Hambourg wrote:
>> Le 23/02/2019 à 15:41, rhkramer@gmail.com a écrit :
>>> On Saturday, February 23, 2019 07:53:23 AM Pascal Hambourg wrote:
>>>> Le 23/02/2019 à 08:53, David Christensen a écrit :
>>>>> Understand that if you disconnect the power cable to a motherboard,
>>>>> drive, peripheral, etc., but not all the other cables (e.g. SATA
>>>>> cable), you can fry electronics.
>>>>
>>>> Right. This is why power pins are longer than data pins in hotplug
>>>> connectors, so that they are connected first and disconnected last.
>>
>>> Hmm, that surprises me -- I guess I would have expected that you want the
>>> data pins connected first (while no power is applied), and disconnected
>>> last (again, while no power is applied).
>>
>> Why would you want this ? From an electrical or logical point of view,
>> it makes no sense.
> 
> Well, two reasons:
> 
>     * in most cases (other than hot plug) you want to make connections first,
> before you turn on the power  (I mean, for example, you don't assemble your
> computer with the power on)

Most computer parts connections (CPU, RAM, PCI cards...) are not 
hotplug. For those which are (SATA in AHCI mode), you can connect them 
while the power is on, power cable first.

Besides, the point is not just about connecting the data pins but 
applying voltages to them while the device is not powered. If the whole 
computer is powered off, there is no voltage on data pins.

>     * and somewhat similarly (but in a very different context) in a 3 pin power
> plug for an ordinary household outlet (in the US), the ground pin is longer
> than the power pins so that the ground is connected before power is applied.

This is not similar at all. The ground pin is not a data pin and does 
not carry any voltage.

[toc] | [prev] | [next] | [standalone]

#205692

[Multipart message — attachments visible in raw view] — view raw

On Sat, Feb 23, 2019 at 09:41:27AM -0500, rhkramer@gmail.com wrote:
> On Saturday, February 23, 2019 07:53:23 AM Pascal Hambourg wrote:
> > Le 23/02/2019 à 08:53, David Christensen a écrit :
> > > Understand that if you disconnect the power cable to a motherboard,
> > > drive, peripheral, etc., but not all the other cables (e.g. SATA cable),
> > > you can fry electronics.
> > 
> > Right. This is why power pins are longer than data pins in plug&play
> > connectors, so that they are connected first and disconnected last.
> 
> Hmm, that surprises me -- I guess I would have expected that you want the data 
> pins connected first (while no power is applied), and disconnected last (again, 
> while no power is applied).  Interesting, 

No. Imagine a data pin at +5V while the power rails are still in an undefined
state. Not good for electronics.

> I guess I am behind the times (and I will have to find some Plug-n-PLay device 
> and look at the connectors).

Have a look at an USB connector (the traditional one, e.g. Type A):
the outer "pins" (rather stripes) are longer (those are 0 and +5V).
The middle ones (data) are shorter.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web