Bug 1170842 - On aarch64, using dracut 050, only one interface gets ifup during the pxe boot first stage
On aarch64, using dracut 050, only one interface gets ifup during the pxe boo...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
aarch64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: dracut maintainers
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-29 14:40 UTC by Alberto Planas Dominguez
Modified: 2021-12-09 08:42 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
thomas.blume: needinfo? (aplanas)


Attachments
Dracut logs (344.81 KB, text/plain)
2020-04-29 14:40 UTC, Alberto Planas Dominguez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alberto Planas Dominguez 2020-04-29 14:40:21 UTC
Created attachment 837097 [details]
Dracut logs

When booting a OEM Kiwi via PXE boot, the download of the second kernel, initrd and image fails.

Inside the dracut shell we can see that the device have two interfaces, but only the first interface gets up. The second one can be manually up via "ifup enp0s2"

The logs shows that indeed, there is only one call to ifup, that correspond to the first interface.
Comment 1 Thomas Blume 2020-05-05 05:52:30 UTC
(In reply to Alberto Planas Dominguez from comment #0)
> Created attachment 837097 [details]
> Dracut logs
> 
> When booting a OEM Kiwi via PXE boot, the download of the second kernel,
> initrd and image fails.
> 
> Inside the dracut shell we can see that the device have two interfaces, but
> only the first interface gets up. The second one can be manually up via
> "ifup enp0s2"
> 
> The logs shows that indeed, there is only one call to ifup, that correspond
> to the first interface.

If not explicitly given at the command line, dracut will only set up one interface and just continue if this is successfull, which is the case here:

-->
   39.785787] localhost dracut-initqueue[575]: + ip -4 addr add 10.0.3.101/24 broadcast 10.0.3.255 dev enp0s1
[   39.856029] localhost dracut-initqueue[575]: + route=()
[   39.858205] localhost dracut-initqueue[575]: + local r route
[   39.858205] localhost dracut-initqueue[575]: + '[' -n '' ']'
[   39.858205] localhost dracut-initqueue[575]: + local g
[   39.858205] localhost dracut-initqueue[575]: + '[' -n 10.0.3.101 ']'
[   39.858205] localhost dracut-initqueue[575]: + for g in ${GATEWAYS}
[   39.858205] localhost dracut-initqueue[575]: + ip -4 route add default via 10.0.3.101 dev enp0s1
[   39.898801] localhost dracut-initqueue[575]: + break
[   39.901409] worker dracut-initqueue[575]: + '[' -n '' ']'
[   39.901409] worker dracut-initqueue[575]: + '[' -n worker ']'
[   39.901409] worker dracut-initqueue[575]: + echo worker
[   39.901409] worker dracut-initqueue[575]: + '[' '!' -s /tmp/net.enp0s1.resolv.conf.ipv4 ']'
[   39.907099] worker dracut-initqueue[575]: + '[' -n '' ']'
[   39.907099] worker dracut-initqueue[575]: + '[' -n '' ']'
[   39.907099] worker dracut-initqueue[575]: + '[' -n 10.0.3.1 ']'
[   39.907099] worker dracut-initqueue[575]: + for s in ${DNSSERVERS}
[   39.907099] worker dracut-initqueue[575]: + echo nameserver 10.0.3.1
[   39.907099] worker dracut-initqueue[575]: + '[' -e /tmp/net.enp0s1.resolv.conf.ipv4 ']'
[   39.907099] worker dracut-initqueue[575]: + '[' '!' -e /etc/resolv.conf ']'
[   39.907099] worker dracut-initqueue[575]: + cp -f /tmp/net.enp0s1.resolv.conf.ipv4 /etc/resolv.conf
[   39.945505] worker systemd[1]: inotify event for /etc/localtime
[   39.949340] worker systemd[1]: Failed to stat /etc/localtime, ignoring: No such file or directory
[   39.951267] worker dracut-initqueue[575]: + info 'DHCP is finished successfully'
[   39.953333] worker dracut-initqueue[575]: + echo 'DHCP is finished successfully'
--<

The root cause visible in the logs is that the device for installation isn't found:

