On 02/04/2014 10:26 AM, Andrey Borzenkov wrote:

В Tue, 04 Feb 2014 09:04:18 -0500 Robert Schweikert пишет:

...

I can get the system to boot but everything with the LVM setup is messed up.

...

...

I ran zypper up right before I tried to shutdown the machine, thus all the latest updates are installed.

That's the problem ...

https://bugzilla.novell.com/show_bug.cgi?id=862076

Yup. Thanks for pointing me in the right direction and thanks Hannes for also finding this for me in a separate thread. panic attack is over..... The solution was to set use_lvmetad = 0 in /etc/lvm/lvm.conf Later, Robert

-- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/04/2014 10:52 AM, Andrey Borzenkov wrote:

В Tue, 04 Feb 2014 10:47:04 -0500 Robert Schweikert пишет:

...

On 02/04/2014 10:26 AM, Andrey Borzenkov wrote:

...

В Tue, 04 Feb 2014 09:04:18 -0500 Robert Schweikert пишет:

...

I can get the system to boot but everything with the LVM setup is messed up.

...

...

I ran zypper up right before I tried to shutdown the machine, thus all the latest updates are installed.

That's the problem ...

https://bugzilla.novell.com/show_bug.cgi?id=862076

Yup.

Thanks for pointing me in the right direction and thanks Hannes for also finding this for me in a separate thread.

panic attack is over.....

The solution was to set

use_lvmetad = 0

in /etc/lvm/lvm.conf

Actually, intended solution is "systemctl enable lvm2-lvmetad.socket" but whatever works :)

Tried that and still ended up with a non operational setup. Turning the new fancy feature off worked. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/04/2014 12:58 PM, Andrey Borzenkov wrote:

В Tue, 04 Feb 2014 11:51:16 -0500 Robert Schweikert пишет:

...

...

...

The solution was to set

use_lvmetad = 0

in /etc/lvm/lvm.conf

Actually, intended solution is "systemctl enable lvm2-lvmetad.socket" but whatever works :)

Tried that and still ended up with a non operational setup. Turning the new fancy feature off worked.

Are you using LVM for root?

No. All my volumes are for other directory trees, /home, /srv, and other stuff. Pretty much the same situation as in the bug. In the bug it was also mentioned that enabling lvmetad did not work. It may possibly be an order thing. But even after reading the related fedora bug I was not certain abut what the order should be to get things to work as intended with use_lvmetad = 1

It does not look like mkinitrd installs lvmetad (or respective udev rule) in initrd, but it does copy /etc/lvm.conf. I wonder what lvm does in this case; probably waits for lvmetad ...

That would be a problem, but in my case should not matter as / is not on LVM and can be mounted. Later, Robert

-- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/04/2014 10:52 AM, Andrey Borzenkov wrote:

Actually, intended solution is "systemctl enable lvm2-lvmetad.socket"

What about lvm2-lvmetad.service ? Should that be enebaled too? (This is 13.1 ..........) -- Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/05/2014 09:11 AM, Robert Schweikert wrote:

On 02/05/2014 08:25 AM, Anton Aylward wrote:

...

On 02/04/2014 10:52 AM, Andrey Borzenkov wrote:

...

Actually, intended solution is "systemctl enable lvm2-lvmetad.socket"

What about lvm2-lvmetad.service ? Should that be enebaled too?

NO, only enable lvm2-lvmetad.socket if you are going down that route.

Is that No, its no necessary or NO! Its going to break and/or damage your system Could you also explain why, please. -- There are two rules for success in life: Rule 1: Don't tell people everything you know. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/05/2014 10:41 AM, Patrick Shanahan wrote:

* Robert Schweikert [02-05-14 09:12]:

...

On 02/05/2014 08:25 AM, Anton Aylward wrote:

...

On 02/04/2014 10:52 AM, Andrey Borzenkov wrote:

...

Actually, intended solution is "systemctl enable lvm2-lvmetad.socket"

What about lvm2-lvmetad.service ? Should that be enebaled too?

NO, only enable lvm2-lvmetad.socket if you are going down that route.

After recovering my Tumbleweed to a semi-normal state, I enabled lvm2-lvmetad.socket and shortly thereafter received a downgrade to lvm2-2.02.98-0.28.1.5.x86_64 which disabled lvmetad.socket.

So *what* is correct?

all 5 of my local installs, four TW and one 13.1, show lvmetad.socket "disabled", inactive (dead)

