error: don't know how to handle 'root=live:<url>'

OSInside / kiwi

KIWI - Appliance Builder Next Generation

https://osinside.github.io/kiwi

GNU General Public License v3.0

298 stars 152 forks source link

error: don't know how to handle 'root=live:<url>' #796

Closed beta-tester closed 6 years ago

beta-tester commented 6 years ago

Problem description

when i try to pxe-boot live-systems like openSUSE-Leap-15.0-GNOME-Live-x86_64-Current.iso or CentOS-7-x86_64-DVD-1804.iso on my PC (x86-x64), i get the folowing error message and the system halted.

dracut: don't know how to handle 'root=live:http://192.168.1.1/nfs/opensuse-x64/LiveOS/squashfs.img'

PS.: this issue report is a follow up of Bug 1099548 - can't PXE-boot into openSUSE Leap 15.0 Live image as reminder for adding livenet integration of the upstream module to the kiwi-live dracut module

Expected behaviour

i used equal boot options like for Fedora 28 LiveDVD. Fedora 28 is pxe-booting just fine into the desktop. openSUSE and CentOS don't, throws the error message and system halt.

Steps to reproduce the behaviour

the pxe(+ tftp + nfs + http)-server is setted up properly for that purpose. the pxe-boot menu entries look like:

LABEL fedora-x64
    MENU LABEL Fedora x64
    KERNEL http://pxe-server/nfs/fedora-x64/isolinux/vmlinuz
    INITRD http://pxe-server/nfs/fedora-x64/isolinux/initrd.img
    APPEND root=live:http://192.168.1.1/nfs/fedora-x64/LiveOS/squashfs.img ro rd.live.image rd.lvm=0 rd.luks=0 rd.md=0 rd.dm=0 vga=794 --
    TEXT HELP
        Boot to Fedora Workstation Live
    ENDTEXT

LABEL opensuse-x64
    MENU LABEL openSUSE Leap x64
    KERNEL http://pxe-server/nfs/opensuse-x64/boot/x86_64/loader/linux
    INITRD http://pxe-server/nfs/opensuse-x64/boot/x86_64/loader/initrd
    APPEND root=live:http://192.168.1.1/nfs/opensuse-x64/LiveOS/squashfs.img ro rd.live.image
    TEXT HELP
        Boot to openSUSE Leap Live
    ENDTEXT

LABEL centos-x64
    MENU LABEL CentOS x64
    KERNEL http://pxe-server/nfs/centos-x64/isolinux/vmlinuz0
    INITRD http://pxe-server/nfs/centos-x64/isolinux/initrd0.img
    APPEND root=live:http://192.168.1.1/nfs/centos-x64/LiveOS/squashfs.img ro rd.live.image
    TEXT HELP
        Boot to CentOS Live
    ENDTEXT

only Fedora is booting well. openSUSE and CentOS will fail.

my pxe-server is a Raspberry Pi and to reproduce you can use that project RPi-PXE-Server

OS and Software information

Operating system: openSUSE 15 Leap LiveDVD CentOS 7 LiveDVD

schaefi commented 6 years ago

I started to work on this

Please note I'd like to use the AOE protocol to address read-only block I/O over the network. The livenet implementation fetches the complete iso into ram which I think is not necessary.

beta-tester commented 6 years ago

the squashfs.img file of Fedora is 1.5GB and fits to the ram.

i don't know if there is an other way how Fedora/CentOS/openSUSE can handle squashfs.img... but from Debian like distributions i know that those don't load the whole squashfs file. they more mount them from the nfs and then they work with the mounted squashfs (read-only)... only loading those parts that are requested from the system/application.

compared to pxe-boot fedora and debian, debian is booted to the desktop way faster. they don't fully download the squashfs.img into ram.

maybe there is a similar mechanism, but that i don't know.

beta-tester commented 6 years ago

stupid me... while reading what i wrote in the previous comment, i changed the boot parameter of fedora from using root=live:http:... to root=live:nfs:... and nor fedora boots up similar quick as debian like distributions. so with nfs even fedora does not need to fully download the squashfs.img file into ram.

LABEL fedora-x64
    MENU LABEL Fedora x64
    KERNEL http://pxe-server/nfs/fedora-x64/isolinux/vmlinuz
    INITRD http://pxe-server/nfs/fedora-x64/isolinux/initrd.img
    APPEND root=live:nfs://192.168.1.1/srv/nfs/fedora-x64/LiveOS/squashfs.img ro rd.live.image rd.lvm=0 rd.luks=0 rd.md=0 rd.dm=0 vga=794 --
    TEXT HELP
        Boot to Fedora Workstation Live
    ENDTEXT

but openSUSE and CentOS still thow the error


