In fact, i'm not in a VM. I have arch 32 bit installed in a netbook (acer aspire one d255e) and it worked nice. But with the last update X gone broken (Loading GLX extension and failing). I downgrade glibc, binutils, gcc and gcclibs, but it didn't work.
I think your issue may be sufficiently different from the one experienced by those of us using VirtualBox that it might be worth starting your own thread in the Newbie Corner forum.
]]>i read that removing the virtualbox lib solves the problem. but when someone is running arch on a real 32 bit machine, that solution isn't effective. i will try downgrading the glibc and its brothers and i will come here to tell you about this.
Not sure what you mean. This issue only seems to affect people running Arch in VB -- if you're using a "real" installation, you shouldn't have these problems. I'm not willing to remove the vboxvideo stuff, because I'm sure that my nice wide-screen display will be "corrupted." I haven't tried it, I admit; I'll try to do it today, see what happens.
]]>As I can't find a better place on the forums to do this, I'll briefly discuss the configuration here.
Wow! Thanks for taking the time for all that. A well written and very useful post -- it should go on a "sticky" somehwere.
Personally, I still find it easier to use Samba (thanks to SMBUp) or mount_afp .
Happy New Year!
]]>That would be nice because I'm also having trouble getting shared folders to work with Virtualbox (if this is too off-topic and it isn't too much hassle for you, you can also PM me).
As I can't find a better place on the forums to do this, I'll briefly discuss the configuration here.
Create a folder on your host OS to be shared with your Arch Linux guest. Note that this folder has to be in a location that's not "owned" by a particular user of your host OS. There's some weirdness to this, as it appears to be about more than just the permissions assigned to a particular folder. I've found that on OS X, creating a folder either in the ~/Public folder (<--this is where I put my shared folder) or on the Desktop works, while creating a folder in the ~/Documents directory does not, despite the fact that the permissions for some of these different directories are similar. Also, at this stage, place a text file or some other file in the folder—later on, if you can see and view the contents of this file from within Arch you'll know the folder's been shared successfully
Identify the shared folder in your VM's VirtualBox settings. In the VirtualBox Manager window, prior to booting your VM, select your Arch Linux guest and go to "Settings > Shared Folders". Click the folder icon with a plus on it to add a shared folder. For "Folder Path" open the dropdown menu and select "Other..." to launch your host OS' file browser. Select the folder you created on your host OS in step one. For "Folder Name", if it's not autofilled, enter a name for the folder to identify it to the Arch Linux guest—to avoid dealing with escape characters and so forth later on, I generally make this something simple, like "Shared", and avoid spaces or special characters. For simplicity's sake, I also usually make this name the same as the name of the folder I created in step one. "Read Only" should be left unchecked, assuming you want to be able to add files to the shared folder from within Arch. Also, leave "Auto-mount" unchecked—there's an alternative configuration in which you leave this checked, but for present purposes it shouldn't be. Finally, check "Make Permanent" to have the folder available every time the Arch guest is booted. When you've filled out the form and clicked 'OK' your new folder-to-be-shared should appear in the "Settings > Shared Folders" window under the list of "Machine Folders".
Boot your Arch Linux VM. Log in with your normal user account (i.e., not as root).
Create a mount point in Arch for the shared folder. By this, I mean create a folder in Arch where you want the contents of the shared folder on the host OS to appear. I usually create this folder in my home (~) directory and, for consistency, name it the same thing I named the folder on the host OS, which is also the same "Folder Name" name I gave when identifying it in the VM settings.
Test the availability of the shared folder by manually mounting it. Momentarily, we'll automate this process, but before we do it's a good idea to make sure everything's working correctly. This is an example of the command to run, which I'll explain subsequently:
# sudo mount -t vboxsf -o gid=1000,uid=1000 Shared /home/josh/Shared
In the above command,
sudo is obviously to invoke administrative privileges, which are needed to mount the folder;
mount is the mount command;
-t is a flag specifying the type of thing to be mounted, which is a Virtual Box shared folder ('vboxsf');
-o is the options flag, which is there so we can invoke the option to make the folder writable for the users in the group with the number 1000 (gid=1000) and the particular user with id number 1000 (uid=1000). Assuming this is a personal install and you created only one non-root user account for yourself, user 1000 in group 1000 will be you, however if you've got multiple user accounts or have set up weird group privileges, you may need to look up the group and user id that apply to you;
'Shared' is the name you gave as "Folder Name" in step two;
'/home/josh/Shared' is the absolute path to the folder you created in step four (my username is 'josh'). Note that you have to give this filepath without any shortcuts or symlinks (i.e., '~/Shared' will not work).
Note that if you want to temporarily share a folder between your guest and host in the future, you can use this same 'mount' command in conjunction with VirtualBox's "Devices > Shared Folders" menu while the VM is running. The only difference is that the folder you share using "Devices > Shared Folders" will be added to a list of "Transient Folders" rather than the "Machine Folders" list, meaning that it will only be available for the current VM session.
Test the shared folder. Once you've run this command, you should be able to see and view the contents of any files you've placed in the shared folder on the host OS by navigating to the mount-point folder you created from within Arch. You should also try copying a file from your Arch system into the shared folder to see if it shows up on the host OS. If not, you may not have write privileges for the folder, and you should check (1) the folder permissions on the host, as well as (2) the uid/gid you used in your command to make sure they correctly apply to your user account.
Add instructions for mounting the folder to /etc/fstab. If everything's worked up 'til now, you can go ahead and add instructions for mounting to the folder to your /etc/fstab file. This will automatically mount the shared folder in the future when Arch boots. At the end of my /etc/fstab file, I placed the following:
# VirtualBox Shared Folder
Shared /home/josh/Shared vboxsf uid=1000,gid=1000 0 0
While the order is slightly different, you'll see that all of the options set here are identical to the ones used in the 'mount' command above, so you should set them to whatever the personal equivalents are that you used previously. The only exceptions are the last two zeroes, which you should just leave as is. These turn off Linux's file system backup ('dump') and file system check ('fsck') for the shared folder, neither of which is needed here.
Reboot Arch. At this point, you should be able to reboot Arch and, if everything's worked correctly, the shared folder should be automatically mounted for you.
Lastly, I should mention how the method I've described here is different from alternatives that some other people use, so there's no confusion if or when you encounter a forum thread at some point in which people have done it differently. Some other folks will use much the same process I've outlined, but instead of having 'fstab' mount their shared folder will instead create a systemd configuration file to do the same thing.
Still other folks will check "Auto-mount" in step two above, and omit my steps 4–7. Instead, they create user privileges for Guest Additions within Arch that allow the Guest Additions software to mount volumes by itself. Guest Additions will then automatically mount the shared folder as an external drive that shows up under the '/media' directory. I've never tried this method personally, but if you wanted to, you could find instructions on doing so with a bit of Googling.
Note that if you use my configuration, you should leave 'Auto-mount' unchecked—if you leave it checked, things will work just fine when you boot and while you're working, but will cause problems when you try to shut down the VM. At that point, VirtualBox's ongoing attempt at connecting to the VM as a removable device, hitherto harmless, causes Arch to wig out as it's unmounting and closing down all the virtual hardware. This usually induces a slew of error messages ending in a kernel panic, and the need for a hard shutdown of the machine.
Hope this helps, and sorry for the long, somewhat OT post. Hopefully it helps by making it easier for people to export error logs to their host systems while this bug is ongoing.
]]>P.S. I can post my shared folder configuration elsewhere if it's helpful, though I feel like it might be OT for this thread
That would be nice because I'm also having trouble getting shared folders to work with Virtualbox (if this is too off-topic and it isn't too much hassle for you, you can also PM me).
]]>I've installed the excellent SMBUp which "just works" to replace Apple's broken Samba. Then, in Arch, with smbclient (from the Extra repo) I can access stuff from the command line (or with Thunar, when X is up) without using the VB "shared folders" which I've always had problems with.
Thanks much. So far VBox shared folders are working well for me. But I've bookmarked the link and should I need a more extensive solution, I'll be sure to try it out!
P.S. I can post my shared folder configuration elsewhere if it's helpful, though I feel like it might be OT for this thread
]]>Even while X was crashing on my system, Guest Additions still successfully provided the ability to mount a shared folder from the host system. So one way to get your log files up is to copy them to a shared folder, to which the host has access, and then open the files in the host OS. At that point you can cut and paste them into a browser in the host system.
On a related note: I see you're using OS X 10.7.5 as a host, as am I. I've installed the excellent SMBUp which "just works" to replace Apple's broken Samba. Then, in Arch, with smbclient (from the Extra repo) I can access stuff from the command line (or with Thunar, when X is up) without using the VB "shared folders" which I've always had problems with. Umm ... get your filenames just right with xmbclient; that should go without saying, but I have an enlarged idiocy gene ...
]]>I'll take a look at your bug report, too. Thanks for the diligence.
NP.
Slightly OT: Do I have to register a new/different account in order to be able to vote on the bug that wideaperture filed?
Yep, the bug tracker requires a separate account.
it's me who have posted this thread, same problem
Thanks for the additional information, and for contributing to the bug report.
the file is on my virtual machine and I don't know how to do this in a non-GUI browser like lynx.
Even while X was crashing on my system, Guest Additions still successfully provided the ability to mount a shared folder from the host system. So one way to get your log files up is to copy them to a shared folder, to which the host has access, and then open the files in the host OS. At that point you can cut and paste them into a browser in the host system.
It's also possible to use 'wgetpaste' to create pastebin links, as 2ManyDogs suggested above.
]]>Apparently.
Despite tooltips explaining which button to press.
Oh hum.
]]>No need to be so exceedingly rude :-(
]]>Hit the square in the window title bar, rather than the "X" to close the window.
I don't think I should have to jump through Windows-centric hoops or pass some silly test.
ps "kraut" is rather offensive & "connard" is not very complimentary.
be nice
Spam is not nice. I call 'em as I see 'em. He could paste his logs into a code block.
]]>