Tiny Core Linux

Tiny Core Extensions => TCE Corepure64 => Topic started by: flyingfishfinger on January 29, 2016, 01:50:14 AM

Title: QEMU for 64bit?
Post by: flyingfishfinger on January 29, 2016, 01:50:14 AM
Hi,
Looks like there was an extension request for this about 2 years ago, but the thread didn't answer whether there is one or not. The only other question about this was more about making our own extensions, and personally I don't think I have the skills for this.
Since there's a 64-bit KVM extension and they most often work together, I'm wondering if there is also a QEMU.
I got VMs working in the 32-bit version of TC, but I'd love to be able to address more RAM and install 64-bit guests in my TC64 install.
Thanks!

R
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on January 30, 2016, 04:40:48 AM
I managed to build it from source (not as an extension) and it works, but I don't know how to persist it through reboots. I tried adding the whole /usr directory to the backup, but apparently that's not enough. In particular, it complains about libbz2.so.1.0 not being available anymore post-boot.
Other than creating an extension, how can I persist builds of things across boots?
Thanks,

R

Also, backing up /usr seems to break Xorg. If I do that, startx is no longer available..
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on January 30, 2016, 05:15:07 AM
Never mind the X thing, it works.
Sorry for replying again, the edit icon seems to have disappeared.

R
Title: Re: QEMU for 64bit?
Post by: Juanito on January 30, 2016, 05:18:25 AM
Really the only sensible way to do this is to create an extension, but the good news is that it's not difficult  :)

You could try this:
Code: [Select]
$ make
$ touch mymarker
$ sudo make install
$ sudo find / -not -type 'd' -cnewer mymarker | grep -v "\/proc\/" | grep -v "^\/sys\/" | tee files
[edit files with a text editor - it will be obvious which ones to delete]
$ sudo tar -T files --numeric-owner -zcvf myextension.tar.gz
$ mkdir /tmp/pkg
$ cp myextension.tar.gz /tmp/pkg
$ cd /tmp/pkg
$ sudo tar xf myextension.tar.gz
$ rm myextension.tar.gz
[edit out dev files from /tmp/pkg/usr/local]
$ cd /tmp
$ sudo mksquashfs pkg/ myextension.tcz
$ sudo chown tc:staff myextension.tcz
Title: Re: QEMU for 64bit?
Post by: Rich on January 30, 2016, 11:30:38 AM
Hi flyingfishfinger
As a general rule of thumb, the only files under  /usr  that should be backed up are configuration files that you have
modified. Every time Tinycore boots it creates the  /usr  directory from scratch to allow you to recover if you messed
something up. Say a library file got altered accidentally. By backing up  /usr , every time you boot the altered library
file would replace the original. Wbar may also be affected. It has files that are dynamically updated and might not like
being changed to a previous state. The point here is, don't back up the  /usr  directory.

Quote
Sorry for replying again, the edit icon seems to have disappeared.
You have about 30 minutes to go back and modify a post.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on January 30, 2016, 08:14:16 PM

Quote
Sorry for replying again, the edit icon seems to have disappeared.
You have about 30 minutes to go back and modify a post.


Ah, makes sense. Thanks!

Also, I successfully made an extension of qemu in 64bit (Thanks Juanito!), seems to work and persist. Since I wasn't able to find one otherwise, should / can I contribute it someplace?

R
Title: Re: QEMU for 64bit?
Post by: Rich on January 30, 2016, 08:24:12 PM
Hi flyingfishfinger
Extensions are always welcome. Instructions for submitting an extension are at the bottom of this page:
http://wiki.tinycorelinux.net/wiki:creating_extensions
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on January 30, 2016, 08:59:58 PM
Well, I spoke too soon. Looks like I compiled it without SDL support, so I'll have to do it again. But once it works I'd be happy to submit it.

R
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on January 31, 2016, 03:40:24 AM
So I'm having a bit of trouble with SDL. I've installed SDL (as well as X11, libs...) before I start compiling, but so far I haven't been able to resolve the following errors:

"in .../ui/sdl.c: undefined reference to 'XkbGetKeyboard'
in .../ui/sdl.c: undefined reference to 'XkbGetAtomName'
in .../ui/sdl.c: undefined reference to 'XkbFreeKeyboard'
in .../ui/sdl.c: undefined reference to 'XFree'
in .../ui/sdl.c: undefined reference to 'XkbFreeKeyboard'
collect2:error: ld returned exit 1 status.

What packages am I missing?

R
Title: Re: QEMU for 64bit?
Post by: Juanito on January 31, 2016, 03:57:53 AM
libxkbcommon-dev, libxkbfile-dev?
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 07, 2016, 04:16:07 AM
Hi, I've got it almost working. Two issues remaining:
- If I add my extension to onboot.lst, I never get a desktop. It hangs with a blinking cursor just after the ASCII art logo and before I would get a text prompt. I can drop to a prompt with CTRL-C, but startx doesn't work in this case. Everything works just fine if I load it manually post-boot. Any ideas for this one?
- Sound issues: I built qemu with the -alsa flag and have set my VM to use hda (Win7 didn't find a driver for ac97 or something, I didn't try very hard because OSS works ootb on Ubuntu with hda). When I boot, I get sound from the VM but it's terribly choppy and torn up. Do I have to use ac97 here? Also, is there a GUI alsamixer for corepure64?
Thanks!

R
Title: Re: QEMU for 64bit?
Post by: Juanito on February 07, 2016, 05:45:46 AM
Do you have a circular dependency in the dep file maybe?

When you load onboot, does open-vm get loaded before something it needs?

No, there is no alsamixer gui in corepure64

No idea about ac97 and windows...
Title: Re: QEMU for 64bit?
Post by: curaga on February 07, 2016, 06:19:28 AM
Add the bootcode "showapps" to see what's loaded.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 07, 2016, 07:09:09 PM
Solved the sound, AC97 did it for ALSA.
What's open-vm? Haven't seen it anywhere...
I don't have a dep file yet, I just added everything it wanted to run to onboot to see if I could get it to work. Everything else loads fine (in particular, once built it only asks for  SDL and bzip2 for some reason). Showapps seems to finish loading, but I can't tell if it does. It gets to the last app in the onboot file, then switches screens and hangs.

R
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 08, 2016, 12:34:07 AM
I also tried putting it in bootlocal.sh (making sure it loads after every other extension?) but it still hangs before X starts.
Title: Re: QEMU for 64bit?
Post by: Rich on February 08, 2016, 12:42:31 AM
Hi flyingfishfinger
Is your extension trying to start QEMU when it gets loaded? If so, that might be why it hangs since X isn't up yet.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 08, 2016, 12:48:59 AM
By "start" you mean open a VM? No, definitely not. All it's trying to do is load the tools. If it's not loaded, I can't execute any qemu-related commands.
Is there a way for me to debug what's making it hang?

R

Also,  I noticed that when I DO run a VM (after loading everything post-boot), it's quite a bit slower than running the same VM from my Ubuntu install on the same machine. It's using KVM in both instances, but there's definitely more lag and time to open programs and such under TC.
Title: Re: QEMU for 64bit?
Post by: Rich on February 08, 2016, 01:02:21 AM
Hi flyingfishfinger
Do any of the tools require that the network is up?
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 08, 2016, 01:11:29 AM
Shouldn't, although I'm not sure how to check this. It works fine if there's no network cable or wireless attached post-boot, at any rate.
Title: Re: QEMU for 64bit?
Post by: Rich on February 08, 2016, 01:23:52 AM
Hi flyingfishfinger
Is there a startup script in  /usr/local/tce.installed  for QEMU? Post it if there is.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 08, 2016, 01:38:40 AM
No, there isn't. Should there be?
Title: Re: QEMU for 64bit?
Post by: Rich on February 08, 2016, 01:53:27 AM
Hi flyingfishfinger
Not necessarily. Startup scripts are used for things like setting up directories, copying files, setting permissions, etc. that
an extension may require.

