** Changed in: systemd (Ubuntu)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some restarts fail due to missing base devices
To manage
The system LPAR this was seen first was an upgrade from Xenial but since then
has been freshly installed with Yakkety. The same behaviour is seen on a zVM
guest running Yakkety.
If anyone face printer issue click here http://canonprintersupport247.com
--
You received this bug notification
Okay suggestion is to:
- Update zKVM (which is based on IBM KVM on z) to the latest and last release
1.1.2 FP4.
1.1.2 FP4 is the only one that is still supported. I can help on that.
- It might also be worth trying to limit the devices on the LPAR with the help
of cio_ignore
and see if that
Here is the number from the beginning of this SRU cycle till today
(since Jul. 3)
We have 6 jobs for each node, which requires at least 6 re-deployments
(note that it's just a reboot for s390x, since we don't re-deploy them).
The failures here means how many times we need to reboot it manually.
Hi, we’re trying to explore different approaches to investigate, resolve
and/or work around this issue, but regrettably there do not appear to be
any simple solutions.
Would it be possible to record the failure rate during the testing for
the next SRU cycle? Perhaps something simple like “5
journalctl log for kernel02 (s390x.zVM), which drops to emergency mode
as well
** Attachment added: "kernel02.log"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1623383/+attachment/4841328/+files/kernel02.log
--
You received this bug notification because you are a member of Ubuntu
Node s2lp6g003 (s390x.zKVM) boot to emergency mode. Please find
attachment for the journalctl log.
** Attachment added: "s2lp6g003.log"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1623383/+attachment/4840829/+files/s2lp6g003.log
--
You received this bug notification because you
On 13 March 2017 at 16:58, Ian Thompson <1623...@bugs.launchpad.net> wrote:
> I have the same problem with two Dell PowerEdge FC630.
> Ubuntu 16.04.2 LTS/ 4.4.0-66-generic
>
> Shutdown/reboot stalls at different points each attempt.
>
> An IBM System x3650 M4 in the same rack, at the same software
I have the same problem with two Dell PowerEdge FC630.
Ubuntu 16.04.2 LTS/ 4.4.0-66-generic
Shutdown/reboot stalls at different points each attempt.
An IBM System x3650 M4 in the same rack, at the same software level,
reboots cleanly every time.
--
You received this bug notification because
Hello Frank, I have set udev.log_priority and rd.udev.log_priority to
debug on kernel03 with smb's help. Let's wait for this happens.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
After further investigation the issue could be related to udev.
Would it be possible to start the systems with kernel parameters
udev.log_priority and rd.udev.log_priority set to debug and share again
the logs from a failed system?
--
You received this bug notification because you are a member
Looks like this can happen on VM guests and KVM vms, too.
(could be somehow related to zfs ...)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some restarts fail due to missing base
** Package changed: udev (Ubuntu) => systemd (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some restarts fail due to missing base devices
To manage notifications about this
#15 -> those things look fine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some restarts fail due to missing base devices
To manage notifications about this bug go to:
Is that normal? However I also see those disconnects on the journal of a
good boot...
journalctl -b0|grep private
Sep 23 09:57:51 kernel02 systemd-tmpfiles[1936]: Entry
"/tmp/systemd-private-4f4f7561b59a4b06a720204adeaff628-*" does not match any
include prefix, skipping.
Sep 23 09:57:51
Changing the type of systemd-modules-load from oneshot to simple might
work around the problem. At least this output looks like it would have
been a hang:
* systemd-modules-load.service - Load Kernel Modules
Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static;
vendor
vgs:
VG #PV #LV #SN Attr VSize VFree
datavg 1 1 0 wz--n- 20.63g 0
zfcpvg 1 0 0 wz--n- 10.00g 10.00g
lvs:
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
Convert
home datavg -wi-ao 20.63g
--
You received this bug notification
Sep 22 13:15:45 s2lp4 systemd[1]: systemd-modules-load.service: Failed
to send unit change signal for systemd-modules-load.service: Transport
endpoint is not connected
Pretty much means that pid1 stopped listening to /run/systemd/private.
Does not receive exited notification, does not mark
Adding the setup of the zVM guest that shows the problem in case that
helps to re-create the problem:
Memory: 4G, 8 vCPUs
Device Subchan. DevType CU Type Use PIM PAM POM CHPIDs
--
0.0.e002 0.0. 1732/03 1731/03 yes 80
Still happened, even without any modules getting loaded by that service.
Maybe the specific service is a red-herring and its something else which
just shows there because the service is in the critical path. For making
things more clear, here the messages related to it from boot -1 (a
failed one)
I took a dump of another run that ended in the failed state. While not all
messages that are in the journal show up in the dmesg log from a dump, there
does not seem to be a message about systemd noticing the exit on
systemd-modules-load, however I can not see the process listed in the ps
Spending more time looking at the two logs, I saw that in the failed boot case
the
systemd-modules-load.service is never stopping. The last message there is that
the ib_iser module (which is the second of 2) got loaded and thats all.
When the boot succeeds, then the systemd init process receives
** Changed in: udev (Ubuntu)
Assignee: (unassigned) => Dimitri John Ledkov (xnox)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some restarts fail due to missing base devices
** Tags added: xenial
** Tags removed: xenial
** Tags added: yakkety
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some restarts fail due to missing base devices
To manage
This is the (compressed otherwise it would be 13M) journal from a zVM
guest failed boot. One thing that maybe should noted, we have some zfcp
disks enabled on the LPAR and zVM guest. That is at least for the zVM
guest the same config as we have for the guest running Xenial.
** Attachment added:
** Attachment added: "zvmguest-goodboot-journal.txt.gz"
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1623383/+attachment/4744324/+files/zvmguest-goodboot-journal.txt.gz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
enc600 is the qeth net device for the zVM guest. There seem to be issues
visible with that in the log.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some restarts fail due to missing
For testing I enabled "debug" in the kernel command-line since that has
some influence on how systemd acts but I found both the LPAR and the zVM
guest unreachable this morning which is a sign they did not survive
being rebooted.
--
You received this bug notification because you are a member of
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: udev (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some
This issue is now blocking kernel regression testing for these s390
variants.
** Changed in: udev (Ubuntu)
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
** Tags added: s390x
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623383
Title:
Some restarts fail due to missing base devices
To manage notifications about this bug go to:
31 matches
Mail list logo
