To enable Oracle VirtualBox USB support for a user on Fedora or some other Linux distribution appliance, first install the VirtualBox Extensions Pack and then add the user to the vboxusers group.
# usermod -a -G vboxusers your-username
If the vboxusers group does not exist, create the group and add your username.
# groupadd vboxusers # usermod -a -G vboxusers your-username
Then reboot the Linux appliance and the user should be able to access USB devices.
Here is what you need to do to successfully build and install the Oracle VirtualBox Guest Additions on Debian 5.
First mount the VirualBox guest additions (Extensions Pack) media (Host-D). Then either mount your Debian 5 installation media or configure your Debian 5 package manager to download the necessary packages from a suitable repository.
# apt-get update # apt-get install gcc make # apt-get install linux-headers-$(uname -r) # cd /media/cdrom # run VBoxLinuxAdditions.run
Then reboot your appliance and check that you can auto-resize the guest display. If not, check the build logs which are available under /var/log.
I have seen many questions about enabling a GNOME Shell theme using gnome-tweak-tool that go like this:
I have the user-theme extension installed and turned on in Gnome Tweak Tool. I’ve unzipped the theme folder to /usr/share/themes and selected my gtk theme fine. However under Shell Theme, there’s still a “!” and it doesn’t allow me to do anything as far as selection. (It’s greyed out)
The caution sign is sometimes referred to as an exclamation mark by users.
The best workaround for this is to enable your theme from the command lien using gsettings as follows
gsettings set org.gnome.shell.extensions.user-theme name 'your theme name'
where your theme-name is the full name of your theme – which is installed under $HOME/.themes.
An alternative way is to edit this particular gsetting value using dconf-editor.
Got a MBR disk and GRUB2 core.img will not fit between the MBR and sector 63? This is common with on disks on which Windows XP was installed prior to trying to install Fedora 16.
Typically you will receive a message similar to this:
Your embedding area is unusually small. core.img won't fit in it.. Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
Here is what the Fedora deveopers have to say about this issue:
Versions of Fedora prior to Fedora 16, and many other operating systems, will by default use the MS-DOS disk label format, and create the first partition on a hard disk at sector 63. This leaves a gap of 32KiB between the MBR and the first partition. This is the space into which the core of the system bootloader must be installed on an MS-DOS labelled disk.
The core part of Fedora 16′s bootloader, grub2, may not fit into this 32KiB space, if the required configuration to boot the system is complex. One known problematic case comes when the /boot partition is on a software or firmware (not hardware) RAID-1 device. In this case, the core grub2 image must include RAID support, and the inclusion of this makes the core image larger than 32KiB in size.
In more ‘straightforward’ cases, grub2′s core image is smaller than 32KiB in size, so this bug will often not be encountered. Also, if you install Fedora 16 in such a way that the target drive is re-formatted, Fedora will use a GPT disk label and create a 1MiB ‘BIOS Boot’ partition. With the GPT disk label format, the bootloader core must reside on such a ‘BIOS Boot’ partition, and the 1MB size provides comfortably enough room for any necessary grub2 core image. The bug only occurs when installing Fedora 16 to an existing partition layout (and hence also when upgrading an existing configuration) which requires a complex grub2 core image.
When you encounter the bug, Fedora’s installer may warn you that bootloader installation failed, but the installation will complete. However, the installed system will fail to boot. If you examine the installer logs you may find the message grub2-setup: warn: your core.img is unusually large, it won’t fit in the embedding area.
The safest workaround for the issue is to resize the first disk on the partition so that there is more empty space in front of it. A very small change will be sufficient – just having the partition start at 1MiB rather than 32KiB should suffice. Some partition types can be non-destructively resized from the beginning in this way, but in some cases it may be necessary to archive all the data on the partition, delete it, re-create it with a slightly later starting sector, and then restore the data. If you have to do this, you will likely wish to note the partition’s UUID and partition label before destroying the partition, and ensure that they match when re-creating it. There are parameters you can pass to the various mkfs commands to force the UUID of the created partition: for instance, the parameter is -U for the mke2fs command.
An alternative workaround may be to manually install grub-legacy (rather than grub2) as the bootloader. However, the use of grub-legacy on Fedora 16 is not officially supported, and grub-legacy may well be removed entirely from future Fedora releases, so this is likely to be feasible only in the short term.
As you can see, your options are limited. The GRUB2 developers failed to take this scenario into consideration when GRUB2 was designed.
Sometimes it is different to easily tell which type of zipped archive you are dealing with because the zipped archive has an incorrect extension or no extension at all.
Here is how to tell which you are dealing with:
Zip file header:
$ od -h zipped-file |head 0000000 8b1f ...
Gzip file header:
$ od -h zipped-file |head 0000000 4b50 0403 ...
Linux News