It all depends on the value in the config file. I suspect that the downgrade set use_lvmetad = 0 in /etc/lvm/lvm.conf while the previous update set the value to 1. So this is what I have gathered based on reading through the bug reports, https://bugzilla.novell.com/show_bug.cgi?id=862076 https://bugzilla.redhat.com/show_bug.cgi?id=837603 answers to this thread, and my own observation. When toggling the value of use_lvmetad either on or off one needs to make certain that the daemon is not running. In either case cache data will be remembered and there'll be no booting the next time around. If you want to use the daemon the following procedure should work: - stop all lvmetad services (.socket and .service) - toggle the flag in the config file - start the lvmetad.service and lvmetad.socket - enable lvmetad.socket The .service should not be enabled, as I understand it, as it will cause problems. The .socket will do the trick when the system is booted and things are expected to work. I have not dug into the details why this is the case and will probably not find the time to do so. To operate as previously, i.e. before the mess started - stop all lvmetad services (.socket and .service) - disable lvmetad.service and lvmetad.socket - set use_lvmetad = 0 - reboot Unless of course you have already forced recognition of your volumes with lvmetad daemon. The you run into the cache issue and the RH bugreport has the details on how to recover. HTH, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/05/2014 12:29 PM, Patrick Shanahan wrote:

* Robert Schweikert [02-05-14 12:24]:

...

On 02/05/2014 10:41 AM, Patrick Shanahan wrote: [...]

...

After recovering my Tumbleweed to a semi-normal state, I enabled lvm2-lvmetad.socket and shortly thereafter received a downgrade to lvm2-2.02.98-0.28.1.5.x86_64 which disabled lvmetad.socket.

So *what* is correct?

all 5 of my local installs, four TW and one 13.1, show lvmetad.socket "disabled", inactive (dead)

It all depends on the value in the config file. I suspect that the downgrade set

use_lvmetad = 0

in /etc/lvm/lvm.conf while the previous update set the value to 1.

So this is what I have gathered based on reading through the bug reports,

https://bugzilla.novell.com/show_bug.cgi?id=862076 https://bugzilla.redhat.com/show_bug.cgi?id=837603

answers to this thread, and my own observation.

When toggling the value of use_lvmetad either on or off one needs to make certain that the daemon is not running. In either case cache data will be remembered and there'll be no booting the next time around.

If you want to use the daemon the following procedure should work: - stop all lvmetad services (.socket and .service) - toggle the flag in the config file - start the lvmetad.service and lvmetad.socket - enable lvmetad.socket

The .service should not be enabled, as I understand it, as it will cause problems. The .socket will do the trick when the system is booted and things are expected to work. I have not dug into the details why this is the case and will probably not find the time to do so.

To operate as previously, i.e. before the mess started - stop all lvmetad services (.socket and .service) - disable lvmetad.service and lvmetad.socket - set use_lvmetad = 0 - reboot

Unless of course you have already forced recognition of your volumes with lvmetad daemon. The you run into the cache issue and the RH bugreport has the details on how to recover.

Thanks for the answer, but still leaves the *question*? Which *should* be used and to what advantage... ?

I think that's a question best answered by those that thought this was a good idea. I would think that using the daemon should/could speed up the boot process as all that is initially needed is to setup the socket. That's a relatively quick operation. After the socket is set up things can continue to run in parallel. With the "old" way of handling LVM a serialization point is created as everything has to wait for the volume handling code to do it's thing. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Andrey Borzenkov [02-04-14 10:27]:

В Tue, 04 Feb 2014 09:04:18 -0500 Robert Schweikert пишет:

...

I can get the system to boot but everything with the LVM setup is messed up.

...

...

I ran zypper up right before I tried to shutdown the machine, thus all the latest updates are installed.

That's the problem ...

https://bugzilla.novell.com/show_bug.cgi?id=862076

