FC13 Virt Win XP guest
Hi all, I've set up FC13 64bit on a machine with an intel i7 and 4G memory I'm trying to get a simple virtualisation to work. I followed the instructions here - http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Installing_Windows_XP_as_a_fully_virtualized_guest.html The install of XP runs fine but when it reboots to run the GUI part of the install I get this message in the VM's console:- Booting from Hard Disk: A disk read error occurred Press Ctrl-Alt-Del to restart It almost seems that the XP boot loader can't find the virtual disk. I must have missed something obvious - but what? Thanks for any pointers Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: FC13 Virt Win XP guest
Suvayu Ali wrote: On Thursday 10 June 2010 12:31 AM, Ken Smith wrote: Suvayu Ali wrote: On Thursday 10 June 2010 12:18 AM, Ken Smith wrote: Hi all, I've set up FC13 64bit on a machine with an intel i7 and 4G memory I'm trying to get a simple virtualisation to work. I followed the instructions here - http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Installing_Windows_XP_as_a_fully_virtualized_guest.html The install of XP runs fine but when it reboots to run the GUI part of the install I get this message in the VM's console:- Booting from Hard Disk: A disk read error occurred Press Ctrl-Alt-Del to restart Pick boot from CD and reboot, it will fix itself. I also ran into this yesterday. I'm installing from an ISO image of the XP install CD. Won't that just kick off the install from the start over again? I was installing from a CD, so I went to the hardware details tab and selected the CD ROM drive in boot options as the boot device. I know this sounds stupid, but it worked then. However after your email I tried to check whether it can still boot. (of course after changing the boot device to something appropriate) But its stuck at Booting from Hard Disk I will try again when I have some time this weekend. This might also be a valid bug as I got this SElinux error every time I started a VM in virt manager. Summary: SELinux is preventing /usr/bin/qemu-kvm write access on sr0. I am sorry my response is not very precise. I 'll look into this in more detail when I have more time. Ken GL resolving this Despite my doubts I tried the boot from CD option as you suggested. It works. The GUI part of install then concludes. But the virtual machine won't boot if I switch it to boot from hard disk. So I've left it set as boot from CD for the moment and just ignore its press any key prompt. A bit of a kludge but its working. :-) Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: FC13 Virt Win XP guest
suvayu ali wrote: On 11 June 2010 13:02, Ken Smith k...@kensnet.org wrote: Suvayu Ali wrote: I was installing from a CD, so I went to the hardware details tab and selected the CD ROM drive in boot options as the boot device. I know this sounds stupid, but it worked then. However after your email I tried to check whether it can still boot. (of course after changing the boot device to something appropriate) But its stuck at Booting from Hard Disk Despite my doubts I tried the boot from CD option as you suggested. It works. The GUI part of install then concludes. But the virtual machine won't boot if I switch it to boot from hard disk. So I've left it set as boot from CD for the moment and just ignore its press any key prompt. A bit of a kludge but its working. Since this is reproducible, its definitely a bug. I'll try to file a bug report over the weekend. Sometimes bugs can be unbelievably weird. :-p :-) Ken Indeed - I'll cross post this to virt list :-) Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
cgi perl selinux question
Hi All, I'm setting up a cgi application (the Web part of the MythTV application). I'd like to try to run it with SELINUX enabled if possible. The perl script writes to STDOUT and it produces a SELINUX error that recommends executing this command chcon -t httpd_sys_content_t 'stdout' How do I set the Selinux context of the stdout stream for an apache session? Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: qemu update for fc13 broken?
Bill Davidsen wrote: Bill Davidsen wrote: compdoc wrote: Keyboard works, mouse doesn't. Does that give you any clues? I'm using qemu-kvm 0.14.0, and I have to run the command like this or neither the mouse or keyboard works: qemu-kvm -m 512 -hda svr.img -soundhw ac97 -k en-us -usbdevice tablet Have not previously used the tablet option for console, only for VNC operation. So if that solves the problem it will be new behavior (I'll take it as workaround if it works, though). I'll report after I try it, been a long day. Using the tablet option restores functionality, although it's not clear why anything was deliberately changed with the recent qemu update. I tested on a number of VMs, including the new Scientific Linux (similar to CentOS) release. Works perfectly, both the screen and the SL-6.0 release. Going on a few servers next week for real testing. This might be related. On my FC13 system, on 22 Mar, qemu went from qemu-common-0.12.5-1.fc13.x86_64 to - qemu-common-0.13.0-1.fc13.x86_64 After that update an XP vm no longer boots. Win 7 and Centos VM's are fine. The XP vm was installed with the work-around of booting from an iso image of the XP install disk and being allowed to time out and then starting the system on the hard disk image. The XP install image will boot and the XP repair option that appears early in the XP install sequence can mount the disk. It's native fixmbr/fixboot commands don't help. If I attach the xp vm's disk to the Win 7 vm all the files are visible. Any suggestions Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: qemu update for fc13 broken?
Ken Smith wrote:
{snip}
This might be related. On my FC13 system, on 22 Mar, qemu went from
qemu-common-0.12.5-1.fc13.x86_64 to - qemu-common-0.13.0-1.fc13.x86_64
After that update an XP vm no longer boots. Win 7 and Centos VM's are
fine. The XP vm was installed with the work-around of booting from an
iso image of the XP install disk and being allowed to time out and then
starting the system on the hard disk image. The XP install image will
boot and the XP repair option that appears early in the XP install
sequence can mount the disk. It's native fixmbr/fixboot commands don't help.
If I attach the xp vm's disk to the Win 7 vm all the files are visible.
Any suggestions
Thanks
Ken
Update: I have installed new XP guest system and copied the whole
filesystem from the non-booting one over the new XP filesystem and it
now boots fine without the workaround of booting via the XP install iso
image. XP had a bit of a tantrum over its own activation process but
that is OK now.
:-) Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
FC13 PS2 Mouse/Keyboard stops working after a while
Hi, I've seem problems like this reported in various forums. I have a i7 Asus MB system with FC13 x64 and I'm using a PS2 keyboard and mouse. They are old but they work well. After the machine has been running for around 10-15 mins all input from the keyboard and mouse fails. The system keeps running, X updates, I can ssh into the machine and if I plug in a USB mouse that works. I have found that if I put the system into suspend or hibernate prior to the failure then on return from hibernate or suspend the PS2 mouse/keyboard work for long periods as normal. The problem is that I have some other hardware that does not work all that well after suspend/hibernate and so I can have either that hardware (M-Audio 1010) working and the mouse at risk of failing or the 1010 not working. Are there some diagnostic steps I could do. I have run the machine in RL3 and the keyboard seams to stay working. So maybe this is an issue with X. I'm using the nVidia binary blob driver but the problem was there with the nouveau driver. Maybe the driver for the PS2 device is suspect??? Any ideas? Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: FC13 PS2 Mouse/Keyboard stops working after a while
Joe Zeff wrote: On 04/05/2011 02:14 PM, Ken Smith wrote: So maybe this is an issue with X. I'm using the nVidia binary blob driver but the problem was there with the nouveau driver. You need to understand that the nVidia driver has to be re-installed every time the kernel is updated. My advice is go here and follow the instructions for installing the Fedora version of the drivers: http://forums.fedoraforum.org/showthread.php?t=204752 If you go the basic route with kmod-nvidia, the kmod will generally update at about the same time as the kernel; if not, don't try the new kernel until it does, generally within a day or so. If you use akmod-nvidia, it will build a new kmod on the fly at boot if needed. It does, however, need the appropriate kernel-devel package installed and for some reason, it's not properly listed as a dependency. I don't know why Leigh didn't mention that in his guide, but you only need to worry about it once, because that gets updated along with the kernel. Don't forget that once you've done the installation, you need to get into init 3 and uninstall the binary blob before rebooting into X. Sorry my bad explanation - I'm using kmod-nvidia. But, as I said, the problem pre existed my use of the nvidia driver. Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: FC13 PS2 Mouse/Keyboard stops working after a while
compdoc wrote: The problem is that I have some other hardware that does not work all that well after suspend/hibernate and so I can have either that hardware (M-Audio 1010) working and the mouse at risk of failing or the 1010 not working. So what you're saying is, while the M-Audio 1010 is working the ps/2 stuff fails, and when the M-Audio 1010 has stopped working due to suspend/hibernate the PS/2 stuff works fine. Coincidence? I find it odd that anything would interfere with a ps/2 keyboard, since it's on such a low and well known IRQ. Keyboard is 1 and mouse is 12. APIC is enabled in the bios? It is odd as PS2 interfaces and 8042's are as old as the hills. Following your reply I monitored /proc/interrupts (via a remote ssh session) and I can see the count of keyboard interrupts rising on CPU2 and the mouse ones on CPU3. When the failure occurs the counts stop rising. If I suspend/resume the machine the count then rises again as the PS2 devices are working once more. So it seems like the 8042 stops interrupting the processor, or the processor/apic is ignoring them, or something along those lines. The evidence is that keyboard mouse cease functioning and the interrupt count stops rising. Noticeable things about this are:- * The fault only occurs with X running * Both keyboard and mouse are affected * USB mouse still works * Fault vanishes after suspend/resume * cpu0 has a few interrupts logged and then the count rises on cpu2 (keyboard) and cpu3 (mouse) As far as I can see there are no APIC settings in the BIOS on this motherboard I did notice that one of my two Delta 1010's share an interrupt with the video card so I will need to move that card to another slot xorg.conf includes Section InputDevice # generated from data in /etc/sysconfig/keyboard Identifier Keyboard0 Driver keyboard Option XkbLayout gb Option XkbModel pc105 EndSection Section InputDevice # generated from default Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Cat'ing /dev/input/mice produces a stream of characters. I was waiting for the system to fail while doing that before sending this message but the mouse/keyboard are still working. Its Heisenberg's Uncertainty Principle at work. Maybe I'll need to brew up some code to log the traffic to the 8042 Anyone else seen this? Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: FC13 PS2 Mouse/Keyboard stops working after a while
Ken Smith wrote: compdoc wrote: The problem is that I have some other hardware that does not work all that well after suspend/hibernate and so I can have either that hardware (M-Audio 1010) working and the mouse at risk of failing or the 1010 not working. So what you're saying is, while the M-Audio 1010 is working the ps/2 stuff fails, and when the M-Audio 1010 has stopped working due to suspend/hibernate the PS/2 stuff works fine. Coincidence? I find it odd that anything would interfere with a ps/2 keyboard, since it's on such a low and well known IRQ. Keyboard is 1 and mouse is 12. APIC is enabled in the bios? It is odd as PS2 interfaces and 8042's are as old as the hills. Following your reply I monitored /proc/interrupts (via a remote ssh session) and I can see the count of keyboard interrupts rising on CPU2 and the mouse ones on CPU3. When the failure occurs the counts stop rising. If I suspend/resume the machine the count then rises again as the PS2 devices are working once more. So it seems like the 8042 stops interrupting the processor, or the processor/apic is ignoring them, or something along those lines. The evidence is that keyboard mouse cease functioning and the interrupt count stops rising. Noticeable things about this are:- * The fault only occurs with X running * Both keyboard and mouse are affected * USB mouse still works * Fault vanishes after suspend/resume * cpu0 has a few interrupts logged and then the count rises on cpu2 (keyboard) and cpu3 (mouse) As far as I can see there are no APIC settings in the BIOS on this motherboard I did notice that one of my two Delta 1010's share an interrupt with the video card so I will need to move that card to another slot xorg.conf includes Section InputDevice # generated from data in /etc/sysconfig/keyboard Identifier Keyboard0 Driver keyboard Option XkbLayout gb Option XkbModel pc105 EndSection Section InputDevice # generated from default Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Cat'ing /dev/input/mice produces a stream of characters. I was waiting for the system to fail while doing that before sending this message but the mouse/keyboard are still working. Its Heisenberg's Uncertainty Principle at work. Maybe I'll need to brew up some code to log the traffic to the 8042 Anyone else seen this? Thanks Ken As it happens, just after sending the last message the mouse/keyboard stopped working. Once it had stopped the stream of characters was no longer available from /dev/input/mice when I use the PS2 mouse. As before the USB mouse works. Given what has been said about the 1010, I'll move its slot to try to get that potential problem out of the way. Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: FC13 PS2 Mouse/Keyboard stops working after a while
Joe Zeff wrote: On 04/06/2011 11:57 AM, James Wilkinson wrote: Stupid debugging idea 1: does it make any difference if you power-up with the PS/2 mouse unplugged and the USB mouse plugged in? If you could borrow a USB keyboard, you could try a similar trick with that. Not stupid at all. In fact, I'll go farther and ask if you have tried swapping in a different keyboard or mouse? Or, have you tried swapping either of them to a different computer to see if the trouble follows them? It's not the type of thing I'd normally think of (I'm *not* a hardware person.) but now that James mentioned it, it looks like an excellent possibility. If nothing else, it's easy to test. The same hardware boots another operating system that does not show these symptoms at all. But what you say is a sensible debugging approach. I might just ditch the PS2 keyboard mouse to bypass the problem :-) Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
F17 XDMCP
Hi, I in danger of making this a rant, but is XDMCP no longer something that Fedora supports? I have just installed F17 x64 in a VM to tinker with it and systemd and I'd like to enable XDMCP. Or what is the favoured remote access method these days. I've put DisallowTCP=0 in the [security] section and Enable=1 in the [xdmcp] section of custom.conf in /etc/gdm/ and opened port 177 UDP in the firewall on the F17 machine. Oddly, on my remote X server when I run X -query machinename :1 the desktop of the remote X server freezes when connecting to this rogue F17 install. As I would expect I can see an open UDP session on UDP 177 but I don't see any traffic on TCP 6000 or 6001 that I would expect. The same remote X server connects to FC6, Centos5.6 etc etc without any issue. What gives? Thanks for any hints and guidance. Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: F17 XDMCP
Ed Greshko wrote: On 06/26/2012 05:27 AM, Ken Smith wrote: I have just installed F17 x64 in a VM to tinker with it and systemd and I'd like to enable XDMCP. Or what is the favoured remote access method these days. What are your requirements for remote access? Is there something missing from using VNC or xrdp? To Alan: I see what you mean about /etc/dconf/db/gdm.d/00-upstream-settings. Its a comment free zone! I'll dig a little deeper. I have made XDMCP work on recent incarnations of Fedora up to 14 To Ed: I've tried xrdp out. Installing xrdp installed the package but it arrived disabled in systemd - grrr: a tad user aggressive - if the aim is to make Fedora more user accessible then installing a service should enable and start it. It fails to show up in the Service Configuration applet until I used bash to tell systemd that its enabled. I don't see how to use the Enable and Disable function in Service Configuration because a service needs to be enabled before it shows up. Gnome 3 runs in fall-back mode in xrdp - a good reason to use X. Vnc does not look too bad in this instance, although in an MS environment I find that the image quality often lacking. I have been used to using XDMCP with *nix systems for years it seems a pity to remove the function that could/might be kept. I could ask the question the other way, how does removing XDMCP functionality further Fedora's cause? This could get into a discussion about the target audience for Fedora/Gnome and what Fedora is trying to achieve. A topic for another thread me thinks. I know one of Fedoras' aims is a technology test bed. The advice is not to use it for production and here is a good example of why. Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: F17 XDMCP
Alan Cox wrote:
{snip} how does removing XDMCP functionality further
Fedora's cause?
It's not a Fedora thing, it's a Gnome thing. Fedora ships several other
display managers all of which do xdmcp just fine.
In appreciate that its a Gnome thing
Thanks
Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: F17 XDMCP
Ed Greshko wrote:
On 06/26/2012 09:54 PM, Ken Smith wrote:
{snip} user accessible then
installing a service should enable and start it.
{snip}
Well, IMO, server software should default to disabled. It is not unusual for
users
(novices and even experienced) to install server side software they aren't
going to
use...at least initially. To have them default to start seems a good choice.
This
is especially true when you probably should alter any default configurations.
{snip}
I could argue this both ways. For something like xrdp I think it should
install, enable and run. I can see an argument for other daemons that
need more application specific config that install and default to
disabled might be a good initial position.
{snip}
I've not used XDMCP in years. I think part of the reason I moved away from it
is
that when I do remote it can be *remote* and the performance over low
bandwidth or
high latency links was lacking.
Agree, but over a 1G LAN with modern hardware it should just fly along.
:-) Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: F17 XDMCP
Eddie G.O'Connor Jr-I wrote:
On 06/26/2012 04:19 PM, Robert Myers wrote:
{snip}
I have more than a hint and guidance. I have emphatic advice. Stop
trying to import and export desktops, no matter the system. Import
and export windows or create virtual machines, but do not ever under
any circumstances attempt to deal with virtual desktops, no matter
the Windows or Linux distribution. If you get it right once for some
circumstance, whatever you have gotten right will soon become wrong
in some intolerable way just as soon as some weenie somewhere has a
better idea. No one is more or less a sinner. All are. I know what
a virtual machine is and I know what a window is and so do most
systems. No one seems to be able to agree on what a desktop is or
what its powers are, and that problem is absolutely fundamental.
Robert Myers
WOW!.strong words! But sound advice nontheless! I've never really
dealt with the virtual desktops and I seriously doubt I ever will, I'm
not that heavily into having different OS'es or programs running. I
imagine it's helpful to people who actually NEED to have that kind of
setup, but for myself it would just be a frivolous waste of time to
even get involved in it!
EGO II
I understand what Robert is meaning especially exporting apps rather
than whole desktops.
But I was attempting to get some hands on experience of F17 via a
Virtual Machine installation. The VNC based window from the VM is only
1024x768 whereas my desktop is 2560x1024 and I'd like to get a full
screen or near full screen display.
xrdp and TigerVNC would give the resolution but they only work in Gnome
fallback mode.
I still don't understand why deprecating XDMCP furthers the Open Source
cause. Like many, I'm pretty tenacious and I'll hack my way round the
enhancements to get the installation to do what I want it to. But why
should I have to resort to that
Maybe I should take this up on a Gnome list.
Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: F17 XDMCP
Gordon Messmer wrote:
On 06/29/2012 05:57 AM, Ken Smith wrote:
I still don't understand why deprecating XDMCP furthers the Open Source
cause.
Guys, slow down. There's no reason to believe that XCMCP has been
deprecated. It can be enabled exactly as it was in the previous
release. It looks like there's a bug that hasn't yet been reported.
It would be helpful if anyone else could verify that the X server
prints an error to the system's console (not to the logs, not to the
controlling tty, and not to stderr) when they attach it to a Fedora 17
XDMCP server.
Apologies Gordon, you asked this earlier and I didn't reply.
I would suggest deprecated as the settings for the function have been
buried. It suppose it depends on how you define deprecated.
I note the other comments about security of XDMCP. In this situation
both the office LAN and the internal VLan inside my host are pretty
safe. If I was concerned I would use a VPN or such like. (Folks still
use ftp and telnet.)
The environment I'm testing in is FC13 x64 on an i7 with nVidia graphics
and that is the KVM host for the FC17 VM. The plan is to move the host
up to FC17 if this testing works out OK.
The FC17 VM has this in the /etc/gdm/custom.conf file
[security]
DisallowTCP=0
[xdmcp]
Enable=1
Ports 177 udp and 6000/6001 tcp are open on it.
There are also Centos 5 and 6 {and other} VM's on that host.
X -query {ipaddr} :1 and Xnest :1 -query {ipaddr} work fine between
the Centos5 and 6 VM's and the host in any combination you choose to try.
If I try the access the FC17 VM with X -query ... from the FC13 host
or the C6 VM, the machine switches desktop as expected and then displays
the circular mouse icon on a black screen and then the desktop freezes.
Cntl-Alt F1 or 2 etc then do nothing.
Logging on to the frozen C6 VM host with ssh shows that the machine is
still up, just its display system is hanging in bits. There is one TCP
session open on port 6001. Trying the kill the X -query process fails.
Switching it to RL1 does not restore any desktop. In this case I killed
the virtual power to it, as all the other buttons and switches were
ineffective.
Sadly in this scenario any messages that were shown on the console are
not visible. Nor are they visible if I do this from the host.
Leaving the FC17 host running and then connecting again, this time with
X -query or Xnest from the host gives varying results. Soon after the
failed attempt with X -query ... I got this error
(EE) open /dev/fb0: No such device
error setting MTRR (base = 0xf000, size = 0x0010, type = 1)
Invalid argument (22)
Fatal server error:
XDMCP fatal error: Session declined Maximum number of open sessions from
your host reached
I got a similar message when I tried with Xnest.
A short time later I tried again with Xnest and got a full logon screen.
I was so surprised I thought I had connected to the wrong host. Trying
again straight away gave this error.
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 2995
Current serial number in output stream: 2995
You may be on the right track that this may be a bug. If there is any
other info I can provide, such as exact software versions etc please let
me know.
Thanks
Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: F17 XDMCP
Gordon Messmer wrote:
{snip}
It sounds like the X server is crashing or locking up. Try this:
Reset the machine running the X server. Possibly reset the F17 host
as well, since it's complaining about too many sessions from your X
server host. When you run X -query, capture data using strace:
strace -f -s 256 X -query ... /var/tmp/xtrace.txt 21
After the X server locks, cancel the trace with Ctrl+C. Don't send
the file to the list, because it'll be large. I don't think it has
any sensitive data in it, so maybe compress it and post it somewhere
it can be retrieved (http://ge.tt ?) or send it to me. What we're
looking for is output from glibc similar to what I included
previously. It'll be on lines near the end which indicate calls to
writev().
I have the trace you need. Its a busy day today but I'll post again as
soon as I have uploaded it somewhere.
Thanks
Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: F17 XDMCP
Gordon Messmer wrote: On 07/02/2012 07:08 AM, Ken Smith wrote: I would suggest deprecated as the settings for the function have been buried. It suppose it depends on how you define deprecated. No, they haven't. They're still in custom.conf, where they've been for some time. The buried settings discussed earlier apply to GDM, which has not itself been deprecated. If I try the access the FC17 VM with X -query ... from the FC13 host or the C6 VM, the machine switches desktop as expected and then displays the circular mouse icon on a black screen and then the desktop freezes. Cntl-Alt F1 or 2 etc then do nothing. It sounds like the X server is crashing or locking up. Try this: Reset the machine running the X server. Possibly reset the F17 host as well, since it's complaining about too many sessions from your X server host. When you run X -query, capture data using strace: strace -f -s 256 X -query ... /var/tmp/xtrace.txt 21 After the X server locks, cancel the trace with Ctrl+C. Don't send the file to the list, because it'll be large. I don't think it has any sensitive data in it, so maybe compress it and post it somewhere it can be retrieved (http://ge.tt ?) or send it to me. What we're looking for is output from glibc similar to what I included previously. It'll be on lines near the end which indicate calls to writev(). I have just sent the below to Gordon off list with an attached file with the traces. Hi Gordon, I attach a tar.gz file with the traces. It only 500k so e-mail should cope. These were done with the FC13 machine, that acts as the VM host, as an X server and the FC17 VM acting as an X client. The FC17 was freshly booted. I had a ssh session logged in to the FC13 from another machine as I was expecting to lose control of the desktop of the FC13 machine during these tests. The file xtrace.txt is a trace using Xnest from a normal user account on the FC13 X server. The file xtrace2.txt is a trace of a repeat of the last Xnest command but this time a login desktop appeared and allowed me to start entering logon details before it vanished off the screen The file xtrace3.txt is a trace of a X -query ... command from a normal user account on the FC13 X server The file xtrace4.txt is a trace of a X -query ... command from the root account on the FC13 X server. As previously the desktop switched to the new X display and it showed a small round icon that was movable with the mouse. The file xtrace4-copy.txt is a copy of xtrace4.txt made after running the X -query ... command but before rebooting that machine to regain control of the desktop. There's some interesting things in that xtrace4.txt file about malloc and memory corruption. Hope this helps Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: what is the name of the os installer?
Anaconda On Tue, Oct 30, 2018 at 9:58 PM ToddAndMargo via users < users@lists.fedoraproject.org> wrote: > Hi All, > > I keep forgetting the name of Fedora's OS installer > (not the program installer). > > Many thanks, > -T > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: fc29 beta
Let us know how it goes! On Fri, Sep 28, 2018 at 2:48 PM ToddAndMargo wrote: > Hi All, > > I just upgraded one of my machines to FC29 Beta. Looks > pretty. Haven't had a chance to play with it yet. > > -T > > Here are my upgrade notes; > > > FC 28 -->> FC 29: > > # rpm --rebuilddb > # rpm -Va --nofiles --nodigest >if anything is too new, do a > # dnf downgrade offender(s) > > # dnf --enablerepo=* update --refresh > # dnf install python3-dnf-plugin-system-upgrade > # dnf system-upgrade download --refresh --releasever=29 --allowerasing > --best > # dnf clean packages <-- optional > # dnf system-upgrade reboot > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: fc29 beta
Thanks for the information, On Fri, Sep 28, 2018 at 2:48 PM ToddAndMargo wrote: > Hi All, > > I just upgraded one of my machines to FC29 Beta. Looks > pretty. Haven't had a chance to play with it yet. > > -T > > Here are my upgrade notes; > > > FC 28 -->> FC 29: > > # rpm --rebuilddb > # rpm -Va --nofiles --nodigest >if anything is too new, do a > # dnf downgrade offender(s) > > # dnf --enablerepo=* update --refresh > # dnf install python3-dnf-plugin-system-upgrade > # dnf system-upgrade download --refresh --releasever=29 --allowerasing > --best > # dnf clean packages <-- optional > # dnf system-upgrade reboot > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
i915 Unstable
Hi everyone, I have a Dell Latitude 5480 laptop with a Fedora 36 install. It crashes regularly, uptime can sometimes be less that 5 mins but sometimes it lasts several hours. There is no trace at all in journalctl of its demise. It behaves like a machine with a memory issue. I've moved the memory from one slot to another and cleaned the connector. I've been using Redhat style systems for over 20 years and have known uptimes of several years. This laptop also boots Win10 and that install is stable. The machine passes Dells internal diagnostics. I'm travelling this week and don't have access to memtest86, but the Win10 memory test passes. Once I'm back home I can network boot it and run memtest86 and FC36 live - which will eliminate the ssd & its controller from the picture. . This machine has a KabbyLake processor (Intel Core i5-7200U 2.50GHz), 8G memory, an Intel i915 (HD Graphics 620) GPU and SSD storage. I've read on various forums that this combination of CPU/GPU can be problematic and some mentions that an upcoming Kernel release may contain a remedy for this. In addition to the FC36 standard kernel, I have tried a 6.0 kernel build and even the development 6.1 kernel from Rawhide's daily builds ( Beta for FC38 ) and its related firmware RPM. Also tried loading the 5.11 kernel from FC34. All with the same results. In fact the FC38 beta kernel only survives a few minutes even without the GUI. Is this hardware faulty, despite Win10 being stable? Does the Linux install stress the hardware in a way Win10 doesent. Should I hold on for a later kernel release with a fix. Is anyone else experiencing this issue? I'd value any insights. Many thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: i915 Unstable
Roger Heflin wrote:
On Wed, Oct 26, 2022 at 7:06 AM Ken Smith via users
wrote:
Hi everyone,
I have a Dell Latitude 5480 laptop with a Fedora 36 install. It crashes
regularly, uptime can sometimes be less that 5 mins but sometimes it
lasts several hours. There is no trace at all in journalctl of its
demise.
{Snip}
This machine has a KabbyLake processor (Intel Core i5-7200U 2.50GHz), 8G
memory, an Intel i915 (HD Graphics 620) GPU and SSD storage. I've read
on various forums that this combination of CPU/GPU can be problematic
and some mentions that an upcoming Kernel release may contain a remedy
for this.
{Snip}
Is this hardware faulty, despite Win10 being stable? Does the Linux
install stress the hardware in a way Win10 doesent. Should I hold on
for a later kernel release with a fix.
Is anyone else experiencing this issue? I'd value any insights.
Many thanks
Ken
I have a 5480, 7300u cpu, hd620 also.No issues with stability when
running graphics.
Current kernel is 5.14.4-200 on fc36, I have also ran 5.18.7-200 and
5.18.6-200 with no stability issues.
Stan, Jamie and Roger. Useful information - thank you. I'll follow the
kdump suggestion.
Thanks
Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: i915 Unstable
Felix Miata wrote:
Ken Smith via users composed on 2022-10-26 13:05 (UTC+0100):
This machine has a KabbyLake processor (Intel Core i5-7200U 2.50GHz), 8G
memory, an Intel i915 (HD Graphics 620) GPU and SSD storage. I've read
on various forums that this combination of CPU/GPU can be problematic
and some mentions that an upcoming Kernel release may contain a remedy
for this.
Wayland? Xorg? Gnome? Plasma? Other DE?
Which DRI driver are you using? Which display driver?
No issues on Kaby Lake desktop here with TDE on Xorg with iris and modesetting:
# xdriinfo
Screen 0: iris
# lscpu | grep 'Model ' | grep -v BIOS
{snip}
For a distro whose reputation is bleeding edge, and deservedly so historically,
its Xorg versions are lagging. As you see above, the F36 version is 1.20.14 (as
is F37's). Xorg's versioning dropped the 1. prefix a year ago, with release of
21.1, when kernel 5.15 was current. 21.1.4 is now current. 21.1.3 was current
when F36 was released. Thus I suggest what's left to try is newer X, to play
most
nicely with latest kernels. An extra installation using Tumbleweed, kernel 6.0.3
+ server 21.1.4, could be an easy way to give it a try.
Good points Felix - thank you. I've installed kdump and it's been
collecting dump files. When I return from travelling this weekend I'll
dig deeper. Tnx Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: i915 Unstable <- no it a hardware fault
Roger Heflin wrote:
The dmesg in the dump where it starts having issues is often enough to
have an idea.
On Fri, Oct 28, 2022, 9:09 AM Ken Smith via users
mailto:users@lists.fedoraproject.org>>
wrote:
Felix Miata wrote:
> Ken Smith via users composed on 2022-10-26 13:05 (UTC+0100):
>
>> This machine has a KabbyLake processor (Intel Core i5-7200U
2.50GHz), 8G
>> memory, an Intel i915 (HD Graphics 620) GPU and SSD storage.
I've read
>> on various forums that this combination of CPU/GPU can be
problematic
>> and some mentions that an upcoming Kernel release may contain a
remedy
>> for this.
{Snip}
To wrap this thread up, its a hardware problem. memtest fails in SMP
mode between 4 & 6G. If I swap in a 4G memory, memtest ran fine for a
couple of days. Beyond 4G it fails, memtest itself crashes. Suspect an
address line is flaky, perhaps 4-6G is showing up lower in the address
space and memtest overwrites itself. (don't know enough about the
architecture of DDR4 memory)
Thanks
Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