Quote
Is there a way for me to debug what's making it hang?
Try adding  syslog  to the your boot loader. Then check  /var/log/messages  for clues.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 08, 2016, 02:16:40 AM
Did, here's the last bit (from the mounting of mydata) until the end:

Quote
Feb  7 23:00:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/mount /mnt/sda1
Feb  7 23:00:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/tar -C / -zxf /mnt/sda1//mydata.tgz
Feb  7 23:00:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/umount /mnt/sda1
Feb  7 23:00:07 box auth.notice su: + /dev/console root:tc
Feb  7 23:00:07 box authpriv.notice sudo:       tc : TTY=console ; PWD=/mnt/sdb1/tce/optional ; USER=root ; COMMAND=/bin/mkdir -p /tmp/tcloop/qemu64
Feb  7 23:00:07 box authpriv.notice sudo:       tc : TTY=console ; PWD=/mnt/sdb1/tce/optional ; USER=root ; COMMAND=/bin/mount qemu64.tcz /tmp/tcloop/qemu64 -t squashfs -o loop,ro,bs=4096
Feb  7 23:00:08 box user.debug kernel: e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
Feb  7 23:00:08 box authpriv.notice sudo:       tc : TTY=console ; PWD=/mnt/sdb1/tce/optional ; USER=root ; COMMAND=/bin/cp -ais /tmp/tcloop/qemu64/home /tmp/tcloop/qemu64/usr /
Feb  7 23:00:08 box user.debug kernel: e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
Feb  7 23:00:08 box authpriv.notice sudo:       tc : TTY=console ; PWD=/mnt/sdb1/tce/optional ; USER=root ; COMMAND=/sbin/ldconfig
Feb  7 23:00:08 box daemon.info init: starting pid 3031, tty '/dev/tty1': '/sbin/getty -nl /sbin/autologin 38400 tty1'
Feb  7 23:00:08 box auth.info login[3031]: root login on 'tty1'
Feb  7 23:00:08 box authpriv.notice sudo:       tc : TTY=unknown ; PWD=/home/tc ; USER=root ; COMMAND=/usr/bin/tee /etc/sysconfig/backup
Feb  7 23:00:09 box user.info kernel: e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Feb  7 23:00:09 box user.info kernel: e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO

...I guess it does do something with the network device, then. I don't know enough to draw any conclusions from this though, unfortunately.

I had
su tc -c "tce-load -i qemu64.tcz"
 in the bootsync.sh, but it behaves the same way as when I try loading it with onboot. I'll look if that version produces a different message log..

Update: Here's the version where it's in onboot.lst instead:

