[opensuse] All my volumes disappered
Hi, Could use some help in pebbling one of my machines back to live. This is openSUSE 13.1 on x86_64. The machine also functions as my print server and this is where the spiral started. This morning I wanted to print something, from another machine, and noticed that the printer had disappeared. After trying to reconfigure it and restarting cups on the print server didn't work I hoped for the magical "lets reboot the box" trick. After all, what could possibly go wrong. Well, pretty much everything went wrong from there. Issuing "shutdown -r now" put he box in limbo and I ended up having to push the power button. Initially after turning it back on it wouldn't boot at all getting stuck when trying to deal with the external usb drive attached. The external device is not part of any VG setup. Turned off the external device and commented out the entries that point to the volume groups in /etc/fstab. Keeping the fstab entries brought me to emergency boot mode in systemd, but the keyboard wouldn't work. Thus, this was entirely useless (filed a bug). I can get the system to boot but everything with the LVM setup is messed up. For example lsblk only shows the drives: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT fd0 2:0 1 4K 0 disk sda 8:0 0 55.9G 0 disk ├─sda1 8:1 0 1G 0 part /boot ├─sda2 8:2 0 12G 0 part [SWAP] └─sda3 8:3 0 42.9G 0 part / sdb 8:16 0 931.5G 0 disk └─sdb1 8:17 0 931.5G 0 part sdc 8:32 0 465.8G 0 disk └─sdc1 8:33 0 465.8G 0 part sdd 8:48 0 931.5G 0 disk └─sdd1 8:49 0 931.5G 0 part sr0 11:0 1 1024M 0 rom But when I boot into a rescue system on SLES DVD and run lsblk I can see the LVM setup in the output For example: sdb |_sdb1 |-extend_VG-home (dm-1) Typing the whole tree is a bit cumbersome. Running lvdisplay when running on the installed system produces sensible output, i.e. what I would expect, except for: # lvdisplay No device found for PV mM4Hhg-o52o-pj0p-fd7v-ArzT-gilf-ZrVdTh. The rest of the output looks OK to me. I have no idea how I would map the cryptic name to an actual device. The systemlog contains timeout messages for 2 of the 3 drives: systemd-udevd[310]: worker [325] /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:1/3:0:1:0/block/sdd/sdd1 timeout; kill it systemd-udevd[310]: worker [327] /devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdc/sdc1 timeout; kill it In the rescue system I can set up a chroot environment and then mount the volumes and everything is fine. As usual, I would rather not go the reinstall route, but am out of ideas at this point. I could use some help. I ran zypper up right before I tried to shutdown the machine, thus all the latest updates are installed. Thanks, 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 04:04 PM, Robert Schweikert wrote:
hoped for the magical "lets reboot the box" trick. After all, what could possibly go wrong. Well, pretty much everything went wrong from there.
wouldn't boot at all getting stuck when trying to deal with the external usb drive attached.
- i wonder if having an external usb drive attached, is what caused my crisis : "os-prober crisis" on Feb 2nd ................
In the rescue system I can set up a chroot environment and then mount the volumes and everything is fine.
my "os-prober" crisis was solved by rescue system : mount /dev/sd'xy' /mnt mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys mount -o bind /dev /mnt/dev chroot /mnt ............... then ran Yast bootloader setup with grub legacy [old grub] [ i had to have 2 attempts : with grub2, was not able to boot : but happily on 2nd attempt with old grub all went well, and was able to boot ok ........... regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В 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 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 ...
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
В 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 ...
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 :) -- 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 ...
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
В 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? 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 ... -- 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
В Tue, 04 Feb 2014 13:30:05 -0500
Robert Schweikert
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
You do not need to enable lvm2-lvmetad.service. You need to enable lvm2-lvmetad.*socket*. This way service is auto-started as soon as lvm tries to connect to socket. Having service alone enabled would of course imply race condition against udev. Enabling socket works for me for non-system group.
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
Actually not, if lvmetad is not available, it falls back to old behavior. So you get nagging warnings but that's all. The problem with non-system group is that with lvmetad set in lvm.conf but disabled nothing activates those groups. -- 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 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. -- 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 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
* Robert Schweikert
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) -- (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
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
* Robert Schweikert
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... ? tks, -- (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
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
В Wed, 5 Feb 2014 12:29:57 -0500
Patrick Shanahan
Thanks for the answer, but still leaves the *question*? Which *should* be used and to what advantage... ?
Whatever works for you. But the real question is - what if user consciously wants to use current settings? Normally update is not expected to go and change them. ... looking at package - it appears that no settings are changed explicitly, rather if default lvm.conf is present it is replaced by new one. Which means - if user made any modification to lvm.conf, change to use lvmetad by default will not be effective. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* 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 ...
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
В Tue, 4 Feb 2014 13:56:09 -0500
Patrick Shanahan
* 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 ...
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.
https://bugzilla.novell.com/show_bug.cgi?id=852021
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: https://bugzilla.novell.com/show_bug.cgi?id=824442
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?
where to go from here?
What happens when you boot into run level 5 directly? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Andrey Borzenkov
В 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
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
* Patrick Shanahan
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.
And just got lvm2 downgrades on all five local linux boxes ??? -- (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
Robert Schweikert wrote:
Hi,
Could use some help in pebbling one of my machines back to live. This is openSUSE 13.1 on x86_64.
The machine also functions as my print server and this is where the spiral started. This morning I wanted to print something, from another machine, and noticed that the printer had disappeared. After trying to reconfigure it and restarting cups on the print server didn't work I hoped for the magical "lets reboot the box" trick. After all, what could possibly go wrong. Well, pretty much everything went wrong from there.
Issuing "shutdown -r now" put he box in limbo and I ended up having to push the power button. Initially after turning it back on it wouldn't boot at all getting stuck when trying to deal with the external usb drive attached. The external device is not part of any VG setup. Turned off the external device and commented out the entries that point to the volume groups in /etc/fstab. Keeping the fstab entries brought me to emergency boot mode in systemd, but the keyboard wouldn't work. Thus, this was entirely useless (filed a bug).
I can get the system to boot but everything with the LVM setup is messed up.
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. -- 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
Anton Aylward wrote:
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.
I still see it as "one more thing that can go wrong. And having had issues with such (Some sequent machines I was administrating back in the 1990's), and not seeing any improvement to safeguard against some of the problems, I still shy away from it unless the system data files are nearly bullet-proof (mirroring RAID, etc.) from a data-storage perspective -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/04/2014 03:04 PM, Robert Schweikert wrote:
The machine also functions as my print server and this is where the spiral started. This morning I wanted to print something, from another machine, and noticed that the printer had disappeared. After trying to reconfigure it and restarting cups on the print server didn't work I hoped for the magical "lets reboot the box" trick. After all, what could possibly go wrong. Well, pretty much everything went wrong from there.
For your printing problem read: https://bugzilla.novell.com/show_bug.cgi?id=857372
participants (8)
-
Andrey Borzenkov
-
Anton Aylward
-
Dirk Gently
-
ellanios82
-
Florian Gleixner
-
Markus Koßmann
-
Patrick Shanahan
-
Robert Schweikert