Bug 672527 - Remote logging via virtio failed
Summary: Remote logging via virtio failed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedNTH
Depends On: 677713
Blocks: F15Beta-accepted, F15BetaFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2011-01-25 12:54 UTC by Hongqing Yang
Modified: 2014-09-30 23:39 UTC (History)
9 users (show)

Fixed In Version: anaconda-15.26-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-02 03:19:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
guest define xml (3.03 KB, text/plain)
2011-01-26 05:30 UTC, Hongqing Yang
no flags Details
rsyslog config file (2.66 KB, text/plain)
2011-01-26 05:31 UTC, Hongqing Yang
no flags Details
anaconda log (33.46 KB, text/plain)
2011-01-26 11:16 UTC, Hongqing Yang
no flags Details
anaconda.syslog (43.65 KB, text/plain)
2011-01-26 11:16 UTC, Hongqing Yang
no flags Details
cpuinfo (527 bytes, text/plain)
2011-01-26 11:18 UTC, Hongqing Yang
no flags Details
lsmod installer modules (1.51 KB, text/plain)
2011-01-26 12:09 UTC, Hongqing Yang
no flags Details

Description Hongqing Yang 2011-01-25 12:54:35 UTC
Description of problem:

Anaconda cannot remote logging via virtio

Version-Release number of selected component (if applicable):
anaconda 14.22

How reproducible:


Steps to Reproduce:
1. yum groupinstall virtualization, yum install anaconda
2. create guest via virt-manager
3. Force off and edit <guestname> via  virsh, add script below:
<channel type='tcp'>
  <source mode='connect' host='127.0.0.1' service='6080'/>
  <target type='virtio' name='org.fedoraproject.anaconda.log.0'/>
</channel>

dumpxml <guestname>, it shows channel has been added as below:

    <channel type='tcp'>
      <source mode='connect' host='127.0.0.1' service='6080'/>
      <protocol type='raw'/>
      <target type='virtio' name='org.fedoraproject.anaconda.log.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='0'/>
    </channel>

4. eval `./analog -p 6080 ./home/hongqing/logs  -o rsyslogd.conf -s`
5. start guest and finish installation
  
Actual results:
There is no logs in /home/hongqing/logs, and directory /home/hongqing/logs is create under anaconda, it does not recognize /home as the user's home.
only two logs in /home/hongqing/logs  

Expected results:
guest installation logs are in directory /home/hongqing/logs

Additional info:
org.fedoraproject.org.anaconda.log.0  exists under /dev/virtio-ports/ on guest
ryslog.conf can be found in enclosure.

host rsyslog service with port 6080 status is below:
tcp        0      0 0.0.0.0:6080     0.0.0.0:*      LISTEN      31763/rsyslogd      
tcp        0      0 :::6080             :::*        LISTEN      31763/rsyslogd 

after installation, if the port 6080 is not open, the guest cannot start

Comment 1 Ales Kozumplik 2011-01-25 14:14:16 UTC
Hi,

