autodetection needs to be fixed: - stage1 - rescue (drvinst/mount partitions/...) - stage2 installer - running system (udev?) check xenbus and find out if this somehow autoloads required modules and there's also the xen platform device... Reproducible: Steps to Reproduce:
Assignee: bugsquad => alien
CC: (none) => alien, mageia, thierry.vignaud, tmb
Fixed (tested stage1 fetching stage2 from net + stage2 installing on hd) stage1 fetching stage2 from hd is known to be broken but that's not such an usefull case for virtualising
Status: NEW => RESOLVEDResolution: (none) => FIXED
is this due to stage1 not having xen-blkfront autodetected/loaded ? did you select the module xen-netfront manually, or chose a different driver? or wrote some code that detects xen-netfront like it does virtio ? or it's been compiled in kernel, or does it actually load from udev? or ... ? i'm interested in the how... btw: if you wrote detection code, you could load xen-blkfront together with xen-netfront...
ldetect: http://svnweb.mageia.org/soft?view=revision&revision=7728 stage1: http://svnweb.mageia.org/soft?view=revision&sortby=date&revision=7731 stage2: http://svnweb.mageia.org/soft?view=revision&sortby=date&revision=7732 http://svnweb.mageia.org/soft?view=revision&sortby=date&revision=7733 rescue would need sg like this in rc.sysinit: if [ -e /sys/bus/xen/ ]; then modprobe xen-blkfront modprobe xen-netfront fi
http://svnweb.mageia.org/soft/drakx/trunk/perl-install/detect_devices.pm?sortby=date&r1=7732&r2=7731&pathrev=7732 & http://svnweb.mageia.org/soft/drakx/trunk/perl-install/detect_devices.pm?sortby=date&r1=7733&r2=7732&pathrev=7733 may not be 100% completely correct... xen-blkfront driver can have hdX/sdX/xvdX and it can even be directed from the xen guest configuration: http://xenbits.xen.org/docs/4.2-testing/misc/xl-disk-configuration.txt (see vdev section)
media_type is a drakx field and we only put 'hd' for hard disks. Anything else means they won't be recognized as hd. as for the first one, if xen presents them as regulard ide/scsi disks, they should be detected the regular way. this piece of code is only for paravirtualized block devices, not for emulated ones.
yes, but in paravirtualised drivers, you can choose the device name in the configuration, and it uses that device... you can pick xvda or sda or hda in paravirtualisation and it will use that one due to the net-blkfront driver...
to clarify, this could mean that hda or sda could need xen-blkfront, it's not because it's hda or sda that it's emulated device... pv device doesn't mean you're limited to using xvdX
Feel free to test :-)
will do, (if i don't forget)
stage1 worked for me. but i've heard from a user on IRC that he gets a message in installer: "insmod: xen-blkfront failed" or something similar... problem is, he has a nonxen physical machine, so something is wrong there.
i forgot to mention he used nonfree boot.iso
reopening the bug for that... rescue should indeed also have some kind of xen-blkfront during drvinst or something not sure this is to be in rc.sysinit though...
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
rebuilding rescue with latest ldetect should be enough
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
@tv: btw: are you sure to close this? i reopened because some user reports that a netinstall on a physical machine (NO XEN) reports in the beginning of stage2 that "xen-blkfront fails to insmod"
Created attachment 3694 [details] Xen netinstall xvda alt F3 installation on HVM failed with this errormessage
Created attachment 3695 [details] Xen netinstall xvda alt F4
these IO errors look pretty weird... and cannot find superblock things... xen-blkfront was loaded... i used LVM as backend
Assignee: alien => thierry.vignaud
Please don't mix issues. This is another issue. Open another bug report.
(In reply to AL13N from comment #14) probing xen-*front on bare metal is fixed with new ldetect