<html><body><div style="font-family: Arial; font-size: 12pt; color: #000000"><div>Thanks for the reply Jim, it's much appreciated. When I boot with the new drive in place, it takes (or is assigned) sdB.<br></div><div><br></div><div>What I was expecting was that the original drives (sda through sdd) would retain their existing configurations, & when I slid the new drive in, it would take the 'sdE' block device which had originally been occupied by the failing drive. Instead, it's appeared to trample all over the sdB drive. And now that that's happened, I can't seem to get the original sdB drive to reappear. I am thinking that I'll use the UUID to force the new drive to take the sdE block device - I just don't know how to get the original sdB drive to reappear.</div><div><br></div><div>It doesn't even list the scsi_device (3:0:0:0) that was originally in use by the original sdB drive, unless I slide either the new or old/damaged drive back into the slot...<br></div><div><br></div><div>Thanks for the pointer to udev, I'll take a look at that.<br></div><div><br></div><div>Thanks again,<br></div><div><br></div><div>T.<br></div><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Jim Ockers" <ockers@ockers.net><br><b>To: </b>clue@cluedenver.org<br><b>Sent: </b>Sunday, June 12, 2016 2:18:43 PM<br><b>Subject: </b>Re: [clue] HDD "shell game" issue<br><div><br></div>
When you boot with the new drive in place, what is its block
device? Is it /dev/sdb or some other device name?<br>
<br>
I understand from your email that your server will boot with the new
drive installed if you comment out the fstab entry which references
filesystems on /dev/sdb . If the new drive becomes /dev/sdb could
you boot up without sdb in fstab, and then while the server is up
you could format the drive the way that fstab expects, and then
uncomment the sdb lines in /etc/fstab, do 'mount -a' to mount them,
and then once you're sure everything is OK, then reboot the server
and it should come up normally. Did you try that?<br>
<br>
If the new drive simply won't become /dev/sdb and you need it to
become /dev/sdb then maybe you have a persistent block device name?
Maybe you could look for & edit udev configs to get rid of the
old sdb device config.
<a class="moz-txt-link-freetext" href="https://wiki.archlinux.org/index.php/persistent_block_device_naming" target="_blank">https://wiki.archlinux.org/index.php/persistent_block_device_naming</a>
It seems like I had to do something like this once but it's been so
long I've forgotten the specifics. I know I have to edit udev
configs to make ethernet cards get the right ethX id.<br>
<br>
Jim<br>
<br>
<div class="moz-cite-prefix">On 6/12/16 12:48 PM,
<a class="moz-txt-link-abbreviated" href="mailto:foo7775@comcast.net" target="_blank">foo7775@comcast.net</a> wrote:<br>
</div>
<blockquote cite="mid:2011696060.21285049.1465760935291.JavaMail.zimbra@comcast.net">
<div style="font-family: Arial; font-size: 12pt; color: #000000">
<div>Hi All,<br>
</div>
<div><br>
</div>
<div> I've run into a situation that
has me puzzled (& a little bit humbled, actually). I have
a server that started out with five drives, sda - sde (no
RAID, no LVM). The sde drive has been throwing alerts for a
few days, so I went in to the DC to replace it. The drives
are hot-swappable, so I didn't expect much problem - but when
I inserted the new drive, the server appeared to not detect it
- and started to generate alerts for the sdB drive as well.
(I'm sure that at least a couple of you can probably see where
this is going...)<br>
</div>
<div><br>
</div>
<div> After puzzling over the
problem for a little while, I found that the new drive had
(appropriated|been assigned to) the sdB slot, rather than sdE
like I had expected. At that point, I started trying to
collect info so that I could recreate the fstab file using
'mount-by-uuid' - but regardless of what configuration I try,
I can't seem to get the original sdB drive to reappear:<br>
</div>
<div><br>
</div>
<div> If I boot with the drive slot
open, I get sda, sdc & sdd.<br>
</div>
<div><br>
</div>
<div> If I boot with the drive slot
holding the bad/original drive, the server shows sda through
sdd.<br>
</div>
<div><br>
</div>
<div> If I boot with the drive slot
holding the new/unformatted drive, the boot process fails when
it's unable to complete checking the drives (server's been up
for >450 days), & I had to boot from a rescue drive
& comment out the sdb entry in fstab to get the server to
complete booting.<br>
</div>
<div><br>
</div>
<div> The worst part of dealing with
this is that I *know* that it's not a really complex issue -
but I am just not seeing how to restore the server to proper
function (which has me feeling distinctly inept). I'm sure
that there's data that I've forgotten to provide here, so if
anyone has any questions, I'll do my best to answer them.<br>
</div>
<div><br>
</div>
<div>I would really appreciate any
thoughts/suggestions that anyone can provide.<br>
</div>
<div><br>
</div>
<div>Thanks in advance.<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
clue mailing list: <a class="moz-txt-link-abbreviated" href="mailto:clue@cluedenver.org" target="_blank">clue@cluedenver.org</a>
For information, account preferences, or to unsubscribe see:
<a class="moz-txt-link-freetext" href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/listinfo/clue</a><br data-mce-bogus="1"></pre>
</blockquote>
<br>
<br>_______________________________________________<br>clue mailing list: clue@cluedenver.org<br>For information, account preferences, or to unsubscribe see:<br>http://cluedenver.org/mailman/listinfo/clue</div><div><br></div></div></body></html>