(In reply to comment #0)
>     <channel type='tcp'>
>       <source mode='connect' host='127.0.0.1' service='6080'/>
>       <protocol type='raw'/>
>       <target type='virtio' name='org.fedoraproject.anaconda.log.0'/>
>       <address type='virtio-serial' controller='0' bus='0' port='0'/>
>     </channel>

this looks correct. Mine looks:

    <channel type='tcp'>
      <source mode='connect' host='127.0.0.1' service='6080'/>
      <protocol type='raw'/>
      <target type='virtio' name='org.fedoraproject.anaconda.log.0'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='0'/>
    </channel>

so I have an extra alias tag, but that should not be important.

> 4. eval `./analog -p 6080 ./home/hongqing/logs  -o rsyslogd.conf -s`

Look at the dot in front of the logs path: it says the path behind it is relative to your current working directory (which in your case is /usr/libexec/anaconda). This concept is heavily used in the linux shell, see also http://www.linfo.org/current_directory.html.

To do what you want to do just give analog the absolute path, for instance:
./analog -p 6080 /home/hongqing/logs  -o rsyslogd.conf -s

> There is no logs in /home/hongqing/logs, and directory /home/hongqing/logs is
> create under anaconda, it does not recognize /home as the user's home.
> only two logs in /home/hongqing/logs  

You say you only can see two log files and they are almost empty. This would point to the fact that the sending side of the communication (that is the guest machine) does not write anything into the virtio port. This can be for two reasons:

1) /dev/virtio-ports/org.fedoraproject.anaconda.1 does not exist on guest (but you confirmed in a previous email it did exist)
2) the communication is not forwarded to the destination tcp port on the host for some reason. You can check if this is the case by running 'nc -l 0.0.0.0 6080' and then starting the guest. The terminal where you started nc should get filled quickly with the raw debug messages.

> Additional info:
> org.fedoraproject.org.anaconda.log.0  exists under /dev/virtio-ports/ on guest
> ryslog.conf can be found in enclosure.

I think you forgot to attach it.

Comment 2 Ales Kozumplik 2011-01-25 14:21:29 UTC
Also when I'm thinking about it: what distro are you trying to install? What is the anaconda version there?

Comment 3 Hongqing Yang 2011-01-26 05:30:27 UTC
Created attachment 475329 [details]
guest define xml

Comment 4 Hongqing Yang 2011-01-26 05:31:19 UTC
Created attachment 475330 [details]
rsyslog config file

Comment 5 Hongqing Yang 2011-01-26 05:45:21 UTC
Hi, Ales

The Anaconda version is 14.22, and both the host and guest are Fedora 14.

I have used eval `./analog -p 6080 /home/hongqing/logs  -o rsyslogd.conf -s`, it works fine.

I has opened port use nc -l 0.0.0.0 6080 as you said above, and start the guest, there is nothing output on the terminal. if I do not open it, the guest will give error:
Error starting domain: internal error Process exited while reading console log output: char device redirected to /dev/pts/2
inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,6080): Connection refused
chardev: opening backend "socket" failed

so i think the guest has already tried to connect with the host on port 6080.

one thing different is, under the guest  /dev/virtio-ports/ is org.fedoraproject.anaconda.log.0, not org.fedoraproject.anaconda.1

Comment 6 Ales Kozumplik 2011-01-26 09:33:55 UTC
(In reply to comment #5)
> Hi, Ales
> 
> The Anaconda version is 14.22, and both the host and guest are Fedora 14.

ok, that is my setup, so it should work.

> I have used eval `./analog -p 6080 /home/hongqing/logs  -o rsyslogd.conf -s`,
> it works fine.

ok, we have that figured out.

> I has opened port use nc -l 0.0.0.0 6080 as you said above, and start the
> guest, there is nothing output on the terminal. if I do not open it, the guest
> will give error:
> Error starting domain: internal error Process exited while reading console log
> output: char device redirected to /dev/pts/2
> inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,6080): Connection refused
> chardev: opening backend "socket" failed

this shows us that we have the port number and everything right, but yet we see no messages coming in. Either
1) the rsyslog on the guest side doesn't write anything into the port, or
2) your kvm/virtio is simply broken for some reason.

To decide between these two explanations, can you please:
1) start nc on the host as described above
2) start the guest, wait until the stage2 GUI comes up.
3) on the guest: ctrl-alt-f2 to switch to the terminal, 
4) then 'killall rsyslogd' 
5) try to write something into the port manually, like:
echo "hi host" > /dev/virtio-ports/org.fedoraproject.anaconda.log.0

the message 'hi host' should appear the the terminal where you started nc. Does that happen? If yes: please attach /etc/rsyslog.conf from the guest to this BZ. You can copy it out of the installer using scp, in a manner similar to what is described here:
http://fedoraproject.org/wiki/Anaconda/Logging#Logging_tips

