July 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 23 Jul '20

23 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c19 --- Comment #19 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Fabian Vogt from comment #18) > No, that "$?" is wrong because there is an if preceding it. > Example: > if false; then false; fi > echo $? # 0 > > So using $? after an if is not working as expected here, it will only > indicate > the exit code of "do_dhcp -4" or "do_dhcp", but never of "do_dhcp -6". Argh, you are right, took me some time to see it, thanks! [...] > Yay, spaghetti... fully agreed > > Please note I appreciate your comments and will try to addess them as best > > as possible, but without breaking anything working. > > Unfortunately code changes here are very delicate since it has a big impact > > on netboot. > > Yep, this is the reverse-engineering part of cleanup ;-) > > I don't see any downside to merging the "# No ip lines default to dhcp" block > with the "# no ip option directed at our interface?" one down below, it would > make the various options and flows much more obvious. Ok, working on an update. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 23 Jul '20

23 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c18 --- Comment #18 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Thomas Blume from comment #16) > (In reply to Fabian Vogt from comment #15) > > > Hm, did you check the latest code? > > > There is: > > > > > > if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then > > > > > > the leasinfo file won't be there if there was no dhcp setup. > > > > Yes, but the use of $? there is still wrong AFAICT. > > Ah, you mean when there is no ip= option at all and no bootdev either? No, that "$?" is wrong because there is an if preceding it. Example: if false; then false; fi echo $? # 0 So using $? after an if is not working as expected here, it will only indicate the exit code of "do_dhcp -4" or "do_dhcp", but never of "do_dhcp -6". > But how should the network get set up via ifup then? > Using rd.neednet without specifying an interface would make the script bail > out early: > > --> > # Huh? No $1? > [ -z "$1" ] && exit 1 > --< > > There is the ifname boot parameter, but that is again covered in another > script, e.g. parse-ifname.sh. ifup.sh is called by udev for each interface, so $1 is always set. Just "rd.neednet=1" works fine. > > Not tested, but would that just move the "dhcp twice" case to netroot only? > > There's nothing which prevents the "# no ip option directed at our > > interface?" > > block from running after "# No ip lines default to dhcp" as the former > > doesn't > > touch /tmp/net.${netif}.up, does it? > > Maybe, I'm overlooking something but AFAICS, the second if would call > do_dhcp only when bootdev is set or ip=dhcp(6); Indeed, so that would probably work. It's totally not obvious though. > --> > if [ -e /tmp/net.bootdev ]; then > BOOTDEV=$(cat /tmp/net.bootdev) > if [ "$netif" = "$BOOTDEV" ] || [ "$BOOTDEV" = "$(cat > /sys/class/net/${netif}/address)" ]; then > load_ipv6 > do_dhcp > fi > else > if getargs 'ip=dhcp6'; then > load_ipv6 > do_dhcp -6 > fi > if getargs 'ip=dhcp'; then > do_dhcp -4 > fi > fi > --< > > So, it shouldn't run again after the "# No ip lines default to dhcp" part. > But it would write did-setup, which is fine since it could have been setup > in "# No ip lines default to dhcp". Yay, spaghetti... > Please note I appreciate your comments and will try to addess them as best > as possible, but without breaking anything working. > Unfortunately code changes here are very delicate since it has a big impact > on netboot. Yep, this is the reverse-engineering part of cleanup ;-) I don't see any downside to merging the "# No ip lines default to dhcp" block with the "# no ip option directed at our interface?" one down below, it would make the various options and flows much more obvious. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174047] Weird load behaviour with kernel-5.3.18-lp152.20.7-default
by bugzilla_noreply＠suse.com 22 Jul '20

22 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174047 https://bugzilla.suse.com/show_bug.cgi?id=1174047#c5 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Takashi Iwai <tiwai(a)suse.com> --- The *.26 kernel is built from the very same source as *.20 but just signed with a correct key (*.20 broke some secure boot-related stuff). So it's no wonder that it didn't work. A patch included recently was identified to be the fix for this problem, so the next kernel should work. I close this now with that promise; if the next one is still broken, please open. Thanks. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174391] /lib/firmware update causes Dell 7300 to hang on boot after loading initrd ramdisk
by bugzilla_noreply＠suse.com 22 Jul '20