-->
[   48.582317] worker dracut-pre-mount[719]: /////lib/dracut/hooks/pre-mount/30-kiwi-dump-image.sh@15(report_and_quit): die 'No device(s) for installation found'
[   48.582317] worker dracut-pre-mount[719]: ////lib/dracut-lib.sh@460(die): echo '<24>dracut: FATAL: No device(s) for installation found'
[   48.582317] worker dracut-pre-mount[719]: ////lib/dracut-lib.sh@461(die): echo '<24>dracut: Refusing to continue'
[   48.582317] worker dracut-pre-mount[719]: ////lib/dracut-lib.sh@465(die): echo 'warn dracut: FATAL: "No device(s) for installation found"'
[   48.582317] worker dracut-pre-mount[719]: ////lib/dracut-lib.sh@466(die): echo 'warn dracut: Refusing to continue'
--<

Still, I can see that a device gets plugged:

-->
[   36.297674] localhost systemd[1]: dev-vda.device: Changed dead -> plugged
[   36.298760] localhost systemd[1]: sys-devices-platform-LNRO0005:1f-virtio2-block-vda.device: Changed dead -> plugged
--<

Is vda the device configured for installation?
Comment 2 Alberto Planas Dominguez 2020-05-06 09:27:22 UTC
(In reply to Thomas Blume from comment #1)

Thomas, thanks for checking this one too!

> If not explicitly given at the command line, dracut will only set up one
> interface and just continue if this is successfull, which is the case here:

This confuses me, as traditionally all my PXE images for the last 1.5 year are using two interfaces, and the tftp server was listening on the second one. As we say in the log from the Intel device, both interfaces were detected and ifup was called for them.


> Still, I can see that a device gets plugged:
> 
> -->
> [   36.297674] localhost systemd[1]: dev-vda.device: Changed dead -> plugged
> [   36.298760] localhost systemd[1]:
> sys-devices-platform-LNRO0005:1f-virtio2-block-vda.device: Changed dead ->
> plugged
> --<
> 
> Is vda the device configured for installation?

You just found a new bug. You are right that indeed I cannot see vda with this new version of the image, but can be a kernel issue. I will rebuild the image under a more up-to-date TW in some days.
Comment 3 Thomas Blume 2020-05-06 10:10:26 UTC
(In reply to Alberto Planas Dominguez from comment #2)
> (In reply to Thomas Blume from comment #1)
> 
> Thomas, thanks for checking this one too!
> 
> > If not explicitly given at the command line, dracut will only set up one
> > interface and just continue if this is successfull, which is the case here:
> 
> This confuses me, as traditionally all my PXE images for the last 1.5 year
> are using two interfaces, and the tftp server was listening on the second
> one. As we say in the log from the Intel device, both interfaces were
> detected and ifup was called for them.
> 

Yes, if the dhcp setup of the first network interface is not sucessfull, subsequent ones are tried until the setup on one succeeds.
But if the setup on the first interface already succeeds, there is no need to setup additional interfaces (unless explicitly specified with the ip= parameter).
If your pxe server only listens on the second interface, the dhcp setup on the first one will fail and dracut should go to the next.

> > Still, I can see that a device gets plugged:
> > 
> > -->
> > [   36.297674] localhost systemd[1]: dev-vda.device: Changed dead -> plugged
> > [   36.298760] localhost systemd[1]:
> > sys-devices-platform-LNRO0005:1f-virtio2-block-vda.device: Changed dead ->
> > plugged
> > --<
> > 
> > Is vda the device configured for installation?
> 
> You just found a new bug. You are right that indeed I cannot see vda with
> this new version of the image, but can be a kernel issue. I will rebuild the
> image under a more up-to-date TW in some days.

Ok
Comment 4 Thomas Blume 2020-05-26 14:44:29 UTC
(In reply to Alberto Planas Dominguez from comment #2)
> > Is vda the device configured for installation?
> 
> You just found a new bug. You are right that indeed I cannot see vda with
> this new version of the image, but can be a kernel issue. I will rebuild the
> image under a more up-to-date TW in some days.

Hi Alberto, could you already retry with a more up to date TW image?
Comment 5 Antonio Feijoo 2021-12-09 08:40:32 UTC
Hi Alberto, we are cleaning up old bug reports. Could you give us some feedback on whether this is still happening with a recent TW version or may we close this one? Thank you.
Comment 6 Alberto Planas Dominguez 2021-12-09 08:42:04 UTC
Fixed.