>>> On 3/12/2015 at 02:17 AM, Offer Baruch <[email protected]> wrote: > Hi, > > after adding the new device (dasdd) i can see that the partition has a UUID > (as it has a FS on it).
OK. > the devices them self's don't (i think this makes sense as they don't have > a FS on them). Correct. > about the persistent_policy... i have tried that > sadly no luck... Was the error the same? I.e., disk with uuid not found, or did it change to path-to-disk not found? > I have run online update not long ago and now running with kernel level > 3.12.36-38. not sure if this is the latest but defiantly a recent one. > is that enough? what is the latest? That's current. > Can someone reproduce this or is this only me? I cannot reproduce it. > one more thing i can't understand... > on previous versions if a FS was specified in the fstab with a zero at the > end (do not run fsck) linux will fully boot even if the FS is not present. > looks like this has changed and now all FS must be available during boot > time or maintenance mode it is. am i correct or this is defect? Depending on what you've done, this can happen. It seems that any swap space you have defined is going to be activated in the grub2 initrd phase. I'm guessing this is because dracut wants to make sure that if you've done a suspend that it will be able to do a resume, so it needs to have all the swap space available when the kernel checks for that. Also, /usr needs to be available during the initrd phase, since so much of the basic system has been moved there. But, I'm not sure that's what you're seeing. Even in prior versions, if an entry in /etc/fstab cannot be mounted, you would get thrown into maintenance mode. It didn't matter if it was marked as "0 0" or not. That only controlled fsck calls. If what you're seeing looks like this (a lot of these actually): A start job is running for dev-disk-by\x2dpath-ccw\x...38s / 1min 30s) Followed by: [ [1;33mDEPEND [0m] Dependency failed for /testing. [ [1;33mDEPEND [0m] Dependency failed for Local File Systems. [ [1;33mDEPEND [0m] Dependency failed for Postfix Mail Transport Agent. systemd-journald[378]: Received request to flush runtime journal from PID 1 Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode. Give root password for maintenance Then that's the same result you would have had with SLES11, just looking very different from before. (And having to wait 90 seconds to be able to do anything about it.) What happens if you disable the cio_ignore piece completely? Does that make a difference? Either way, send me your z/VM console logs and a supportconfig offline. I'll see what I can figure out. Mark Post ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
