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

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

Failure to boot - LVM problems?

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

Contents

  Failure to boot - LVM problems? Richard Hector <richard@walnut.gen.nz> - 2019-01-04 02:50 +0100
    Re: Failure to boot - LVM problems? Richard Hector <richard@walnut.gen.nz> - 2019-01-11 03:20 +0100
      Re: Failure to boot - LVM problems? Michael Stone <mstone@debian.org> - 2019-01-11 15:40 +0100

#203929 — Failure to boot - LVM problems?

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

Hi all,

This is one of those annoying cases where I claim "It was working, and I
didn't do anything, and now it doesn't" - suspicious, I know ...

In this case, I can see from my emails that this machine booted (via
wake-on-lan from a cronjob) this morning, and then shut itself down (via
a local cronjob), having done its job. Then later, I booted it manually,
and it didn't - when I plugged in a screen and keyboard, I found it at
the 'root password for maintenance or Ctrl-D to continue' prompt.

On logging in, I found it had had problems mounting filesystems.

All further attempts to boot it have gone straight from grub to a
blinking underline cursor in the top left.

If I boot with one of the 'recovery mode' options, I can get back to the
maintenance option. Having dug around a bit, I find that 'vgchange -ay'
followed by 'systemctl default' brings it up, in an apparently normal state.

It reports warnings about being unable to connect to lvmetad, but I
gather that's not normally something to worry about. On the other hand,
the searches I've done have only found suggestions for disabling it, not
making it work.

General info about the system:

It's a generic tower system, with (currently) 6 disks.

I use RAID 1 for everything - but in an effort to keep the arrays small
(an attempt to reduce the risk of failing to rebuild before another
error happens), there are many partitions, grouped into vgs with lvm.
However, the filesystems I'm having problems with are on a vg that has
only one md in it, because those disks are relatively small anyway.

It runs a single kvm guest, which does my backups using dirvish (pulling
from various machines both locally and over the net) - hence the
automated boot in the middle of the night.

The weather is kind of hot (New Zealand summer), which is one of the
reasons I went to the cronjob solution to not (normally) run it during
the day - I started that last summer, but have had it running 24/7 for a
while, and then shut it down to rely on this system a couple of days
ago, so it hasn't had many boot cycles recently.

Any tips/questions very welcome.

Cheers,
Richard

[toc] | [next] | [standalone]

#204302

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

On 4/01/19 2:48 PM, Richard Hector wrote:
> Hi all,
> 
> This is one of those annoying cases where I claim "It was working, and I
> didn't do anything, and now it doesn't" - suspicious, I know ...
> 
> In this case, I can see from my emails that this machine booted (via
> wake-on-lan from a cronjob) this morning, and then shut itself down (via
> a local cronjob), having done its job. Then later, I booted it manually,
> and it didn't - when I plugged in a screen and keyboard, I found it at
> the 'root password for maintenance or Ctrl-D to continue' prompt.
> 
> On logging in, I found it had had problems mounting filesystems.
> 
> All further attempts to boot it have gone straight from grub to a
> blinking underline cursor in the top left.
> 
> If I boot with one of the 'recovery mode' options, I can get back to the
> maintenance option. Having dug around a bit, I find that 'vgchange -ay'
> followed by 'systemctl default' brings it up, in an apparently normal state.
> 
> It reports warnings about being unable to connect to lvmetad, but I
> gather that's not normally something to worry about. On the other hand,
> the searches I've done have only found suggestions for disabling it, not
> making it work.
> 
> General info about the system:
> 
> It's a generic tower system, with (currently) 6 disks.
> 
> I use RAID 1 for everything - but in an effort to keep the arrays small
> (an attempt to reduce the risk of failing to rebuild before another
> error happens), there are many partitions, grouped into vgs with lvm.
> However, the filesystems I'm having problems with are on a vg that has
> only one md in it, because those disks are relatively small anyway.
> 
> It runs a single kvm guest, which does my backups using dirvish (pulling
> from various machines both locally and over the net) - hence the
> automated boot in the middle of the night.
> 
> The weather is kind of hot (New Zealand summer), which is one of the
> reasons I went to the cronjob solution to not (normally) run it during
> the day - I started that last summer, but have had it running 24/7 for a
> while, and then shut it down to rely on this system a couple of days
> ago, so it hasn't had many boot cycles recently.
> 
> Any tips/questions very welcome.

It turns out the later failures to boot probably weren't; it's just that
I had 'quiet' enabled in the kernel commandline. Disabling that enabled
me to see where it was hanging - which is now queried in my 'Slow boot?'
thread.

So the initial failure must have been a one-off thing, which if anything
is more worrying - sounding more like hardware.

Richard

Richard

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

#204316

On Fri, Jan 11, 2019 at 03:16:37PM +1300, Richard Hector wrote:
>It turns out the later failures to boot probably weren't; it's just that
>I had 'quiet' enabled in the kernel commandline. Disabling that enabled
>me to see where it was hanging 

Yeah, I hate that "quiet" is the default--in the best case it's 
pointless, in the worst case it gets in the way.

[toc] | [prev] | [standalone]

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

csiph-web