[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From heinz-werner_se...@de.ibm.com 2021-02-25 07:33 EDT--- IBM Bugzilla status->closed Fix Released with 20.04 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From heinz-werner_se...@de.ibm.com 2021-01-27 08:03 EDT--- ok, same behavior like with the PPA package -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From niklas.schne...@ibm.com 2021-01-22 11:01 EDT--- (In reply to comment #89) > So for now I think we should pick up the patches as they are, > since they already provide value and we will be at a similar level like on > groovy, > mention the current situation in the release notes and pointing to > "nvme-core.multipath=0" > and SRUing a chreipl fix as soon as it becomes available (probably for H, G > and F then). Sounds good, thank you! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From niklas.schne...@ibm.com 2021-01-22 10:39 EDT--- (In reply to comment #87) > Ubuntu supports NVMe Multipath on all architectures in Focal. I know that > some other distributions do not. > > Setting nvme-core.multipath=0 for s390x isos only, or changing kernel config > to disable multipath to "n" on s390x only, would mean regression on s390x as > compared with amd64/arm64/ppc64le. > > That would be suboptimal. > > Do you have no plans to support multipath NVMe and are customers who buy > expensive multipath capable NVMe drives will not be able to use multipath > capability with them? Or for example is multipath handled separately on Z > with NVMe? (ie. HMC mediated) > > My preference would be to see a chreipl fix upstream in s390-tools to add > support for multipath nvme drives, and SRU that too. Oh, we absolutely want to support NVMe multipathing and I don't see a general reason to disable it in the config as I don't know about any other issues with it. This is only about working around the current "chreipl node /dev/nvmeXYZ" bug which as far as I understand breaks the final reboot from the installer to the installed system. We're already working on a chreipl fix but as far as I understand the installer ISOs are released only for .x releases and running the installer with multipathing off should only impact the installer's performance or am I missing something? So this is definitely meant as a temporary workaround. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From niklas.schne...@ibm.com 2021-01-22 10:02 EDT--- Hi Frank, we've now internally confirmed that setting the "nvme-core.multipath=0" Kernel parameter as a workaround makes "chreipl node" succeed with NVMes that otherwise break the current chreipl due to its lack of multipath support. Do you think it would be possible to set this Kernel parameter for the installer? As far as I understand this option doesn't necessarily have to be set for the installed system since the IPL information is stored in firmware as FID and namespace so only a manual "chreipl node /dev/nvmeXYZ" from the installed system would risk breaking the IPL information and there the user should get a crash and can instead use "chreipl nvme -i -s ". Normal "zipl" as done by a kernel update should not be a problem, in fact I've got an Ubuntu 20.04 installed on an NVMe (via KVM ;-) /dev/vda on an NVMe) here and kernel updates worked fine. Alternatively there is also the config option CONFIG_NVME_MULTIPATH if we would set that to "n" for Z that should also work. Either way we'll of course work on a proper fix for chreipl. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From jjhe...@us.ibm.com 2021-01-15 08:35 EDT--- (In reply to comment #82) > Is the NVMe drive with or without nvme-multipath support? > Does it help to disable multipath? > > Please see the below pullrequest from Canonical employee in efivar project > that explains the issue a bit, and the various paths that the NVMe devices > can have. > > https://github.com/rhboot/efivar/pull/158 > > This also affected efibootmgr project for the EFI platforms with newer > kernels, as shipped in focal. > > You can also try booting with the following kernel cmdline option appended > in the param file i.e. `nvme_core.multipath=N` to get the "non-multipath > nvme0 nodes in the sysfs". > > BTW > https://www.ibm.com/support/knowledgecenter/STSLR9_8.3.1/com.ibm.fs9100_831. > doc/svc_fc_nvme_multipathconfighosts.html has an excellent summary of nvme > multipath situation in various distros. Yes, multipath is the problem here. When multipath is enabled we have a different sysfs structure. I'll have to work up a fix. Can you move ahead with the code as it is, and then we can provide a bug fix patch when ready? This chreipl bug should not impede NVMe installation or a normal boot process. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From jjhe...@us.ibm.com 2021-01-14 09:00 EDT--- chreipl currently fails on Ubuntu 20.04 when given a device node (e.g. chreipl /dev/nvme0n1p1). This is because chreipl cannot find the expected sysfs directory structure. We are investigating the best way to fix this. If the Ubuntu installer can still complete an install to NVMe devices without this particular invocation of chreipl then we recommend going forward with the code as-is and we can provide a bug fix at a later date. I suspect this should be fine, as chreipl should only affect the reboot following OS installation. It should be noted that chreipl works when given the devices function id (FID) parameter instead of the device node. It only fails when it needs to look up the device's FID given the device node. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From jjhe...@us.ibm.com 2020-12-01 08:05 EDT--- (In reply to comment #74) > @Jason, seems to be some build failures. Can you please have a look. It looks like there are two versions of this patch applied: [PATCH] s390-tools: zipl: Fix NVMe partition and base device detection Not sure how this happened. Here is the compiler output: disk.c:174:12: error: redefinition of ?blkext_get_partnum? 174 | static int blkext_get_partnum(dev_t dev) |^~ disk.c:92:12: note: previous definition of ?blkext_get_partnum? was here 92 | static int blkext_get_partnum(dev_t dev) |^~ disk.c:199:12: error: redefinition of ?blkext_is_base_device? 199 | static int blkext_is_base_device(dev_t dev) |^ disk.c:117:12: note: previous definition of ?blkext_is_base_device? was here 117 | static int blkext_is_base_device(dev_t dev) |^ disk.c:213:12: error: redefinition of ?blkext_get_base_dev? 213 | static int blkext_get_base_dev(dev_t dev, dev_t *base_dev) |^~~ disk.c:131:12: note: previous definition of ?blkext_get_base_dev? was here 131 | static int blkext_get_base_dev(dev_t dev, dev_t *base_dev) |^~~ Can someone on Canonical's end manually verify this,and perhaps exclude the above patch from their build if it seems to already be present? I created the backport patches on top of the following repo/branch: git://git.launchpad.net/ubuntu/+source/s390-tools focal-proposed And on this branch, this patch was missing, which is why I included it here. Was I using the wrong repo/branch for this backport? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From jjhe...@us.ibm.com 2020-11-17 16:23 EDT--- I've attached the three backported s390-tools patches for focal-proposed. They received a basic compile test and a very quick "it runs" sanity check. If we need more testing at this stage, let me know and I'll see about getting it tested properly. This may take a day or two as the environment is very difficult to set up without installer support for NVMe devices. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From jjhe...@us.ibm.com 2020-11-16 14:19 EDT--- (In reply to comment #60) > Hi Jan, yes (almost) all Ubuntu packages are hosted nowadays at our > Launchpad git (at least all packages in main, incl. s390-tools). > Please see: https://code.launchpad.net/ubuntu/+source/s390-tools > If you are logged in with a Launchpad account, you will directly see at the > top a comd-line that allows to clone the package sources, like: > " Get this repository: > git clone https://git.launchpad.net/ubuntu/+source/s390-tools " > If not logged in you'll see a more generic page, but again listing the URLs > that can be used for cloning, here: > git://git.launchpad.net/ubuntu/+source/s390-tools > git+ssh://git.launchpad.net/ubuntu/+source/s390-tools > https://git.launchpad.net/ubuntu/+source/s390-tools I've cloned the repo. Which branch should I re-base the patches on? I was able to find the following likely candidates: origin/ubuntu/focal origin/ubuntu/focal-devel origin/ubuntu/focal-proposed origin/ubuntu/focal-updates -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From jan.hoepp...@de.ibm.com 2020-11-16 11:16 EDT--- Canonical, are there public s390-tools repositories with the Ubuntu versions available that we can mirror internally and which we could then use for potential backport work (such as this feature seems to require)? Please let me know so that we can provide you with backport patches that apply cleanly on your version of s390-tools (v2.12.0). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902179] Comment bridged from LTC Bugzilla
--- Comment From heinz-werner_se...@de.ibm.com 2020-11-05 12:23 EDT--- We were finally able to cobble together a system to perform some testing on the provided Ubuntu test kernel. Here is what was tested (using Debian s390-tools 2.14): - Using zipl to install the bootloader to NVMe works as expected. - The kernel IPLs and the IPL type is properly identified via lsreipl - chreipl/reboot to the same NVMe device works as expected. - chreipl/reboot to a DASD works as expected. What could not easily be tested in our environment: - chreipl/reboot from the DASD back to the NVMe device. - chreipl involving an FCP device. Though, knowing what has changed in the code, and knowing how reipl works, I have no reason to suspect that either of these test cases could cause any issues. I would be confident to give a thumbs up here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902179 Title: [20.04 FEAT] Support/enhancement of NVMe IPL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