I too lost my lvm2 partitions and really mucked up my system :^( I have 2 2T drives raid mirror with lvm2 partitions on them. I rebooted my system and it hung showing a faulty raid (cannot remember exactly) and: [DEPEND] Dependency failed ofr /paka-A [DEPEND] Dependency failed for local File Systems. Welcome to emergency mode! After loggin in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode. After reading this thread and editing lvm2.conf to use_lvmetad = 0 I can again use my system, BUT.. in the meantime grub became confused, drive ordereing changed for some unknown reason.... Correcting device.map now allows me to boot to runlevel 3 but I cannot init 5, I get the dark background with the green flowering gecko and there it stays. Reinstalled nvidia driver to no avail I can login a text screen as <user> and "startx -- :0". where to go from here? tls. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Andrey Borzenkov [02-04-14 14:11]:

В Tue, 4 Feb 2014 13:56:09 -0500 Patrick Shanahan пишет:

...

After reading this thread and editing lvm2.conf to use_lvmetad = 0 I can again use my system, BUT.. in the meantime grub became confused, drive ordereing changed for some unknown reason.... Correcting device.map now allows me to boot to runlevel 3 but I cannot init 5, I get the dark background with the green flowering gecko and there it stays.

How long did you wait? There was at least one known case of long timeout due to lost udev events:

too long, 8-10 minutes

https://bugzilla.novell.com/show_bug.cgi?id=824442

Yes, I have seen non explainable delays but usually on shutdown and rebooting rather than startup.

...

Reinstalled nvidia driver to no avail

I can login a text screen as <user> and "startx -- :0".

Well, I have used this for years, why not?

startx result was quite flakey.

...

where to go from here?

What happens when you boot into run level 5 directly?

loooong delay at screen with dark background and green flowery gecko until I finally reset. But I just did another reboot after another flakey startx session and boot straight into X very normally. 18:24 Crash: ~ # systemd-analyze blame |head 21.521s network.service 20.917s network@eth0.service 1.586s systemd-udev-settle.service 1.323s ntp.service 1.146s spamd.service 1.020s privoxy.service 988ms SuSEfirewall2.service 721ms systemd-fsck@dev-disk-by\x2dlabel-paka\x2dA.service 547ms mdadmd.service But now my server, 13.1, will not boot, complaining in the same manner, and lvm2.conf has no string "use_lvmetad = 0" Another oddity, all main system except boot is in lvm (root,home,var,srv) and it show up fine, but a 4gb drive with lvm fails. Booted server from cd, usb will not work, and commented out the faulty lvm in fstab. Rebooted and ran vgscan which provided no answer. Ran vgscan -v an saw display of faulty lvm. Did the same with lvscan which provided no output but lvs showed same lvm as active. Removed comment from fstab and "mount -a" and all is back. BUT what will happen the next time I need to boot? :^( this is WeIrD ShiT. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Dienstag, 4. Februar 2014, 19:26:57 schrieb Andrey Borzenkov:

В Tue, 04 Feb 2014 09:04:18 -0500

Robert Schweikert пишет:

...

I can get the system to boot but everything with the LVM setup is messed up. ...

...

I ran zypper up right before I tried to shutdown the machine, thus all the latest updates are installed.

That's the problem ...

https://bugzilla.novell.com/show_bug.cgi?id=862076 I was bitten by this problem on one system this morning, too. I'am using two vgs , one with the root file system and one with only non-root filesystems. Only the the non-root vg was unusable.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/05/2014 01:59 PM, Dirk Gently wrote:

This is why I avoid LVM on ANY flavor of Unix or Linux unless the system has VERY good backups. If you lose your LVM configuration, you lose everything. In contrast, it's extremely rare to lose a partition table.

I disagree. Every disk I've lost has been - so the data rescue services tell me - damage to the outer tracks by the head withdrawing badly on shutdown/poweroff. The inner parts of the disk, if I could somehow read then, are fine. LVM doesn't need a partition table; if the data recovery people can get at it they can - somehow - 'dd' the rest of the drive and you can reconstruct a usable table using gpart - NOT gpartED! The whole point of LVM is that its portable, that the header/superblock information is 'plain text'. You can search for it by doing a dd of the partition and piping that though something like 'strings'. The problem in this thread is not with the information on the disk but with the configuration that starts up the software that allows it to be read, the mapping software etc. If Patrick, for example, took that drive and put it as a second drive on another machine, one running 12.3 for example, and vgactivated it the data would still be visible. Yes, this works. I have a 12.3 drive and a 13.1 drive in a machine. The smaller drive with 12.3 is completely BtrFS; the 13.1 1T drive has a LVM partition. I can boot the 12.3 and mount the LVM on the other drive. An example of LVM not needing a partition table; just make the whole drive LVM. -- "Most victories came from instantly exploiting your enemy's stupid mistakes, and not from any particular brilliance in your own plan." -- Orson Scott Card, -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org