Fedora remix + launch GUI = fail

[Sailing_Nut]

Hi all, I'm booting up the Fedora 14 remix in Qemu and if I select for it to boot into the GUI by default I can't log in. The problem is that the login screen does not see any keyboard input.

Has anyone else seen this problem? If yes, have you fixed it and how? TIA!

I'm a Linux n00b, so hacking around in text mode has not been very fruitful for me. I'm trying to get the networking going through Qemu to my host machine so that I can play on the internet, but have not had any luck.

[cowfodder]

The very first time, it will stay in terminal mode even if you selected Graphical mode.  Login as root to access the command line and change the permissions of the temp directory:chmod 777 /tmp
Read more: http://www.cnx-software.com/20.....x-in-qemu/

[Tass]

Sailing_Nut said:


Hi all, I'm booting up the Fedora 14 remix in Qemu and if I select for it to boot into the GUI by default I can't log in. The problem is that the login screen does not see any keyboard input.

Has anyone else seen this problem? If yes, have you fixed it and how? TIA!

I'm a Linux n00b, so hacking around in text mode has not been very fruitful for me. I'm trying to get the networking going through Qemu to my host machine so that I can play on the internet, but have not had any luck.


I'd love to know if you've found the issue here and I have the same issue – after booting into the UI the keyboard and mouse don't work.  Before I do anything I can see the mouse cursor in the middle of the screen, but as soon as I click to give focus to qemu the cusor disappears.

I've tried the chmod command (had to do that to get through to the UI), but still no luck.  I've seem someone mention the option f running yum install system-config-keyboard, but I can't do this as I have had to launch qemu with the -net none option.

EDIT: Ignore comment about mouse cursor - I can see the cursor, I was confusing it with the VNC cursor.  So - I can move the mouse, but clicking doesn't result in anything.

[Sailing_Nut]

Unfortunately, I have not been able to resolve the keyboard issue with the GUI. I did set the image up without starting the GUI to try various things with the networking and I nave come to a bit of a sad conclusion, I do not believe that networking works in the Windows version of Qemu.

I may try building the Windows Qemu source to see if I can get it to work, but I am not hopeful. (I have seen people writing about how difficult it is to even get the Qemu source to compile.)

It would seem that I need to srcounge up enough old parts to build a system that I can dedicate to Linux and playing with the RPi image.

[Tass]

Sailing_Nut said:

It would seem that I need to srcounge up enough old parts to build a system that I can dedicate to Linux and playing with the RPi image.

Ah - here's the problem.  I AM using a Linux distro - Ubuntu 11.10.  It might work on Fedora itself...

[fireraisr]

@Sailing_Nut

Have you considered trying the debian + lxde setup instead? I've read in several places that the fedora remix still has a few bugs to work out, like the one you described.

Remember this was a dev launch so nothing will be perfect. Also, since it's a free OS that people have put many hours into, putting "fail" in your topic header is rude. Don't be a child, people respond best to polite requests around here.

[Sailing_Nut]

fireraisr said:


@Sailing_Nut

Have you considered trying the debian + lxde setup instead? I've read in several places that the fedora remix still has a few bugs to work out, like the one you described.


I have also tried the Debian setup and was unable to get it to work with networking so I was trying the Fedora image to "cover all my bases"



Remember this was a dev launch so nothing will be perfect. Also, since it's a free OS that people have put many hours into, putting "fail" in your topic header is rude. Don't be a child, people respond best to polite requests around here.


I am sorry that the word "fail" offended you. It was only meant as a comment that putting those two together failed for me. It was in no way intended as a slight toward the people that volunteer their time and effort to produce the code. I'm a developer in my "day job" so I completely understand the blood sweat and tears that get put into efforts like this. (To be truthful I can't completely understand it because I've never worked on an actual operating system, so I have even more respect.)

[SN]

I think the fedora remix has far far fewer bugs in it than might be apparent from the misguided stumblings on here. Rebuild you image as noted on the other thread - it will work (if you"re running qemu on linux, can"t speak for windows users)

[grumpyoldgit]

SN said:


I think the fedora remix has far far fewer bugs in it than might be apparent from the misguided stumblings on here. Rebuild you image as noted on the other thread - it will work (if you"re running qemu on linux, can"t speak for windows users)


