Re: [opensuse-factory] Base:System util-linux, regarding sr 226509
Ruediger Meier wrote:
On Friday 21 March 2014, Stanislav Brabec wrote:
Ruediger Meier wrote:
Hi,
The ChangeLog is almost useless since none of the referenced bug reports is readable for non-suse people.
These changelogs were taken from the original changelog. Many of openSUSE changelogs refer to bugs that are not accessible. In ideal case, people working on SLES fix would post the same patch to openSUSE, and make a public clone of the bug report. It did not happened, and a review found these patches, where the patch was not posted to Factory nor upstream.
At least one of the added patches ("umount-avoid-readlink.patch") has no effect because it patches a deprecated and unused subdir which will be removed in next release anyway.
Yes, it is deliberate. The patch was created for SLE11 and affects the code, which is now deprecated and not used. I did not want to lose this patch and save it for upstreaming.
Upstream has already removed the whole code.
If upstream dropped "mount-deprecated" completely, then the patch as is is obsolete, and can be dropped now (or in the next version that will have no "mount-deprecated" code).
Collecting upstream-able patches will take some time. Hopefully these patches will disappear from the Factory then.
I'd like to help to get useful patches upstream. But it's hard if I'm not allowed to know anything about the fixed issues.
Well, there is also a lot of openSUSE patches, that need to check its universal validity. Regarding the SLES11 patches: sfdisk-warn-about-2TB-limit.patch: The msdos partition table is suppose to address up to 2 TB LUNs. Sfdisk didn't stop (or warning) the user about this limitation and went ahead created partition beyond 2 TB. After the reboot, the device node for the partition starting above 2TB was not created. Fix is impossible, but sfdisk should warn about it. The same bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324525 util-linux-ng-2.16-squashfs3-detect.patch: Detection of squashfs3 filesystem was requested. util-linux-ng-2.19.1-barrier_documentation.patch: The description of the 'barrier' mount option was request. Patch was written by Jan Kára. He wrote in the bug, that he sent the patch to the upstream as well. Maybe it was lost. util-linux-update-default-commit-interval.patch: Customer pointed out with the inclusion of the linux-2.6.29-jbd-longer-commit-interval.patch, changing "kjournald starting. Commit interval 15 seconds" from the long standing default "5 seconds", the "mount" man pages are no longer correct. Obsoleting of uuid-runtime: That package existed between SLE11 SP1 and SLE11 SP3 and probably sometimes in past. I failed to track the package origin, but it is safe to keep Obsoletes in the spec file. umount-avoid-readlink.patch: The problem existed (exists?) on NFS (reproduced on SLE11 SP2 on s390x, but probably was (is?) reproducible on all platforms): 1) sudo mount -t nfs4 -o sec=sys,intr,noac,nordirplus machine:/dir,binary /mnt 2) stop/reconfig NFS server 3) sudo umount -f /mnt umount2: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle umount2: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle sudo umount /mnt umount.nfs4: /mnt: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle File conflict: Package s390-32 contains files s390 and s390x conflicting with util-linux and breaks installation on System Z. uname26: There was a request to support uname26 in PAM (it already is) and have a simple to use uname26 binary.
Please somebody have a look at the last changelog and either make the bug reports world-readable or fix the changlog to explain the purpose of these patches:
SLES bug reports that contain sensitive customer data cannot be opened for public.
Have you really checked all the bug reports and they all contain sensitive data?
Well, if the bug is reported against SLES, there is no way to make it public in Bugzilla. The only way is making an openSUSE clone. Most of SLE bugs contain commercial support information, machine configurations and similar sensitive data.
Most of these patches are self descriptive. Well, this one is probably not true for umount-avoid-readlink.patch:
It's purpose is avoiding a readlink() failure when umount'ing stale NFS volumes.
But today your patch only changes unused code. If this is still an issue in the new code then your patch will not fix it. Volunteer reviewers (like me) cannot really check if there is still an issue or not. Also I'd like to check whether this patch would be good for Evergreen 11.4.
I know. The code of umount is completely rewritten, and I was not able to determine, whether it is still needed. I plan to do test of these problems and then either port them or drop.
* lscpu: improve hypervisor detection (puzel@novell.com, fate#310255)
This patch for example breaks a test in the test suite. None of us can read the discussion about this new feature. non-SLE people had no chance to say their opinion about it.
Patch was written by Petr Uzel. There was requested detection of all Hypervisors on x86_64, System Z and Power in lscpu and detect virtual graphic adapters. Adding him to Cc. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri 21-03-14 21:10:26, Stanislav Brabec wrote:
Well, there is also a lot of openSUSE patches, that need to check its universal validity.
Regarding the SLES11 patches:
sfdisk-warn-about-2TB-limit.patch: The msdos partition table is suppose to address up to 2 TB LUNs. Sfdisk didn't stop (or warning) the user about this limitation and went ahead created partition beyond 2 TB. After the reboot, the device node for the partition starting above 2TB was not created. Fix is impossible, but sfdisk should warn about it. The same bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324525
util-linux-ng-2.16-squashfs3-detect.patch: Detection of squashfs3 filesystem was requested.
util-linux-ng-2.19.1-barrier_documentation.patch: The description of the 'barrier' mount option was request. Patch was written by Jan Kára. He wrote in the bug, that he sent the patch to the upstream as well. Maybe it was lost. Yes, I did submit it. Not sure what happened with it. Can you please resubmit it?
util-linux-update-default-commit-interval.patch: Customer pointed out with the inclusion of the linux-2.6.29-jbd-longer-commit-interval.patch, changing "kjournald starting. Commit interval 15 seconds" from the long standing default "5 seconds", the "mount" man pages are no longer correct. The longer commit interval was a SUSE specific tweak. So also the doc change was suse specific. We don't have the longer commit interval in SLE12 any longer so we can drop the doc change as well.
Honza
--
Jan Kara
On Sunday 23 March 2014, Jan Kara wrote:
On Fri 21-03-14 21:10:26, Stanislav Brabec wrote:
Well, there is also a lot of openSUSE patches, that need to check its universal validity.
Regarding the SLES11 patches:
Thank you both for the additional comments. I will also review and test again whether they are still needed or to get them upstream for next release. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 21 March 2014, Stanislav Brabec wrote:
Ruediger Meier wrote:
On Friday 21 March 2014, Stanislav Brabec wrote:
Ruediger Meier wrote:
Hi,
The ChangeLog is almost useless since none of the referenced bug reports is readable for non-suse people.
These changelogs were taken from the original changelog. Many of openSUSE changelogs refer to bugs that are not accessible. In ideal case, people working on SLES fix would post the same patch to openSUSE, and make a public clone of the bug report. It did not happened, and a review found these patches, where the patch was not posted to Factory nor upstream.
At least one of the added patches ("umount-avoid-readlink.patch") has no effect because it patches a deprecated and unused subdir which will be removed in next release anyway.
Yes, it is deliberate. The patch was created for SLE11 and affects the code, which is now deprecated and not used. I did not want to lose this patch and save it for upstreaming.
Upstream has already removed the whole code.
If upstream dropped "mount-deprecated" completely, then the patch as is is obsolete, and can be dropped now (or in the next version that will have no "mount-deprecated" code).
Collecting upstream-able patches will take some time. Hopefully these patches will disappear from the Factory then.
I'd like to help to get useful patches upstream. But it's hard if I'm not allowed to know anything about the fixed issues.
Well, there is also a lot of openSUSE patches, that need to check its universal validity.
Regarding the SLES11 patches:
I have reviewed all these added patches (except squashfs3 detection). See sr228719 https://build.opensuse.org/request/show/228719 The barrier barrier_documentation.patch is upstream now. I'd also like to get lscpu-improve-hypervisor-detection.patch upstream but for testing I would need dumps of /proc and /sys from such interesting systems. I also think that the vmware detection (temporary SIGSEGV handler) couldn't work together with lscpu's option -s. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 02.04.2014 12:27, schrieb Ruediger Meier:
I'd also like to get lscpu-improve-hypervisor-detection.patch upstream but for testing I would need dumps of /proc and /sys from such interesting systems.
What 'interesting systems'? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 02 April 2014, Stefan Seyfried wrote:
Am 02.04.2014 12:27, schrieb Ruediger Meier:
I'd also like to get lscpu-improve-hypervisor-detection.patch upstream but for testing I would need dumps of /proc and /sys from such interesting systems.
What 'interesting systems'?
Generally all (virtual) machines where above patch improves/corrects the output of lscpu | grep "^Hyper\|Virtualization" These could be for example virtual machines like [HYPER_VMWARE] = "VMware", [HYPER_VBOX] = "Oracle", [HYPER_OS400] = "OS/400", [HYPER_PHYP] = "pHyp" and/or ppc machines with existing directories like /proc/iSeries /proc/device-tree/ibm,partition-name /proc/device-tree/hypervisor/compatible and/or machines with pci and graphic cards by some of these vendors ids: +const int hv_vendor_pci[] = { + [HYPER_MSHV] = 0x1414, + [HYPER_VMWARE] = 0x15ad, + [HYPER_VBOX] = 0x80ee +}; + +const int hv_graphics_pci[] = { + [HYPER_MSHV] = 0x5353, + [HYPER_VMWARE] = 0x0710, + [HYPER_VBOX] = 0xbeef }; cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/02/2014 03:02 PM, Ruediger Meier wrote:
On Wednesday 02 April 2014, Stefan Seyfried wrote:
Am 02.04.2014 12:27, schrieb Ruediger Meier:
I'd also like to get lscpu-improve-hypervisor-detection.patch upstream but for testing I would need dumps of /proc and /sys from such interesting systems.
What 'interesting systems'?
Generally all (virtual) machines where above patch improves/corrects the output of lscpu | grep "^Hyper\|Virtualization"
No 'grep -i virt' match in './lscpu' output (latest git) on an openSUSE-13.1 guest in VirtualBox-4.3.10 (host=Win7): $ ./lscpu --version lscpu from util-linux 2.24.424-753d $ ~/util-linux> ./lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 58 Model name: Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz Stepping: 9 CPU MHz: 1584.000 CPU max MHz: 3800.0000 CPU min MHz: 1600.0000 BogoMIPS: 3355.62 L1d cache: 32K L1d cache: 32K L2d cache: 6144K NUMA node0 CPU(s): 0,1 Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 02 April 2014, Bernhard Voelker wrote:
On 04/02/2014 03:02 PM, Ruediger Meier wrote:
On Wednesday 02 April 2014, Stefan Seyfried wrote:
Am 02.04.2014 12:27, schrieb Ruediger Meier:
I'd also like to get lscpu-improve-hypervisor-detection.patch upstream but for testing I would need dumps of /proc and /sys from such interesting systems.
What 'interesting systems'?
Generally all (virtual) machines where above patch improves/corrects the output of lscpu | grep "^Hyper\|Virtualization"
No 'grep -i virt' match in './lscpu' output (latest git) on an openSUSE-13.1 guest in VirtualBox-4.3.10 (host=Win7):
$ ./lscpu --version lscpu from util-linux 2.24.424-753d
Could you try to apply that patch to see whether it does something? https://github.com/rudimeier/util-linux/commit/beadd39381ab51079b47d2494397f... You could also send me a tar ball with all these paths (if they exist): ls -d /proc/{cpuinfo,sysinfo} /proc/bus/pci/devices \ /proc/device-tree /proc/vz /proc/bc /proc/self/status \ /proc/xen/capabilities /sys/devices/system/{cpu,node} \ 2>/dev/null Like the ones in util-linux/tests/ts/lscpu/dumps/ (allthough these ones may not contain everything which is parsed nowadays) Thanks, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Ruediger, Am 02.04.2014 15:02, schrieb Ruediger Meier:
On Wednesday 02 April 2014, Stefan Seyfried wrote:
What 'interesting systems'?
Generally all (virtual) machines where above patch improves/corrects the output of lscpu | grep "^Hyper\|Virtualization"
These could be for example virtual machines like [HYPER_VMWARE] = "VMware", [HYPER_VBOX] = "Oracle", [HYPER_OS400] = "OS/400", [HYPER_PHYP] = "pHyp"
and/or ppc machines with existing directories like /proc/iSeries /proc/device-tree/ibm,partition-name /proc/device-tree/hypervisor/compatible
and/or machines with pci and graphic cards by some of these vendors ids: +const int hv_vendor_pci[] = { + [HYPER_MSHV] = 0x1414, + [HYPER_VMWARE] = 0x15ad, + [HYPER_VBOX] = 0x80ee +}; + +const int hv_graphics_pci[] = { + [HYPER_MSHV] = 0x5353, + [HYPER_VMWARE] = 0x0710, + [HYPER_VBOX] = 0xbeef };
Luckily I have none of the above. I might have been able to help out with relatively new CPUs and stuff, but not commercial hypervisors, sorry. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Bernhard Voelker -
Jan Kara -
Ruediger Meier -
Stanislav Brabec -
Stefan Seyfried