Quote
Feb  7 23:25:01 box authpriv.notice sudo:       tc : TTY=console ; PWD=/mnt/sdb1/tce/optional ; USER=root ; COMMAND=/bin/mkdir -p /tmp/tcloop/qemu64
Feb  7 23:25:01 box authpriv.notice sudo:       tc : TTY=console ; PWD=/mnt/sdb1/tce/optional ; USER=root ; COMMAND=/bin/mount qemu64.tcz /tmp/tcloop/qemu64 -t squashfs -o loop,ro,bs=4096
Feb  7 23:25:01 box authpriv.notice sudo:       tc : TTY=console ; PWD=/mnt/sdb1/tce/optional ; USER=root ; COMMAND=/bin/cp -ais /tmp/tcloop/qemu64/home /tmp/tcloop/qemu64/usr /
Feb  7 23:25:03 box user.info kernel: snd_hda_intel 0000:00:1b.0: probe_mask set to 0x1 for device 17aa:20ac
Feb  7 23:25:03 box user.debug kernel: snd_hda_intel 0000:00:1b.0: irq 47 for MSI/MSI-X
Feb  7 23:25:03 box user.warn kernel: usb 2-4: Warning! Unlikely big volume range (=511), cval->res is probably wrong.
Feb  7 23:25:03 box user.warn kernel: usb 2-4: [14] FU [Digital In Playback Volume] ch = 6, val = -8176/0/16
Feb  7 23:25:03 box user.info kernel: usbcore: registered new interface driver snd-usb-audio
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.25
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: http://ibm-acpi.sf.net/
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: ThinkPad BIOS 7NETC2WW (2.22 ), EC 7MHT25WW-1.03
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: Lenovo ThinkPad X61, model 7673JBB
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: detected a 16-level brightness capable ThinkPad
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: radio switch found; radios are enabled
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
Feb  7 23:25:03 box user.notice kernel: thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
Feb  7 23:25:03 box user.info kernel: thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
Feb  7 23:25:03 box user.info kernel: input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input7
Feb  7 23:25:03 box user.info kernel: sound hdaudioC0D0: autoconfig: line_outs=1 (0x12/0x0/0x0/0x0/0x0) type:speaker
Feb  7 23:25:03 box user.info kernel: sound hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Feb  7 23:25:03 box user.info kernel: sound hdaudioC0D0:    hp_outs=1 (0x11/0x0/0x0/0x0/0x0)
Feb  7 23:25:03 box user.info kernel: sound hdaudioC0D0:    mono: mono_out=0x0
Feb  7 23:25:03 box user.info kernel: sound hdaudioC0D0:    inputs:
Feb  7 23:25:03 box user.info kernel: sound hdaudioC0D0:      Internal Mic=0x15
Feb  7 23:25:03 box user.info kernel: sound hdaudioC0D0:      Dock Mic=0x1c
Feb  7 23:25:03 box user.info kernel: sound hdaudioC0D0:      Mic=0x14
Feb  7 23:25:03 box user.info kernel: input: HDA Intel Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
Feb  7 23:25:03 box user.info kernel: input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
Feb  7 23:25:03 box user.info kernel: input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
Feb  7 23:25:03 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chown tc:staff -R /home/tc/.config/nano
Feb  7 23:25:03 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod 644 /home/tc/.config/nano/nanorc
Feb  7 23:25:06 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chown -R root.staff /usr/local/tce.installed
Feb  7 23:25:06 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod -R 775 /usr/local/tce.installed
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/sh
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/cp /usr/local/share/wbar/dot.wbar /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chown root.staff /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod g+w /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/mv /tmp/wbar.2273 /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod g+w /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/mv /tmp/wbar.2283 /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod g+w /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/mv /tmp/wbar.2291 /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod g+w /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/mv /tmp/wbar.2299 /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod g+w /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/mv /tmp/wbar.2309 /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod g+w /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/mv /tmp/wbar.2317 /usr/local/tce.icons
Feb  7 23:25:07 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/chmod g+w /usr/local/tce.icons
Feb  7 23:25:08 box authpriv.notice sudo:     root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/ln -s /usr/local/etc/udev/rules.d/90-alsa-restore.rules /etc/udev/rules.d/
Feb  7 23:25:08 box daemon.info init: starting pid 2830, tty '/dev/tty1': '/sbin/getty -nl /sbin/autologin 38400 tty1'
Feb  7 23:25:08 box auth.info login[2830]: root login on 'tty1'
Feb  7 23:25:08 box authpriv.notice sudo:       tc : TTY=unknown ; PWD=/home/tc ; USER=root ; COMMAND=/usr/bin/tee /etc/sysconfig/backup
Feb  7 23:25:08 box user.debug kernel: e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
Feb  7 23:25:09 box user.debug kernel: e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
Feb  7 23:25:10 box user.info kernel: e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Feb  7 23:25:10 box user.info kernel: e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO

Same hangup with both variants...

Thanks for your continued help!

