[clue] Ack! (recovering busted disks - (fixed)

[Mike Bean]

Theorhetically yes, and we did that, but as predicted, since I #1 noticed
the box was down and #2 attempted to fix it, I therefore have ownership of
it now.   Have to look into a cheap scale able method to get actual backups
and stop depending on snap shots.   I suppose I could just back it up.  But
it's only a matter of time before someone notices the Jenkins box has
backups and complains that all the other boxes don't.

Mike B

On Thu, Apr 14, 2016 at 7:52 PM, <foo7775 at comcast.net> wrote:

> Glad to hear that you were able to recover - and it sounds like a good
> time to create an updated snapshot!  ;-)
>
> T.
> ------------------------------
> *From: *"Mike Bean" <beandaemon at gmail.com>
> *To: *"CLUE's mailing list" <clue at cluedenver.org>
> *Sent: *Tuesday, April 12, 2016 11:54:53 AM
> *Subject: *[clue]  Ack! (recovering busted disks - (fixed)
>
>
> Tagging this fixed.  We got lucky.  For the life of me I don't really
> understand why, but somehow the machine lost the ability to see the disc by
> UUID, but could still see it by device name.
>
> changing /etc/grub/grub.conf from
> linux   /vmlinuz-3.16.0-0.bpo.4-amd64 root=UUID ro  quiet
> to
> linux   /vmlinuz-3.16.0-0.bpo.4-amd64 root=/dev/mapper/rootvg-rootlv ro
>  quiet
>
> somehow fixed the issue.   (after running update-grub).
>
> (whew)
>
> On Tue, Apr 12, 2016 at 9:54 AM, Mike Bean <beandaemon at gmail.com> wrote:
>
>> Well, the UUID it's referencing is our root LVM group.   But it would
>> make sense for it to be a problem with boot partition.
>>
>> On Tue, Apr 12, 2016 at 9:51 AM, Charles Burton <
>> charles.d.burton at gmail.com> wrote:
>>
>>> Are you sure you're using it with LVM?  At boot LVM scans all the disks
>>> and looks for the metadata, it generally doesn't care much about UUID other
>>> than for internal accounting.  Likely it's your boot partition.
>>>
>>> On Tue, Apr 12, 2016 at 3:33 PM, Mike Bean <beandaemon at gmail.com> wrote:
>>>
>>>>
>>>> We have a fairly major system at work that somehow lost track of a disk
>>>> ALERT! /dev/disk/by-uuid/(some id) does not exist.  Dropping to a shell
>>>>
>>>> Booting to recovery mode gets the same result.
>>>> Booting to a debian disk on rescue mode sees the disk.  the UUID in
>>>> question is the root VG
>>>>
>>>> Must admit, my google-fu has failed me.  I have no idea.  I have a
>>>> snapshot I can revert to, but it's an old one, and the users will lose
>>>> allot of their work.
>>>>
>>>> Mike B
>>>>
>>>> _______________________________________________
>>>> clue mailing list: clue at cluedenver.org
>>>> For information, account preferences, or to unsubscribe see:
>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>
>>>
>>>
>>> _______________________________________________
>>> clue mailing list: clue at cluedenver.org
>>> For information, account preferences, or to unsubscribe see:
>>> http://cluedenver.org/mailman/listinfo/clue
>>>
>>
>>
>
> _______________________________________________
> clue mailing list: clue at cluedenver.org
> For information, account preferences, or to unsubscribe see:
> http://cluedenver.org/mailman/listinfo/clue
>
>
> _______________________________________________
> clue mailing list: clue at cluedenver.org
> For information, account preferences, or to unsubscribe see:
> http://cluedenver.org/mailman/listinfo/clue
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20160419/1c3da41d/attachment.html