22 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174391 https://bugzilla.suse.com/show_bug.cgi?id=1174391#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |janm2(a)gmx.de, | |tiwai(a)suse.com Flags| |needinfo?(janm2(a)gmx.de) --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- It's a known problem regarding the AMDGPU firmware update that broke with this kernel-firmware update, but your case doesn't seem that. Or is it with AMDGPU? Other than that, the only other changes in this update were Realtek rtl8125b stuff, but this doesn't look matching with yours (with Realtek but different chips). Could you try to identify which kernel-firmware-xxx package may break things? It'd be greatly appreciated if we can know that. You can save initrd file beforehand (just copy /boot/initrd-xxx to /boot/initrd-xxx.old), and choose it in GRUB menu for recovery, too. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174116] New: Kernel repeatedly crashing
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174116 Bug ID: 1174116 Summary: Kernel repeatedly crashing Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: msvec(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 839676 --> https://bugzilla.suse.com/attachment.cgi?id=839676&action=edit kernel log This is the latest 15.2 with kernel-default-5.3.18-lp152.20.7.1.x86_64 The only thing I need to do was: - kinit - access a file in the NFS directory See the attached crash log -- You are receiving this mail because: You are the assignee for the bug.

1 21

[kernel-bugs] [Bug 1173448] Webcam(earlier working) doesn't work now. Sony Vaio
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173448 https://bugzilla.suse.com/show_bug.cgi?id=1173448#c7 --- Comment #7 from Takashi Iwai <tiwai(a)suse.com> --- You can try just installing the latest openSUSE Leap 15.1 kernel, e.g. from OBS Kernel:openSUSE-15.1 repo http://download.opensuse.org/repositories/Kernel:/openSUSE-15.1/standard/ Grab kernel-default.rpm, and install it manually via zypper zypper in --oldpackage kernel-default-4.12*.rpm You might need to add --nodeps option for ignoring the kernel-firmware dependency. Then reboot with that kernel (go "Advanced menu" in GRUB menu and choose it). Similarly, try Leap 15.2 kernel from http://download.opensuse.org/repositories/Kernel:/openSUSE-15.2/standard/ too -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c17 --- Comment #17 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Thomas Blume from comment #16) > (In reply to Fabian Vogt from comment #15) > > > Hm, did you check the latest code? > > > There is: > > > > > > if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then > > > > > > the leasinfo file won't be there if there was no dhcp setup. > > > > Yes, but the use of $? there is still wrong AFAICT. > > Ah, you mean when there is no ip= option at all and no bootdev either? > But how should the network get set up via ifup then? > Using rd.neednet without specifying an interface would make the script bail > out early: > > --> > # Huh? No $1? > [ -z "$1" ] && exit 1 > --< > > There is the ifname boot parameter, but that is again covered in another > script, e.g. parse-ifname.sh. Sorry, that reply was incomplete, $? is also needed in the do_dhcp case, because the function has parts where the return code is set explicitly. checking for leaseinfo is not the same, because this file is created by wicked in yet another function (dhcp_wicked_apply). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c16 --- Comment #16 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Fabian Vogt from comment #15) > > Hm, did you check the latest code? > > There is: > > > > if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then > > > > the leasinfo file won't be there if there was no dhcp setup. > > Yes, but the use of $? there is still wrong AFAICT. Ah, you mean when there is no ip= option at all and no bootdev either? But how should the network get set up via ifup then? Using rd.neednet without specifying an interface would make the script bail out early: --> # Huh? No $1? [ -z "$1" ] && exit 1 --< There is the ifname boot parameter, but that is again covered in another script, e.g. parse-ifname.sh. > > Those parameters are a bit different, bootdev is documented as: > > --> > > bootdev=<interface> > > specify network interface to use routing and netroot information > > from. Required if multiple ip= lines are used. > > --< > > > > So it is bound to the netroot case and a specific interface, whereas > > rd.neednet does the network setup unconditionally. > > That seems to be working with netroot, but not depend on netroot. > It doesn't say that bootdev can only be specified if multiple ip= options > are set, but only that it is mandatory in that case. Hm, right, even though it doesn't make sense it is allowed to set rd.neednet together with bootdev. But in any case the bootdev option requires an specific interface name while in the rd.neednet only case $iface should be empty. > Not tested, but would that just move the "dhcp twice" case to netroot only? > There's nothing which prevents the "# no ip option directed at our > interface?" > block from running after "# No ip lines default to dhcp" as the former > doesn't > touch /tmp/net.${netif}.up, does it? Maybe, I'm overlooking something but AFAICS, the second if would call do_dhcp only when bootdev is set or ip=dhcp(6); --> if [ -e /tmp/net.bootdev ]; then BOOTDEV=$(cat /tmp/net.bootdev) if [ "$netif" = "$BOOTDEV" ] || [ "$BOOTDEV" = "$(cat /sys/class/net/${netif}/address)" ]; then load_ipv6 do_dhcp fi else if getargs 'ip=dhcp6'; then load_ipv6 do_dhcp -6 fi if getargs 'ip=dhcp'; then do_dhcp -4 fi fi --< So, it shouldn't run again after the "# No ip lines default to dhcp" part. But it would write did-setup, which is fine since it could have been setup in "# No ip lines default to dhcp". Please note I appreciate your comments and will try to addess them as best as possible, but without breaking anything working. Unfortunately code changes here are very delicate since it has a big impact on netboot. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c15 --- Comment #15 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Thomas Blume from comment #14) > (In reply to Fabian Vogt from comment #12) > > - Touch did-setup in the "# no ip option directed at our interface?" case > > after successful do_dhcp > > > > 0b998beebc008f2dda2eed8a36d59f4a258cb27a introduced the code to handle the > > latter, but: > > - It also runs in cases where the do_dhcp in this block wasn't actually run > > (like in this bug report) > > - The $? it checks is meaningless at this point due to the ifs > > Hm, did you check the latest code? > There is: > > if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then > > the leasinfo file won't be there if there was no dhcp setup. Yes, but the use of $? there is still wrong AFAICT. > > In the "rd.neednet=1 bootdev=eth0" case it actually runs do_dhcp twice for > > the interface, as both > > "# No ip ..." blocks apply. Maybe those blocks should be merged? > > Those parameters are a bit different, bootdev is documented as: > --> > bootdev=<interface> > specify network interface to use routing and netroot information > from. Required if multiple ip= lines are used. > --< > > So it is bound to the netroot case and a specific interface, whereas > rd.neednet does the network setup unconditionally. That seems to be working with netroot, but not depend on netroot. It doesn't say that bootdev can only be specified if multiple ip= options are set, but only that it is mandatory in that case. > Also, the code for evaluating rd.neednet isn't in ifup.sh but in > net-genrules.sh. > > Considering the duplicate run of do_dhcp, I'd blame this at the missing > check for netroot as outlined above. Not tested, but would that just move the "dhcp twice" case to netroot only? There's nothing which prevents the "# no ip option directed at our interface?" block from running after "# No ip lines default to dhcp" as the former doesn't touch /tmp/net.${netif}.up, does it? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c14 --- Comment #14 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Fabian Vogt from comment #12) > (In reply to Thomas Blume from comment #11) > > Can you please give the dracut package at: > > > > https://build.opensuse.org/package/binaries/home:tsaupe:branches:openSUSE: > > Factory:dracut-bsc1173402/dracut/openSUSE_Factory > > > > a try? > > Works! > > Looking at this again, this is quite the mess... > AFAICT, touching the did-setup file after a successful "do_dhcp" is > generally the right way. > > This is currently not done, which lead to > https://github.com/tblume/dracut/commit/ > 0b998beebc008f2dda2eed8a36d59f4a258cb27a adding another path to create > did-setup. > This new path was broken by > https://github.com/tblume/dracut/commit/ > 28be2f3692d6a641c841f636c03e45c5f3c4ec6b, which you now fixed with > https://github.com/tblume/dracut/commit/ > 487fb167b82c88871e6d1ace21ccdb0a48e9032d. > > What should be done IMO: > > - Touch did-setup in the "# No ip lines default to dhcp" case after > successful do_dhcp The code there really looks wrong: --> if [ -z "$NO_AUTO_DHCP" ] && [ -z "$ip" ]; then if [ "$netroot" = "dhcp6" ]; then do_dhcp -6 else do_dhcp -4 fi --< That runs do_dhcp -4 in any case if there is no ip= line and dhcp isn't explicitly disabled. But that code is apparently for the netroot case, so it needs to be checked whether $netroot is filled. After this, a did-setup is indeed appropriate IMHO. > - Touch did-setup in the "# no ip option directed at our interface?" case > after successful do_dhcp > > 0b998beebc008f2dda2eed8a36d59f4a258cb27a introduced the code to handle the > latter, but: > - It also runs in cases where the do_dhcp in this block wasn't actually run > (like in this bug report) > - The $? it checks is meaningless at this point due to the ifs Hm, did you check the latest code? There is: if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then the leasinfo file won't be there if there was no dhcp setup. > In the "rd.neednet=1 bootdev=eth0" case it actually runs do_dhcp twice for > the interface, as both > "# No ip ..." blocks apply. Maybe those blocks should be merged? Those parameters are a bit different, bootdev is documented as: --> bootdev=<interface> specify network interface to use routing and netroot information from. Required if multiple ip= lines are used. --< So it is bound to the netroot case and a specific interface, whereas rd.neednet does the network setup unconditionally. Also, the code for evaluating rd.neednet isn't in ifup.sh but in net-genrules.sh. Considering the duplicate run of do_dhcp, I'd blame this at the missing check for netroot as outlined above. -- You are receiving this mail because: You are the assignee for the bug.

1 0