R
Title: Re: QEMU for 64bit?
Post by: curaga on February 08, 2016, 04:33:52 AM
Why does your extension contain /home? If that overwrites the provided files, it could cause issues like this. Another guess would be running out of RAM, but I guess your extension isn't that big vs your RAM.
Title: Re: QEMU for 64bit?
Post by: Juanito on February 08, 2016, 06:34:27 AM
What's open-vm? Haven't seen it anywhere...
Sorry - I meant your qemu extension
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 08, 2016, 11:01:54 PM
Progress!
You're right, I shouldn't have zipped up the /home directory in the extension. I followed the directions for making one, and there was a QEMU-related file in the directory so I left it in.
Removed it, fixed permissions (755) and voila, no longer hangs on boot! I'm writing this from inside the VM, as it happens!

Always more questions though  ::) :
- Is there a spice client for TC? The graphics performance is kind of terrible, and I'd like to be able to start the VM on boot so I can just connect to it once the desktop shows up. I wrote this whole sentence before it appeared in the box, for example.
- There doesn't seem to be a cpufreq-util in the 64-bit category. Is that correct?
- I'm having trouble with my screen resolution, but that's probably a better question for a new thread.


R
Title: Re: QEMU for 64bit?
Post by: Rich on February 08, 2016, 11:23:59 PM
Hi flyingfishfinger
Quote
... I'd like to be able to start the VM on boot so I can just connect to it once the desktop shows up.
Create a file under  /home/tc/.X.d  containing the command to start QEMU. Something like:
Code: [Select]
qemu-x86_64 options &
Title: Re: QEMU for 64bit?
Post by: Juanito on February 09, 2016, 12:06:55 AM
There doesn't seem to be a cpufreq-util in the 64-bit category.

That's true, but an element of cpufreq functionality is built into the base - Curaga can probably provide more details.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 09, 2016, 12:17:35 AM
Rich: What's the difference between doing that and putting it bootsync?

Also, I found that this doesn't seem to work if you're using SDL. The machine will start before X, but I don't know how to connect to an SDL session after that.
What kind of VNC clients are there for corepure64? I didn't see any in the list.
In trying to build the spice client, spice-protocol, cyrus-sasl and vala-tools don't seem to exist. Will look into it further.

R
Title: Re: QEMU for 64bit?
Post by: Juanito on February 09, 2016, 12:20:04 AM
What's the difference between doing that and putting it bootsync?

In ~/.X.d it will not start until after X has started.
Title: Re: QEMU for 64bit?
Post by: Juanito on February 09, 2016, 12:33:01 AM
...vala-tools don't seem to exist. Will look into it further.

You mean like vala, vala-gen-introspect, valac, vapicheck and vapigen or something else?
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 09, 2016, 12:46:13 AM
Ah, so many dependencies. The spice-server requres spice-protocol, which itself needs to be built. That required python six, which I couldn't get without pip, which needed to be downloaded separately. Urgh...this is why I didn't become a software engineer :p
Let me poke at this for a little and get back to you guys...

R
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 09, 2016, 01:19:20 AM
Ah, so many dependencies. The spice-server requres spice-protocol, which itself needs to be built. That required python six, which I couldn't get without pip, which needed to be downloaded separately. Urgh...this is why I didn't become a software engineer :p
Let me poke at this for a little and get back to you guys...