Thanks.

> one thing different is, under the guest  /dev/virtio-ports/ is
> org.fedoraproject.anaconda.log.0, not org.fedoraproject.anaconda.1

Sorry, my bad, it should always be /dev/virtio-ports/org.fedoraproject.anaconda.log.0.

Comment 7 Hongqing Yang 2011-01-26 10:35:15 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Hi, Ales
> > 
> > The Anaconda version is 14.22, and both the host and guest are Fedora 14.
> 
> ok, that is my setup, so it should work.
> 
> > I have used eval `./analog -p 6080 /home/hongqing/logs  -o rsyslogd.conf -s`,
> > it works fine.
> 
> ok, we have that figured out.
> 
> > I has opened port use nc -l 0.0.0.0 6080 as you said above, and start the
> > guest, there is nothing output on the terminal. if I do not open it, the guest
> > will give error:
> > Error starting domain: internal error Process exited while reading console log
> > output: char device redirected to /dev/pts/2
> > inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,6080): Connection refused
> > chardev: opening backend "socket" failed
> 
> this shows us that we have the port number and everything right, but yet we see
> no messages coming in. Either
> 1) the rsyslog on the guest side doesn't write anything into the port, or
> 2) your kvm/virtio is simply broken for some reason.
> 
> To decide between these two explanations, can you please:
> 1) start nc on the host as described above
> 2) start the guest, wait until the stage2 GUI comes up.
> 3) on the guest: ctrl-alt-f2 to switch to the terminal, 
> 4) then 'killall rsyslogd' 
> 5) try to write something into the port manually, like:
> echo "hi host" > /dev/virtio-ports/org.fedoraproject.anaconda.log.0
> 
> the message 'hi host' should appear the the terminal where you started nc. Does
> that happen? If yes: please attach /etc/rsyslog.conf from the guest to this BZ.
> You can copy it out of the installer using scp, in a manner similar to what is
> described here:
> http://fedoraproject.org/wiki/Anaconda/Logging#Logging_tips
> 
> Thanks.
> 
> > one thing different is, under the guest  /dev/virtio-ports/ is
> > org.fedoraproject.anaconda.log.0, not org.fedoraproject.anaconda.1
> 
> Sorry, my bad, it should always be
> /dev/virtio-ports/org.fedoraproject.anaconda.log.0.


Ales,

I tried what u said above, there is no /dev/virtio-ports/org.fedoraproject.anaconda.log.0 during the installation,  after installation, rebooting the guest, it comes, it seems this is the point of the problem.

