On 4/22/20 12:16 PM, Will, Chris wrote:
> Mark,
>
> Dasda2 and dasdd1 should have all the LVM logical volumes that are part of
> the root file system (/usr, /var, /opt, /home, /tmp) which are xfs file
> systems. The remainder of the root file system(/) is on dasda1 (ext4).
> When I cat
Mark,
Dasda2 and dasdd1 should have all the LVM logical volumes that are part of the
root file system (/usr, /var, /opt, /home, /tmp) which are xfs file systems.
The remainder of the root file system(/) is on dasda1 (ext4). When I cat
/proc/cio_ignore it is empty. When I run Dracut I get
Try when you are in that shell
vgchange -ay system
You may have to chzdev -e first
On Tue, Apr 21, 2020 at 9:21 AM Will, Chris wrote:
> This has now happened on two SLES 12 SP4 that have had any of the LVM root
> file system (/var /tmp, etc) expanded (lvextend). Here is the error
>
Probably notthe Linux world seemed easier for me to understand before all
the "unification" efforts (like grub, systemd, et al). Just showing my age.
Thanks for the explanation, Mark.
Thanks,
Sam
(217) 862-9227 (office)
(602) 327-2134 (cell)
-Original Message-
From: Linux on 390
On 4/22/20 11:03 AM, Will, Chris wrote:
> Scanning devices dasda2 dasdd1 sda1 sdb1 sdc1 sdd1 for LVM logical volumes
> system-vg/usr-lv
So, this is the list of eligible block devices that are currently active
on this system. Are all the block devices that *should* be there,
actually there? Are
On 4/22/20 11:21 AM, Cohen, Sam wrote:
> FWIW, every time I run dracut, I then run zipl before IPLing.
If you're doing this on a SLES system that's using grub2, I'm not at all
sure zipl is doing what you think it is. The zipl command is *only* used
to re-write the block locations for the "grub2
Chris,
FWIW, every time I run dracut, I then run zipl before IPLing.
Thanks,
Sam
(217) 862-9227 (office)
(602) 327-2134 (cell)
-Original Message-
From: Linux on 390 Port On Behalf Of Will, Chris
Sent: Wednesday, April 22, 2020 8:03 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: BCACHE
I have a more current version of Dracut but still having issues. I expanded
the volume (got the BCACHE messages), ran "dracut -f" and rebooted and got a
disabled wait. From the other server here are some of the messages from the
rdsosreport file.
+ cat /lib/dracut/dracut-044-10.21.1
Yes, we had this in two forms. Both fixed by the dracut fix (and
rerunning it)
Subject: SR101238520451 Re dracut timeout problems after
patching
Marcy,
We released this fix in maint
(dracut-044.2-10.15.2.s390x). The other
On 4/21/20 12:11 PM, Will, Chris wrote:
> Has anyone run into something like this? I would like to fix this
> proactively and not wait until the server dies and I have to go into
> emergency mode. This could be an issue with all our servers.
Hi, Chris,
I really thing the BCACHE messages are
Yes, we had this in two forms. Both fixed by the dracut fix (and rerunning
it)
Subject: SR101238520451 Re dracut timeout problems after patching
Marcy,
We released this fix in maint (dracut-044.2-10.15.2.s390x).
The other issue related to this:
This has now happened on two SLES 12 SP4 that have had any of the LVM root file
system (/var /tmp, etc) expanded (lvextend). Here is the error message.
sles12osdev2:~ # lvextend -L +2G /dev/mapper/system--vg-opt--lv
scan_dev_close /dev/dasda2 no DEV_IN_BCACHE set
scan_dev_close /dev/dasdc1 no
12 matches
Mail list logo