In which case, can we have a definitive idiot guide? At the moment the advice, counter advice and counter counter advice is spread out over dozens of posts in half a dozen threads and at least one external web site.

[bob_binz]

@grumpyoldgit
Can you say where you *have* got to with fedora please. You may have already done so somewhere but as you say, there"s a lot of posts to sift through. What os are you hosting from? What fails with fedora? I now have a working setup (i think) so I would like to help if I can

Bbz

[grumpyoldgit]

I got to the point of not being able to log into the gui as the keyboard was unresponsive.

I then scrubbed that image completely and started again but there are, as I've said, several running threads and in trying to follow the advice of others I have got myself completely confused. I can either get caught in a loop at the change password stage or there is a pop and the screen disappears completely. Take your pick. I was going down the expand rootfs procedure but there is now conflicting advice over that.

My boot drive is small so I don't keep any data on it at all. Instead I have an external drive called Western Digital. I am wondering whether some of my problems are occurring because I am carrying out all the instructions in /media/Western Digital. Elsewhere there have been problems because people have used directories with spaces in them so I am wondering if this is partly my problem.

My inclination is to scrub the image again and start from scratch but the idea of wading through pages and pages of conflicting advice is daunting.

[Tass]

Common factor = Grumpyoldgit and I are both running Ubuntu 11.10 with the same outcome (for me the keyboard seems unresponsive, my mouse cursor moves but clicks are unresponsive).

Anyone else got this up & running on Ubuntu?

My next step (tonight) will be to rebuild the image and see if that works - I'll feed back once I've done that.  As I'm going through this I'm documenting it (with screenshots) so if it works, I'll post a guide.

[bob_binz]

Ok, well firstly, I'm running Ubuntu 11.10 too, so I can only really speak for that, although other Linux hosts can probably apply similar strategy. For windows users, I can't say; I understand qemu on windows isn't the easiest thing to cut teeth on!

Next, I'd say grab a brew, cos this goes on a bit!

I would recommend booting to command line at first until everything is working.  You can always edit /etc/inittab and change the 3 in the last line to a 5 to get it to boot to GUI

Also, you should be able to edit the root file system through the mounted disk on your host if you do so as root.  So, if you have /media/Raspi_Remix_14 in Ubuntu, for example, you can edit /media/Raspi_Remix_14/etc/inittab and make changes as above (do this as root on your host, e.g.  sudo nano /media/.....)

The password thing is a pain in the butt.  Think of a couple of passwords that meet the criteria (try using @ for a, ! for i, 0 for o etc.)  You need a couple because you will have to go through the loop a couple of times.

So in qemu, at the beginning, once you've added your users, login to command prompt as root.  If password expired, change it.  Type chage root. Enter 0, 99999, 2012-01-01, 0, -1, <default>.  Note, all except last change date are default values.  Type chage -l root (that's letter l (lower case L)).You should see never against three of the options.  Repeat for your user i.e. chage <uname>.  Now, you may have to do this after you've changed your password, so if you run passwd to change, then type chage -l <name> to see how it's set.  If wrong use chage <name> again. You may need to do root first, set it's password, run chage, then login as user, change password, run sudo chage and that should be it.  I think the reason this has to be done is because the initial time is incorrect.  As long as you have networking, you should be able to use ntp to set the time and the expiry won't be a problem anyway.

Assuming password is now ok, at least you should be able to get into your command line login each time.  Report back if not.

Actually, whilst you're logged in as root, you can do the following:

echo <username>   ALL=(ALL) ALL

replacing <username> with the user you setup.  This allows that user to run sudo commands (you should really use a group rather than the user, but hey!)

Next I would recommend you check that networking is working.  I use a tap/tun connection, but I seem to remember, at least grumpyoldgit had networking working out of the box on debian.  To check it, ping your router IP from qemu.  Also, check DNS by pinging, e.g. raspberrypi.org.  If there's no network, report back, and we can try setting up tap connections (which is the only way that works for me)  Oh, please excuse the jargon - tap is a connection method for connecting qemu through your PCs network connection.