Comment 8 Ales Kozumplik 2011-01-26 10:48:01 UTC
(In reply to comment #7)> 
> Ales,
> 
> I tried what u said above, there is no
> /dev/virtio-ports/org.fedoraproject.anaconda.log.0 during the installation, 
> after installation, rebooting the guest, it comes, it seems this is the point
> of the problem.

Allright. That sounds like anaconda is not loading the required virtio module. Can you please attach /tmp/anaconda.log, /tmp/syslog and contents of /proc/cpuinfo to this bug?

Comment 9 Hongqing Yang 2011-01-26 11:16:00 UTC
Created attachment 475368 [details]
anaconda log

Comment 10 Hongqing Yang 2011-01-26 11:16:51 UTC
Created attachment 475370 [details]
anaconda.syslog

Comment 11 Hongqing Yang 2011-01-26 11:18:42 UTC
Created attachment 475371 [details]
cpuinfo

Comment 12 Ales Kozumplik 2011-01-26 11:45:53 UTC
this is going to be difficult: the logs do not help as much since the part where anaconda enables the virtio logging of course has to happen before we initialize logging (and before we get the first logging messages).

Can you paste the output of 'lsmod' from the installer? Also you say that the virtio port device is missing during install: what happens if you manually do 'modprobe virtio_pci' from the install? Does the virtio port appear?

Comment 13 Ales Kozumplik 2011-01-26 11:47:28 UTC
> I tried what u said above, there is no
> /dev/virtio-ports/org.fedoraproject.anaconda.log.0 during the installation, 
> after installation, rebooting the guest, it comes, it seems this is the point
> of the problem.

Hm. What if you just reboot the machine after stage2 starts and let it boot into the installer again? Can you see the virtio ports then?

Comment 14 Hongqing Yang 2011-01-26 12:09:43 UTC
Created attachment 475378 [details]
lsmod installer modules

Comment 15 Hongqing Yang 2011-01-26 12:21:49 UTC
The module modprobe virtio_pci has been loaded, if I modprobe virtio_pci, nothing happens. there is still no /virtio-ports/ folder.

I see there are some modules should be loaded as stated in analog, such as imtcp.so and imuxsock. I cannot find the rsyslog folder and these two  modules.
 


(In reply to comment #12)
> this is going to be difficult: the logs do not help as much since the part
> where anaconda enables the virtio logging of course has to happen before we
> initialize logging (and before we get the first logging messages).
> 
> Can you paste the output of 'lsmod' from the installer? Also you say that the
> virtio port device is missing during install: what happens if you manually do
> 'modprobe virtio_pci' from the install? Does the virtio port appear?

Comment 16 Hongqing Yang 2011-01-26 12:23:17 UTC
(In reply to comment #13)
> > I tried what u said above, there is no
> > /dev/virtio-ports/org.fedoraproject.anaconda.log.0 during the installation, 
> > after installation, rebooting the guest, it comes, it seems this is the point
> > of the problem.
> 
> Hm. What if you just reboot the machine after stage2 starts and let it boot
> into the installer again? Can you see the virtio ports then?


Hi, Ales,

I have tested that, after I reboot, a new id will be assigned to the guest. and also it does not make sense.

Comment 17 Ales Kozumplik 2011-01-26 12:38:37 UTC
(In reply to comment #15)
> The module modprobe virtio_pci has been loaded, if I modprobe virtio_pci,
> nothing happens. there is still no /virtio-ports/ folder.

note that we are looking for /dev/virtio-ports folder.

and how come you say it does not exist on the guest when you said in Comment #0 it does?:
> Additional info:
> org.fedoraproject.org.anaconda.log.0  exists under /dev/virtio-ports/ on guest

> I see there are some modules should be loaded as stated in analog, such as
> imtcp.so and imuxsock. I cannot find the rsyslog folder and these two  modules.
> 
> 

have you got rsyslog rpm installed on the host? or are you talking about the guest?

Comment 18 Hongqing Yang 2011-01-26 15:07:50 UTC
(In reply to comment #17)
> (In reply to comment #15)
> > The module modprobe virtio_pci has been loaded, if I modprobe virtio_pci,
> > nothing happens. there is still no /virtio-ports/ folder.
> 
> note that we are looking for /dev/virtio-ports folder.
> 
> and how come you say it does not exist on the guest when you said in Comment #0
> it does?:
/dev/virtio-ports  does not exits during installation, after installation finished and system reboots, perform the post installation configuration steps, the folder /dev/virtio-ports exits.
> > Additional info:
> > org.fedoraproject.org.anaconda.log.0  exists under /dev/virtio-ports/ on guest
> 
> > I see there are some modules should be loaded as stated in analog, such as
> > imtcp.so and imuxsock. I cannot find the rsyslog folder and these two  modules.
> > 
> > 
> 
> have you got rsyslog rpm installed on the host? or are you talking about the
> guest?

please ignore this. the modules imtcp and imuxsock is under folder /usr/lib64, I only checked /usr/lib.
sorry for the inconvenience.

Comment 19 Ales Kozumplik 2011-01-26 16:30:47 UTC
OK,

I am running out of ideas here. In your email from yesterday you mention that you use the following steps to add the virtio channel:

> 1. use virt-manager create a guest from a local iso image
> 2. at the step  starting bios, I pause it.
>    virsh -c qemu:///system
>    edit <machinename>
>    paste the script below in the <devices> section
> 
> <channel type='tcp'>
>   <source mode='connect' host='127.0.0.1' service='6080'/>
>   <target type='virtio' name='org.fedoraproject.anaconda.log.0'/>
> </channel>

Are you still doing that? Because adding the channel after the machine was started would not cause it to see the new channel! That's why I asked what happens if you reboot into the same installation again in comment 13. Please try that and tell me if you can see the virtio ports. I am regularly rebooting the same virtual machine into installation many times, without touching its .xml definition (sometimes in virt-manager you need to change the booting order back to the cd media or pxe or what you have).

Comment 20 Hongqing Yang 2011-01-27 03:08:18 UTC
(In reply to comment #19)
> OK,
> 
> I am running out of ideas here. In your email from yesterday you mention that
> you use the following steps to add the virtio channel:
> 
> > 1. use virt-manager create a guest from a local iso image
> > 2. at the step  starting bios, I pause it.
> >    virsh -c qemu:///system
> >    edit <machinename>
> >    paste the script below in the <devices> section
> > 
> > <channel type='tcp'>
> >   <source mode='connect' host='127.0.0.1' service='6080'/>
> >   <target type='virtio' name='org.fedoraproject.anaconda.log.0'/>
> > </channel>
> 
> Are you still doing that? Because adding the channel after the machine was
> started would not cause it to see the new channel! That's why I asked what
> happens if you reboot into the same installation again in comment 13. Please
> try that and tell me if you can see the virtio ports. I am regularly rebooting
> the same virtual machine into installation many times, without touching its
> .xml definition (sometimes in virt-manager you need to change the booting order
> back to the cd media or pxe or what you have).

Hi, Ales
I realized it was wrong to pause and resume, I have replied you in the following email. 
Now What I doing is exactly the same with the description, Force off it, edit the xml, change boot option to cdrom, dumpxml guest, I can see channel is in the xml, then I start it to install, after installation, change boot option to hd. And also I  have tried to restart it.

The rsyslogd on guest and host are running.

Comment 21 Hongqing Yang 2011-01-27 05:13:42 UTC
One funny thing happens, just now I tried to install Fedora 14 i386, It works fine, but I try the Fedora 14 x86_64, it still  does not work.
The host is Fedora 14 x86_64.

Comment 22 Hongqing Yang 2011-01-27 09:39:37 UTC
I have downloaded the Fedora 14 x86_64 from a different mirror, the situation is the same.

Comment 23 Ales Kozumplik 2011-01-27 10:38:35 UTC
Doh!

now I see that this is really the case with all x86_64 composes: it is so because virtio logging needs virtio_console kernel module. On i386 (where I usually test), this is built in the kernel so I never came across the necessity to pull it in.

Will fix this for rawhide (F15), if you want to use virtio remote logging on F14 you will have to stick with i386.

Thanks for helping in debugging this.

Comment 24 Ales Kozumplik 2011-01-27 12:10:34 UTC
please leave this opened until I commit the fix.

Comment 25 Hongqing Yang 2011-01-31 02:55:18 UTC
Hi, Ales,

I have tested the F15 rawhide, it seems still not work on F15 rawhide x86_64.

Comment 26 Ales Kozumplik 2011-02-16 09:19:20 UTC
Just an update on the status: there's my patch waiting for review: https://www.redhat.com/archives/anaconda-devel-list/2011-February/msg00055.html

but a colleague who was reviewing it decided to try to get kernel make the virito_console module built-in just like on i386: see bug 677713.

Waiting for how that bug will be resolved now. This change is not going to make F15 since it's hard to be seen as a blocker.

Comment 27 James Laska 2011-02-16 19:16:09 UTC
(In reply to comment #26)
> Waiting for how that bug will be resolved now. This change is not going to make
> F15 since it's hard to be seen as a blocker.

I agree this isn't a blocker for F15 Alpha, but we have *plenty* of time for F15 Final.  While this isn't critical for any release criteria, this definitely fits the NICE-TO-HAVE criteria [1] since we'd like to use this for our install automation.  How long do you anticipate patch reviews will take, do you expect this support will be available for F15 Beta or Final?

This only fails on i386 right?  We can still explore our proof-of-concept virtio logging with x86_64, right?

[1] http://fedoraproject.org/wiki/QA:SOP_nth_bug_process

Comment 28 Ales Kozumplik 2011-02-17 08:34:52 UTC
> I agree this isn't a blocker for F15 Alpha, but we have *plenty* of time for
> F15 Final.  While this isn't critical for any release criteria, this definitely
> fits the NICE-TO-HAVE criteria [1] since we'd like to use this for our install
> automation.  How long do you anticipate patch reviews will take, do you expect
> this support will be available for F15 Beta or Final?

There's just been an update from kernel. See https://bugzilla.redhat.com/show_bug.cgi?id=677713#c2.

Can you guys retest on x86_64 f15 after kernel-2.6.38-0.rc5.git1.1.fc15 ?

If it works we can close this (and I don't need a review for the patch).

> 
> This only fails on i386 right?  We can still explore our proof-of-concept
> virtio logging with x86_64, right?

The other way round: this only fails on x86_64 and works on i386. So you can already try this out on i386 (see comment 21 and comment 23).

Comment 29 Amit Shah 2011-02-18 07:59:02 UTC
I'd suggest to attempt to load the virtio-console module in any case.  This will prevent such incidences with other architectures and distributions.

Comment 30 Ales Kozumplik 2011-02-18 08:14:36 UTC
There's one more thing why a built-in module is more useful: if it is not, and we modprobe it manually, the virito device doesn't appear right after the modprobe returns but a second or two later. This means we need that ugly sleep()y loop in anaconda to wait for it to come up: if the user did not start a machine that actually has any virtio channels (which we can only know after the timeout) this wait is a waste of time.

I also witnessed some random freezes shortly after this point in anaconda's loader with my proposed patch. But that might have been something else.

Comment 31 Hongqing Yang 2011-02-22 08:17:50 UTC
(In reply to comment #28)
> > I agree this isn't a blocker for F15 Alpha, but we have *plenty* of time for
> > F15 Final.  While this isn't critical for any release criteria, this definitely
> > fits the NICE-TO-HAVE criteria [1] since we'd like to use this for our install
> > automation.  How long do you anticipate patch reviews will take, do you expect
> > this support will be available for F15 Beta or Final?
> 
> There's just been an update from kernel. See
> https://bugzilla.redhat.com/show_bug.cgi?id=677713#c2.
> 
> Can you guys retest on x86_64 f15 after kernel-2.6.38-0.rc5.git1.1.fc15 ?
> 
> If it works we can close this (and I don't need a review for the patch).
> 
> > 
> > This only fails on i386 right?  We can still explore our proof-of-concept
> > virtio logging with x86_64, right?
> 
> The other way round: this only fails on x86_64 and works on i386. So you can
> already try this out on i386 (see comment 21 and comment 23).

just tested on f15-alpha-rc1 with kernel version 2.6.38-0.rc5.git1.1.fc15, it still does not work.

Comment 32 Ales Kozumplik 2011-02-22 08:50:32 UTC
> just tested on f15-alpha-rc1 with kernel version 2.6.38-0.rc5.git1.1.fc15, it
> still does not work.

Hongqing, what architecture is that?

Thanks.

Comment 33 Hongqing Yang 2011-02-22 08:59:12 UTC
still X86_64

Comment 34 Ales Kozumplik 2011-02-22 10:22:26 UTC
I checked the kernel, seems not fixed still:
https://bugzilla.redhat.com/show_bug.cgi?id=677713#c4

Let's wait for what they have to say.

Comment 35 Ales Kozumplik 2011-02-28 07:02:23 UTC
Hongqing,

please see https://bugzilla.redhat.com/show_bug.cgi?id=677713#c6 and test with the kernel version mentioned there (not sure if it's going to make f15 or just rawhide).

Thanks.

Comment 36 Hongqing Yang 2011-03-02 09:55:24 UTC
Ales, 

I have tested the kernel  2.6.38-0.rc6.git6.1.fc15.x86_64, now the port org.fedoraproject.anaconda.log.0 is created during installation.  It can also communicate with the host by doing like below:
echo "hello host" > org.fedoraproject.anaconda.log.0.
But the virtio_pci module is not loaded, the logs are still not forwarded to the host.

Comment 37 Amit Shah 2011-03-02 10:19:03 UTC
(In reply to comment #36)
> Ales, 
> 
> I have tested the kernel  2.6.38-0.rc6.git6.1.fc15.x86_64, now the port
> org.fedoraproject.anaconda.log.0 is created during installation.  It can also
> communicate with the host by doing like below:
> echo "hello host" > org.fedoraproject.anaconda.log.0.

If this works, the communication part works alright.

> But the virtio_pci module is not loaded, the logs are still not forwarded to
> the host.

That's now built into the kernel, you won't see modules for virtio-pci and virtio-console.

Comment 38 Ales Kozumplik 2011-03-07 15:30:14 UTC
Amit,

With the new kernel I found out that the devices appear at the point where the anaconda loader makes udevadm settle all devices, many modules are loaded then.

What specific modules do I need to load for the device to appear very soon after boot (we need the logging much sooner than when we can actually start calling udev)? I tried manually loading virtio_net and virtio_blk, but that's not enough.

Thanks.
Ales

Comment 39 Amit Shah 2011-03-08 05:30:28 UTC
The module can get loaded pretty soon, but for the /dev/virtio-ports/... files to appear, udev needs to be around.  That's because udev rules create the entries in /dev/virtio-ports/.

Comment 40 James Laska 2011-03-08 12:36:13 UTC
Thanks Ales, Amit and Hongqing.

Proposing as a nice-to-have (NTH) fix for Fedora 15 Beta.  This isn't a high profile feature where many users will be impacted, but this does restrict the installation automation work Hongqing has been doing.  Having virtio logging on both architectures during virt-installs will help us move to the next step with regards to installation automation.  I support this as a NTH.

Comment 41 Ales Kozumplik 2011-03-08 14:14:29 UTC
Patch awaiting review:
https://www.redhat.com/archives/anaconda-devel-list/2011-March/msg00114.html

Comment 42 Ales Kozumplik 2011-03-09 08:41:33 UTC
Fixed in F15: 
Fixed on master: de3d6e5538ca851a261492924ff80585db7ab455.

Comment 43 Adam Williamson 2011-03-11 19:02:21 UTC
Discussed at 2011-03-11 blocker/NTH review meeting. Agreed this is accepted as nice-to-have due to impact on QA's automated installation testing process.

Comment 44 Fedora Update System 2011-03-29 20:59:31 UTC
anaconda-15.26-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/anaconda-15.26-1.fc15

Comment 45 Fedora Update System 2011-03-30 02:26:28 UTC
Package anaconda-15.26-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-15.26-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/anaconda-15.26-1.fc15
then log in and leave karma (feedback).

Comment 46 Hongqing Yang 2011-04-02 03:19:10 UTC
fixed on anaconda 15.19 and kernel-2.6.35.11-83.fc14.x86_64.

Comment 47 Fedora Update System 2011-04-05 21:38:19 UTC
anaconda-15.26-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.