Update: I think I got past the vala (maybe not, I'll let you know). Currently building spice-gtk, which fails with the following:

Quote
GEN      vncdisplaykeymap_xorgevdev2xtkbd.c
/bin/sh: ./keymap-gen.pl: not found
  GEN      vncdisplaykeymap_xorgkbd2xtkbd.c
/bin/sh: ./keymap-gen.pl: not found
  GEN      vncdisplaykeymap_xorgxquartz2xtkbd.c
/bin/sh: ./keymap-gen.pl: not found
  GEN      vncdisplaykeymap_xorgxwin2xtkbd.c
/bin/sh: ./keymap-gen.pl: not found
  GEN      vncdisplaykeymap_osx2xtkbd.c
/bin/sh: ./keymap-gen.pl: not found
  GEN      vncdisplaykeymap_win322xtkbd.c
/bin/sh: ./keymap-gen.pl: not found
  GEN      vncdisplaykeymap_x112xtkbd.c
/bin/sh: ./keymap-gen.pl: not found
  CC       vncdisplaykeymap.lo
vncdisplaykeymap.c:75:46: fatal error: vncdisplaykeymap_xorgevdev2xtkbd.c: No such file or directory
 #include "vncdisplaykeymap_xorgevdev2xtkbd.c"

R
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 09, 2016, 03:03:13 AM
Got that one too. Apparently TC installs perl into /usr/local/bin as opposed to /usr/bin. So I needed to change the !# line inside keymap-gen.pl to !#/usr/local/bin.
Another dep is gtk3-gir, then it built. I now have a spicy client, but I need to recompile qemu to support spice output.
Also, it wants PulseAudio and Gstreamer 1.0. I thought I had the Gstreamer one, but I'll try and rebuild it.

...sheesh, I should write all this up when I'm done if I remember.  Meanwhile, since none of this is persistent I'll get lots of practise doing it over again after I reboot :D

R
Title: Re: QEMU for 64bit?
Post by: Juanito on February 09, 2016, 03:16:57 AM
You should file a bug requesting that they put /usr/bin/env perl  ;)

..make extensions as you go along, then it will be persistant...
Title: Re: QEMU for 64bit?
Post by: curaga on February 09, 2016, 05:12:55 AM
Re cpufreq: the kernel functionality is included in base, and ondemand is the default. Anything done via the cpufreq utils can be done directly by writing into files in /proc and /sys.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 09, 2016, 09:12:08 PM
Found the CPU adjustments, thank you!
I made an extension for the spice-protocol, yay!