The reason I recommend getting networking working before X is because you can ssh into qemu to kill X if necessary. So, in qemu, type ifconfig eth0 and make a note of the inet addr.

For X, you need to create a new file in /etx/X11 called xorg.conf, then add the following lines:

Section "InputClass"
Identifier "evdev keyboard catchall"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbLayout" "gb"
EndSection

Again, you can do this from your host - sudo nano /media/Raspi_Premix_14/etc/X11/xorg.conf

I had to omit any screen section to get this to work, and I'm still trying to find out why at this stage.

then if you sudo init 5, you should eventually get to the login screen.  Does the keyboard work?  If not, damn, it seems I was fluked!  To kill the session, assuming you have networking, open terminal in your host and ssh root@ipaddr where ip addr is the one you noted above.  Alternatively, use your username to ssh then use sudo for the following command.  Once logged in to ssh, type init 3 (or sudo init 3)  Your x session should return to the command line - press return a couple of times if there's no prompt.

Well, I need a brew myself now (and there's probably loads I've forgotten!)  Have a read of the above and post back.

BBz

[grumpyoldgit]

You are starting your guide in the middle, after you have managed to get the beast up and running, which is the main stumbling block for most people. It needs to start at the beginning

[bob_binz]

You're correct - I am taking the starting point as being once qemu has been booted up.  I made the assumption you had no problems getting Fedora installed to an SD card (or whatever)  Did I assume incorrectly?  I think my problem is that if I use my method of running qemu, it adds confusion (by introducing tap network connections, which most people don't seem to need.)  If people generally have networking working at turn on, then I don't really want to add this extra level of (potentially confusing) info.

So yes, the details really begin at the point where a user has run their qemu command.  Apologies if this isn't enough.

BBz

[AndyD]

Thanks BBz,

I have been having troubles with getting the fedora remix image to work under qemu. It was all easy ... except the X11 keyboard issue. Adding the xorg.conf file worked for me. I am running qemu on using Fedora 16 on an old celeron based laptop.

[grumpyoldgit]

You haven't given any instructions for running Qemu. 95% of the discussion on these threads is on the process of getting an image up and running in Qemu. You have started after that point.

[bob_binz]

@AndyD

Please can you post your qemu command line and state whether you have networking up or not?

Thanks, BBz

[Tass]

OK - so here's the start of a step-by-step tutorial to getting Qemu up and running:

http://myraspberrypiexperience.....al-pi.html

I'm having an issue getting all the screenshots posted in so will sort that out later, but hopefully this will help get everyone up and running, and once we work out what the exact issues are I'll add in an issues & solutions section.

Feedback welcome.

[grumpyoldgit]

I've had a very quick look. I'll have to sit down this afternoon and do it. I notice though that you don't tell them how to get hold of zImage_3.1.9

[Tass]

Grumpyoldgit said:


I've had a very quick look. I'll have to sit down this afternoon and do it. I notice though that you don't tell them how to get hold of zImage_3.1.9



Thanks - I'll add a step with a link

[zardoz99]

OK, off the top of my head, try the following at command line while connected via ssh to the emulation (ie, outside the GUI screen) . I do not promise it will work but I did manage to get my keyboard working after messing about in this area.

# udevd -d

#udevadm trigger --verbose

#udevadm control --reload-rules

#killall -9 X

Wait for the GUI to restart and see if that makes any difference.

Z.

[Tass]

bob_binz said:

For X, you need to create a new file in /etx/X11 called xorg.conf, then add the following lines:
Section "InputClass"
Identifier "evdev keyboard catchall"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbLayout" "gb"
EndSection


Thanks, but I've tried this and unfortunately no luck.  When running sudo init 5 I see the error below:



Seems to be an issue with system-setup-keyboard there....

[zardoz99]

The system-setup-keyboard is a red herring I think. Try my udev stuff and see if it helps.

[Tass]

zardoz99 said:


The system-setup-keyboard is a red herring I think. Try my udev stuff and see if it helps.



I was just looking into that.  I unfortunately have to launch qemu with -net none param (other networking issue discussed across various posts), so don't think ssh will work.  I'll need to see if I can get around that first, then move onto the udev stuff.

Thanks for the info!