dracut: don't know how to handle 'root=live:nfs://192.168.1.1/srv/nfs/opensuse-x64/LiveOS/squashfs.img'```

beta-tester commented 6 years ago

thank you for your work.

i didn't know what AOE is before. is there a practical reason, why doing a specialised unique boot method root=live:AOEINTERFACE:e0.1 rd.kiwi.live.pxe insted of using the standard mechanism root=live:nfs://192.168.1.1/srv/nfs/opensuse-x64/LiveOS/squashfs.img ro rd.live.image like described in the dracut document?

for the AOE solutions there are client/server specific dependencies that must fit on top of the normal regular pxe server requirements, otherwise pxe boot is not possible with kiwi. isn't it too unflexible unique?

EDIT: what i currently did before on the pxe-server to pxe boot a live ISO image is:

the normal pxe-server stuff (dnsmasq + tftp + nfs (+ http optional))
i mounted the ISO image as loop on the pxe-server (read-only).
nfs exported the mount point of the loop to get access to the ISO content (read-only).
added a symbolic link of the mount point to the tftp path, be accessable via tftp.

this worked well for multiple linux LiveOS distributions, even Fedora, but not openSUSE and not CentOS

schaefi commented 6 years ago

Hi,

i didn't know what AOE is before. is there a practical reason, why doing a specialised unique boot method root=live:AOEINTERFACE:e0.1 rd.kiwi.live.pxe insted of using the standard mechanism root=live:nfs://192.168.1.1/srv/nfs/opensuse-x64/LiveOS/squashfs.img ro rd.live.image like described in the [1]dracut document?

Because NFS is not AoE. The Ata Over Ethernet protocol allows to share a block layer one by one over the network. Meaning access to an iso file is not any different compared to if it would be local. NFS requires the information of the host plus a path and a file. That's why live:nfs:... makes sense. When using AoE you need to specify an interface name thus live:AOEINTERFACE:...

I tried to document it to make that clear as you can see from the pull request and also soon online here:

https://opensource.suse.com/kiwi/building/working_with_images.html

For me AoE is the better technology for this use case. If nfs should be used it's possible by just using the upstream module as I wrote in my last mail

for the AOE solutions there are client/server specific dependencies that must fit on top of the normal regular pxe server requirements, otherwise pxe boot is not possible with kiwi. isn't it too unflexible unique?

For NFS you have to provide an NFS server plus exports setup. It's pretty easy to populate an AoE file by one vblade command.

For me there is less overhead in providing a file via AoE compared to providing it via NFS

Again both solutions have their pros and cons and I don't want to force people into a direction. There is a free choice at the image creation level. From a technology point of view Ata Over Ethernet makes more sense to me, especially only block read is needed in case of the live image

Regards, Marcus -- Public Key available via: https://keybase.io/marcus_schaefer/key.asc keybase search marcus_schaefer

Marcus Schäfer (Res. & Dev.) SUSE Linux GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg HRB: 21284 (AG Nürnberg) Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton http://www.suse.de

beta-tester commented 6 years ago

hi, its me again... please can you help me. i tried to follow the steps at "Booting a Live ISO Image from Network" and run into errors on the pxe-server when trying to export an iso. (openSUSE-Leap-15.0-GNOME-Live-x86_64-Current.iso , from 2018-09-03)

u@pxe-server:~ $ sudo apt install -y vblade

u@pxe-server:~ $ sudo vbladed 0 1 INTERFACE /srv/iso/openSUSE-Leap-15.0-GNOME-Live-x86_64-Current.iso

u@pxe-server:~ $ cat /var/log/syslog
Sep  6 08:24:45 pxe-server vbladed: bind funky: No such device
Sep  6 08:24:45 pxe-server vbladed: Can't get hw addr: Bad file descriptor
Sep  6 08:24:45 pxe-server vbladed: pid 13150: e0.1, 1863680 sectors O_RDWR
Sep  6 08:24:45 pxe-server vbladed: Can't get mtu: Bad file descriptor
Sep  6 08:24:45 pxe-server vbladed: putpkt aoe id: Bad file descriptor
Sep  6 08:24:45 pxe-server vbladed: read network: Bad file descriptor

u@pxe-server:~ $ ls -la /dev/etherd/
total 0
drwxr-xr-x  2 root root    140 Sep  6 08:23 .
drwxr-xr-x 16 root root   4500 Sep  6 08:23 ..
c-w--w----  1 root disk 152, 3 Sep  6 08:23 discover
cr--r-----  1 root disk 152, 2 Sep  6 08:23 err
c-w--w----  1 root disk 152, 6 Sep  6 08:23 flush
c-w--w----  1 root disk 152, 4 Sep  6 08:23 interfaces
c-w--w----  1 root disk 152, 5 Sep  6 08:23 revalidate

AoE on the pxe-server gives the following informations:

u@pxe-server:~ $ sudo modprobe aoe

u@pxe-server:~ $ modinfo aoe
filename:       /lib/modules/4.14.62-v7+/kernel/drivers/block/aoe/aoe.ko
version:        85
description:    AoE block/char driver for 2.6.2 and newer 2.6 kernels
author:         Sam Hopkins <sah@coraid.com>
license:        GPL
srcversion:     48E7597167B2E6ABFE67504
depends:
intree:         Y
name:           aoe
vermagic:       4.14.62-v7+ SMP mod_unload modversions ARMv7 p2v8
parm:           aoe_iflist:aoe_iflist=dev1[,dev2...] (string)
parm:           aoe_dyndevs:Use dynamic minor numbers for devices. (int)
parm:           aoe_deadsecs:After aoe_deadsecs seconds, give up and fail dev. (int)
parm:           aoe_maxout:Only aoe_maxout outstanding packets for every MAC on eX.Y. (int)
parm:           aoe_maxsectors:When nonzero, set the maximum number of sectors per I/O request (int)

u@pxe-server:~ $ cat /var/log/syslog
Sep  6 08:23:14 pxe-server kernel: [209345.857961] aoe: AoE v85 initialised.

i am using a debian stretch like linux distribution on the pxe-server. do you know, what i am doing wrong?

beta-tester commented 6 years ago

d'oh!... silly me... INTERFACE must be my network interface... sorry.

beta-tester commented 6 years ago

one more silly question... the PXE menu entry must it be append ... rd.kiwi.live.pxe root=live:AOEINTERFACE=e0.1 or append ... rd.kiwi.live.pxe root=live:eth0=e0.1 or something else?

i tried to pxe-boot the openSUSE-Leap-15.0-GNOME-Live-x86_64-Current.iso , from 2018-09-03 and i still get the error

dracut: don't know how to handle 'root=live:AOEINTERFACE=e0.1'

dracut: don't know how to handle 'root=live:eth0=e0.1'

on the pxe-server:

u@pxe-server:~ $ sudo vbladed 0 1 eth0 /srv/iso/openSUSE-Leap-15.0-GNOME-Live-x86_64-Current.iso

u@pxe-server:~ $ cat /var/log/syslog
Sep  6 09:00:01 pxe-server vbladed: pid 13892: e0.1, 1863680 sectors O_RDWR

schaefi commented 6 years ago

root=live:AOEINTERFACE=e0.1

is the correct syntax.

I tried to pxe-boot the openSUSE-Leap-15.0-GNOME-Live-x86_64-Current.iso

The Leap15 live image is most probably build with the kiwi version available in Leap15. The changes done here are only available to the latest version and have not yet submitted as update to Leap15. Thus I guess this image build does not participate in the change.

You can obs branch the live project which builds openSUSE-Leap-15.0-GNOME-Live and add the Virtualization:Appliances:Builder project as repo to the kiwi config file. Your branch build will then use the latest kiwi including this feature

jirislaby commented 5 years ago

I ran into same issue. But with http as URL.

Wouldn't it be easier to add the AOEINTERFACE support to livenet+dmsquash dracut's module and use dmsquash-live instead of kiwi-live? That way, we would have a unified and dracut-documented way of PXE booting the SUSE images.

Permanent overlayfs would dracut upstream appreciate too, I would say. And CDLABEL should be handled just fine already.

Note that if I enable livenet module and rebuild the PXE initrd, booting like this works just fine (if I put aside kiwi's timeouts due to missing /run/rootfsbase):

root=live:http://192.168.1.49/openSUSE-Leap-15.0-KDE-Live-x86_64-Build-Media.iso rd.live.image rd.neednet=1

Note that the URL could be directly from download.opensuse.org and you don't have to store it locally at all.

schaefi commented 5 years ago

Wouldn't it be easier to add the AOEINTERFACE support to livenet+dmsquash dracut's module and use dmsquash-live instead of kiwi-live?

yes I think that would be the preferred solution. At the time I started to move to dracut I made sure the layout of the live ISO is compatible with livenet+dmsquash. I looked into the dracut code and found it would be relatively intrusive to add the overlayfs bits in a way that I could not make sure it does not break other stuff in there. So I decided to write that kiwi-live alternative with the background that we can drop it in the future. The problem is, I currently don't have time to drive the upstream contribution. Maybe you can open an issue on github such that we can discuss the process.

Please also have in mind, as long as the livenet+dmsquash module does not have the patch upstream we wouldn't be able to build live iso images in obs easily. So we need a transition process. Maybe a package based on current state of livenet+dmsquash including the upstream patch as long as it was not yet merged

Note that if I enable livenet module and rebuild the PXE initrd, booting like this works just fine

yes that matches the plan I had in mind, see above