Is there a celt051 package already? There seems to have been a celt.tcz in TC but not in 64-bit. The spice-server (required to build qemu with spice support) specifically requires celt051.. :(

EDIT:....never mind, built an extension for it.

R
Title: Re: QEMU for 64bit?
Post by: Juanito on February 10, 2016, 12:14:23 AM
specifically requires celt051.. :(

EDIT:....never mind, built an extension for it.

Please name the extension celt.tcz and not celt-051.tcz
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 10, 2016, 12:17:17 AM
Ok, but it's apparently specific to that particular version and not the latest one. Still just celt?

R
Title: Re: QEMU for 64bit?
Post by: Juanito on February 10, 2016, 12:24:04 AM
If there's no other existing celt extension, then it would better to call it just celt - this avoids having to change dep files if the extension were changed from, say, celt-051 -> celt-053.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 10, 2016, 12:37:42 AM
Ok. The celt project actually makes note that they branched this particular version and developed it in parallel and named it celt051:

Quote
This is an update of the previous 0.5.1 prerelease; as several software and hardware projects have seen fit to deplot this prerelease version for development and testing, we've released this new version that changes the installation namespace from 'celt' to 'celt051' to ease installation and parallel development with other versions of celt without conflict. Aside from renaming symbols and install locations to 'celt051' there are no other changes from the celt 0.5.1 release.
Title: Re: QEMU for 64bit?
Post by: Juanito on February 10, 2016, 12:52:49 AM
Ah - in that case, maybe celt051 is better...
Title: Re: QEMU for 64bit?
Post by: Rich on February 10, 2016, 12:57:38 AM
Hi flyingfishfinger
According to:
http://www.celt-codec.org/downloads/
Quote
—The CELT codec has been merged into the IETF Opus codec and is now obsolete—
Would Opus be a suitable replacement?
http://opus-codec.org/
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 10, 2016, 02:29:35 AM
Not sure. Spice-server calls for that particular version (also documented on other sites that have guides on how to build it).

In other news, I succeeded in building it with spice support! Now to build the Spice client and pray it works...

R
Title: Re: QEMU for 64bit?
Post by: Juanito on February 10, 2016, 02:32:03 AM
Would Opus be a suitable replacement?

Since it's missing from the corepure64 repo, I'll make an extension.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 10, 2016, 04:25:56 AM
Alright, I think there's one more question. I managed to build the spice-client before, but now it won't work for the life of me. I didn't get this error before and I did the exact same thing. A reboot / norestore doesn't change anything. Here is the issue:

Quote
/usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_G                                                                                                                                                   LIB
/usr/local/share/aclocal/glib.m4:8:   run info Automake 'Extending aclocal'
/usr/local/share/aclocal/glib.m4:8:   or see http://www.gnu.org/software/automak                                                                                                                                                   e/manual/automake.html#Extending-aclocal
configure.ac:16: warning: AM_NLS is m4_require'd but not m4_defun'd
/usr/local/share/aclocal/intltool.m4:27: IT_PROG_INTLTOOL is expanded from...
configure.ac:16: the top level
configure.ac:16: warning: AM_NLS is m4_require'd but not m4_defun'd
/usr/local/share/aclocal/intltool.m4:27: IT_PROG_INTLTOOL is expanded from...
configure.ac:16: the top level
configure.ac:16: warning: AM_NLS is m4_require'd but not m4_defun'd
aclocal.m4:462: IT_PROG_INTLTOOL is expanded from...
configure.ac:16: the top level
configure:12503: error: possibly undefined macro: AM_NLS
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/local/bin/autoconf failed with exit status: 1
Running configure with --enable-maintainer-mode --enable-gtk-doc --with-gtk=3.0                                                                                                                                                    --enable-vala --prefix:/home/tc/spice

This is a slightly different error I got for a long while beforehand, which was the "./configure.lineno: syntax error "unexpected word"  one.
It's really annoying because I had built this before but not made an extension from it... :(

R

    [EDIT]: Fixed quote tag.  Rich
Title: Re: QEMU for 64bit?
Post by: Juanito on February 10, 2016, 05:25:10 AM
This looks like you took spice-client from git  - why not use a stable version?

If you have to use git, check that automake, intltool, libtool-dev and gettext-dev are all loaded before running ./autogen.sh - you might also need glib2-dev and/or gtk3-dev.
Title: Re: QEMU for 64bit?
Post by: flyingfishfinger on February 10, 2016, 06:02:15 PM
Built a stable version. I can connect to a running VM with spicy (included in GTK)!
The only problem now is that it only ever seems to draw one frame, the one it received when I started up the client. I know the VM is working fine because I can click something, kill the client, open it back up and the new (first) frame will be rendered with the action I took.
It seems to be making a great picture viewer, but not so much a functional desktop. Any clues? This might be more of a spice question now though.
Thanks for all the continued help so far! Progress is slow, but steady.

R
Title: Re: QEMU for 64bit?
Post by: Juanito on April 09, 2016, 03:24:06 AM
qemu extension posted

To use with spice-gtk and pulseaudio

In one terminal window:
Code: [Select]
$ QEMU_AUDIO_DRV=pa qemu-system-x86_64 -enable-kvm -cdrom TinyCorePure64-7.0.iso -soundhw hda -m 2G -spice port=5930,disable-ticketing
In another terminal window:
Code: [Select]
$ spicy -h 127.0.0.1 -p 5930
Note: shift f12 to ungrab the mouse

spice-vdagent (to cut & paste host <-> guest) and xf86-video-qxl also posted, but I've not yet figured out how to use them  ::)
Title: Re: QEMU for 64bit?
Post by: Juanito on April 11, 2016, 08:03:08 AM
..and to enable copy/paste host <-> guest..

Start qemu with:
Code: [Select]
$ QEMU_AUDIO_DRV=pa qemu-system-x86_64 -enable-kvm corepure64.img -soundhw hda -m 2G -spice port=5930,disable-ticketing -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent
Connect with gtk-spice:
Code: [Select]
$ spicy -h 127.0.0.1 -p 5930
In the guest vm:
Code: [Select]
$ tce-load -i spice-vdagent
$ sudo modprobe uinput
$ sudo spice-vdagentd
$ spice-vdagent

..and copy/paste is enabled

As an added bonus, once vdagent is up, there's also no need to ungrab the mouse to pass from guest to host  :)