I 'm using ubuntu and windows in parallel. In my hard disk I left some space for windows and linux also. Now disk apace is full. How can I transfer some data from root to other derive without affecting any applications? plz suggest me the best approch
I'm attaching the screen shot of disk usage analyzer!
I experienced same kind of problem and could move the /home partition to some mounted device in 2-steps after logging in as root(On 'Ubuntu 12.04.1 LTS' server).
Step 1: Move /home to /mounteddevice/home
Step 2: Update /etc/passwd file replacing 'home' with 'mounteddevice/home'
And the other directory which consumes more space is /lib and /var/lib and I am searching for a proper solution to move /lib and /var/lib
Related
Docker Desktop supports moving the VM Image that it uses onto another drive if needed. On my Mac Mini (2018) I have moved it to an external SSD in order to enlarge it more than the internal storage would have allowed.
The external SSD was named "Extra Space", which (ironically) became a problem when I also tried to use the SSD for other non-Docker development and discovered that some of the Ruby Gems I am using have problems with spaces in path names.
I decided that I would have to rename the drive to "ExtraSpace" (without the "extra" space), but then Docker was not able to find its VM Image. I was unable to use the built-in location chooser ("Preferences" -> "Resources" -> "Advanced" -> "Disk Image Location") because that tool assumes that it is moving the image from one location to another but in my case the image is not being moved, only the path to the existing image is changing.
I looked through the Docker configuration in ~/Library/Containers/com.docker.desktop/ and found the path to the image in Library/Containers/com.docker.docker/Data/vms/0/hyperkit.json. I tried changing it there, but Docker Desktop would not start.
In the error logs, I found lots of messages like this:
time="2021-10-31T15:06:43-04:00" level=error msg="(5487d9bc) 4ecbf40e-BackendAPI S->C f68f0c84-DriverCMD GET /vm/disk (925.402µs): mkdir /Volumes/Extra Space: permission denied"
common/cmd/com.docker.backend/internal/handlers.(*VMInitHandler).VMDiskInfo(0x58c13b8, {0x58b94a0, 0xc0001d82a0})
common/cmd/com.docker.backend/internal/handlers/vminit.go:39 +0x42
Why does Docker Desktop not follow the VM configuration file to find the location of the image? Is there somewhere else I have to change it?
After a lot more searching, I found the following additional files that need to be updated with the new path:
~/Library/Preferences/com.electron.docker-frontend.plist
~/Library/Preferences/com.electron.dockerdesktop.plist
~/Library/Group Containers/group.com.docker/settings.json
Once I had updated all of these files with the new path, Docker Desktop was able to start up correctly.
I'm running Centos7 using Vmware workstation on windows 7 laptop. All was well until I restarted my laptop this morning & my VM started complaining as below
The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child
Cannot open the disk 'C:\Users\<user>\Documents\Virtual Machines\CentOS 64-bit\CentOS 64-bit-000003.vmdk' or one of the snapshot disks it depends on.
Module 'Disk' power on failed.
Failed to start the virtual machine.
Below is the image of the folder containing the VM & the image of the VM itself.
I've looked through the vmware log & found the disk ID
2016-03-21T15:56:15.685+13:00| vmx| I125: DISKLIB-LINK : Opened 'C:\virtmac\CentOS 64-bit.vmdk' (0xe): monolithicSparse, 419430400 sectors / 200 GB.
2016-03-21T15:56:15.685+13:00| vmx| I125: DISKLIB-LINK : DiskLinkIsAttachPossible: Content ID mismatch (parentCID b0f614a0 != a0549cb5)
All you have to do is to delete the .lck file from the folder of your vmdk files.
It is generally present at
C:\Users\UserName\Documents\Virtual Machines\VMWareName
Also you can just move the lck files one folder up to ensure you do not delete any other file by mistake.
Deleting all .lck files in the folder should technically solve the problem.
If you use VMs such as Kali Linux, it might happen that the AV quarantines parts of the .vmdk files. In my case I had to restore it from the Windows Defender quarantined files see the screenshot attached
If you are using Kali in VM,
Go to the main directory (Configuration File).
Determine the missing file partition. Ex: kali-linux-2022.3-vmware-amd64-s003.vmdk
Copy any other partition and give it a name of a messing partition.
> copy kali-linux-2022.3-vmware-amd64-s004.vmdk kali-linux-2022.3-vmware-amd64-s003.vmdk
In case you face a Busybox Initramfs Error
type (initramfs) fsck /dev/sda1 -y
I have extended my Time Capsule storage by adding an external disk to the TC USB port. Everything looks good except I see that /.Trashes on this disk has 241 GB of data that I don't need. How can I get rid of it?
I am comfortable using terminal and sudo, although I'm very rusty, but I have no clue of even how to access this TC external disk from terminal.
I figured out how to do it. All external disks appear under /Volumes in terminal. I cd'd to the directory under there that held my 241 GB of unwanted data and used
rm -r *
to remove all of it. Of course this "remove recursively" should be used with great caution.
I am using Oracle Virtual Box version 4.2.16 r86992. Everything was fine until yesterday shutdown.
Today, it shows inaccessible and throws this error:
Runtime error opening C:\Users\xxxxxx\VirtualBox VMs\vBoxxxxXubuntu_Beta\vBoxxxxXubuntu_Beta.vbox for reading: -102 (File not found.).
D:\tinderbox\win-4.2\src\VBox\Main\src-server\MachineImpl.cpp[725] (long __cdecl Machine::registeredInit(void)).
It's good to restore this to working, It would save lot of time and restore configuration settings and data. Thanking your support.
This normally happens if the host OS crashes or you pull the plug on it, leaving the .vbox file unsaved.
In the location:
C:\Users\xxxxxxx\VirtualBox VMs\vBoxxxxXubuntu_Beta\
you should find two files:
vBoxxxxXubuntu_Beta.vbox-prev
vBoxxxxXubuntu_Beta.vbox-tmp
Copy vBoxxxxXubuntu_Beta.vbox-prev to vBoxxxxXubuntu_Beta.vbox.
Select vBoxxxxXubuntu_Beta.vbox, in the VBox manager, right click, and then left click on refresh.
Observe that it now shows Powered Off.
Now you are good to go.
Based on my experience, I was on Windows 7 and running Ubuntu 14.04 as guest OS on Virtual Machine.
Go to your Virtualbox folder (in my case):
C:\Users\Dev12\VirtualBox VMs\Ubuntu
You'll see files with extensions: Ubuntu.vbox-tmp or Ubuntu.vbox-prev
Remove -tmp from file name Ubuntu.vbox-tmp so that it reads as Ubuntu.vbox
Exit from Virtual Machine and start it again.
You should now see error gone away.
The virtual box files with extension .vbox contain metadata the virtualbox hypervisor requires to resolve the guest virtual OS' configuration.
If the main .vbox file is corrupted (i.e. reporting that it is empty) then use the backup .vbox-prev file to recover the contents of the original file.
Do this by renaming the empty .vbox files a temporary name (e.g. rename originalVM.vbox to originalVM-empty.vbox).
Then make a copy of the backup file originalVM.vbox-prev, where the copy will have the same name as the original but with the word "copy" appended to it (i.e. originalVM.vbox-prev is renamed to originalVM (copy).vbox-prev).
It is important to retain the original backup .vbox-prev file it should not be altered or itself renamed.
Now go rename the copy of the newly created .vbox-prev file originalVM (copy).vbox-prev to the original name of the empty .vbox file and be mindful to also change it extension from .vbox-prev back to just .vbox.
That is rename originalVM (copy).vbox-prev back to originalVM.vbox. Now that this is done you may add the .vbox file (guest os) back into the VBOX hypervisor. This will recover the state and snapshot of the "inaccessible" guest VM. Now delete the original empty .vbox file.
I've faced the same issue using CentOs 6.8 on a VirtualBox 5.1 installed in Windows 7 and AjayKumarBasuthkar's solution worked perfectly for me:
I went to C:\Users\\VirtualBox VMs\CentOS6.8
Made a copy of the file CentOS6.8.vbox-prev and gave it the name of CentOS6.8.vbox
Went to the VirtualBox GUI, right-clicked the VM instance and hit refresh
The CentOS instance went from the State Inaccessible to Powered Off
VirtualBox 4.3 is released and could it be that you've updated or there was some issues while updating?
In any case if you are not able to bring up the Virtualbox, remember to backup the VirutalBox VMs folder and going for a fresh install should be the best way forward.
I faced the same problem and I resolved by doing following in Oracle Virtual box 4.3.28 with Ubuntu 14.04 LTS, when Virtual box VM was closed.
Removed ubuntu.vbox to another folder outside virtual box folder
removed -prev from file ubuntu.vbox-prev
start oracle virtualbox, it works excellent.
On a Windows 7 Host, I found that Daemon Tools service had a hold on the file.
The solution was to uninstall Daemon Tools, but I suspect if you stop the service and remove the file association, you would be sorted.
The other issue might be that if your Virtual Machine was on an external hard drive, it is possible that the drive letter has changed. If so, go to Computer Management, and select the hard drive and right click to change the drive letter and save (Note that this is for Windows).
This is going to sound stupid but try to reinstall VB. It may work.
I am adding one critical and important comment to the previous great answers. Make sure that the original .vbox file is corrupted and empty before you copy the content from the.vbox-prev file. If it is not the case and you find it with lines and readable content, don't replace the content of the .vbox.
Changes made to the VM directly before the VM got inaccessible might not be updated in the .vbox-prev backup file . The changes could not be synced with those changes before the OS upgrade or system changes that led to the inaccesable issue.
If you find your VM not accessible after an OS upgrade or system change, first check the.vbox file if it is still readable by a text editor and it has lines. Then you just need to delete the VM from the VirtualBox manager list(just remove the appliance from the list and don't remove files) . Then reopen the.vbox file and it should work perfectly.
If the original.vbox file is corrupted or empty when you open it with a text editor, then and only then, you can copy the content from the .vbox-prev and follow the instructions highlighted.
This was my experience, and I wanted to share it with you to avoid losing some last minute changes before the OS upgrade or crash.
Recently I changed the permissions of the file system and gave myself all the rights. I logged out of the system and I couldn't log back in. I got the error message
Could not update ICEauthority file /home/marundu/.ICEauthority</>
I did a live boot with a Fed 17 disc and replaced my .ICEauthority file with the live-user version and it worked for a time, until I logged out again. Now, the login progress screen is all that shows. I can log into command mode (Ctrl-Alt-F2) but I can't sudo - I get the error messages:
sudo:/usr/libexec/sudoers.so must be only writable by owner and sudo: fatal error. Unable to load plugins.
I just found a good link on Ubuntu:
Ask Ubuntu: ICEauthority permissions problem
Some things to note:
I tried the obvious things like changing file permissions, but found my whole home directory was somehow owned by root. I believe this was due to a failed package update.
I used a recovery disk (Knoppix ISO) for ease of use: Better UI
When mounting the bad home partition, I used the most common Linux file type (Ext4)
I used 'sudo mount -o r,w -t ext4 /dev/sda1 /mnt'
When changing ownership, I used the numeric user:group specification, since the recovery disk doesn't have the symbolic users and groups: 'sudo chown -R 1000:1000 /mnt/home/userdir'
I verified that /home/userdir had rwx for owner, r-x for group / other. This is noted as a valid set of permissions for ICEauthority; others can work. See the linked discussion.
Hope that helps someone...
I got the “Could not update ICEauthority file” error and found that my home partition was in "Read-Only" mode. Thus, this error made sense.
The real question was what caused the "Read-Only" attribute on the partition. I ran "dmesg | read-only" and found that there were serious errors with the file system on my home partition which the kernel had set to "read-only during the boot process.
I then booted from a USB key (CDROM would do as well) and ran "sudo fsck /dev/sdXY" where /dev/sdXY is the partition containing my home directory. fsck corrected a number of file system errors on my home partition.
I then reboot after removing the USB key/CDROM and the problem went away.
Bottom line: Check if your home partition has file system errors. They might be the cause of this error. If so, run fsck from an external device on the partition containing your home directory.