I have a problem with the Shadow Copy. Specifically, when I try to set up a Shadow Copy of a given volume, error 0x80042306 appears.
Additionally, there is no possibility to choose a Shadow Copy for the same volume, I simply cannot select my own partition to perform the copy on the same volume.
The second issue is that the partition to which the error pertains is part of a larger disk. We have a 30TB disk and expanded it by creating a new 70TB partition, and the error is related to this second one. Other disks perform correctly. The entire disk is on a disk array.
To preempt the question, all other backup applications have been removed and no other applications are using VSS.
There are only two Microsoft providers in the registry.
I would be grateful for any information.
Best regards,
We have uninstalled all backup applications.
We have tried to set up ShadowCopy on other disk/partitions.
I am using Yocto for one of my project. I know that Yocto needs a good amount of disk space for build activities. And also I am working as non-root user in Ubuntu 20.04. But I often run into space issues during build.
WARNING: The free space of [...]/tmp-glibc (overlay) is running low (0.555GB left)
ERROR: No new tasks can be executed since the disk space monitor action is "STOPTASKS"!
WARNING: The free space of [...]/downloads (overlay) is running low (0.555GB left)
ERROR: No new tasks can be executed since the disk space monitor action is "STOPTASKS"!
WARNING: The free space of [...]/sstate-cache (overlay) is running low (0.555GB left)
ERROR: No new tasks can be executed since the disk space monitor action is "STOPTASKS"!
I have tried deleting $TMPDIR (build/tmp), $SSTATE_DIR (build/sstate-cache), $DL_DIR (build/downloads). But these things didn't help me.
Is there any way to allocate more space to user in Ubuntu? And also what is the best practice for space usage while working with Yocto?
Can anyone please let me know how to resolve this issue?
Your help will be much appreciated.
Thanks in advance.
P.S: I working with Yocto "Honister" release. Please let me know if any info is missing here.
It is known to all Yocto users/developers that it needs lot of space, and it has 3 parts that are huge:
TMP
DOWNLOADS
SSTATE CACHE
My advice is the following (based on my experience):
Before starting to work on any Yocto build, create one directory for the three components mentioned above.
Example:
mkdir -p /home/user/yocto_shared/{tmp,downloads,sstate-cache}
After that, any build you create you share those with it:
In local.conf:
DL_DIR ?= "/home/user/yocto_shared/downloads"
SSTATE_DIR ?= "/home/user/yocto_shared/sstate-cache"
TMPDIR = "/home/user/yocto_shared/tmp"
This will save you lot of space and save you time for new builds.
Also, you can inherit rm_work which removes tmp output files for every recipe after it bitbake:
INHERIT += "rm_work"
NOTE
After you remove something on Ubuntu, specially Yocto tmp, downloads and sstate-cache, do not forget to empty the Trash.
In addition to the suggestions above, you could try adding the following to your conf/local.conf file to avoid creating -dbg packages, which could save some extra space.
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
In any case, console-only images might take up to 20GB, whilst graphical images can go up to 50GB. You should not be deleting your $TMPDIR (build/tmp), $SSTATE_DIR (build/sstate-cache) and $DL_DIR folders, but getting a larger HDD/SDD instead.
I'm looking to have root on a RAID BtrFS built on a number of luks disks. I typically do this on Debian or Ubuntu by preparing my disks before-hand, then running the install into those disks. At the end, I need to pivot into the new system to modify crypttab and fstab.
I'm trying the same thing with Qubes, which uses the Anaconda installer. When I get to the GUI partitioner, the BtrFS appears under the "Unknown" dropdown, but if I try to set "mount point to "/" and then "Update Settings," it errors with "You must create a new filesystem on the root device." (But there is already one there.) If I use "+" instead, I am told "Not enough free space for thin provisioning." The installer is clearly confused about how much space is available: "Available space 992.5 KiB," "Total space 238.47 GiB." In fact, there is 932.35GiB in the RAID'ed BtrFS.
If I just open the luks devices, but put no FS in there, then all /dev/mapper/luks* devices appear in the partitioner under the "Unknown" dropdown, but choosing "New mount points will use the following partitioning scheme: Btrfs," none of the devices allow me to associate a mount point. It's greyed out, or if I try to use "+" and test it with a single disk, it comes back with an error "Not enough disks for single." (But I have multiple LUKS disks there!)
Trying without any prior formatting, neither luks nor Btrfs, I find that the partitioner can't handle bare disks. It wants a partition table (which I don't).
Does anyone have a way through this?
Edit: It appears there are serious issues with this installer.
The answer to all of this appears to be: "Don't try to fight the Anaconda, as you will lose." Despite the access to a root terminal (Control-Alt-F1 reaches a tmux session, Control-b 2, reaches a terminal with root privileges), you must return to the graphical installer, which is too limited to allow any headway, particularly with BtrFS disks. Anaconda sees BtrFS not as a filesystem, but as a device, and this makes problems insurmountable.
The solution is to do a dummy install and then modify all disks, editing crypttab, fstab, /etc/default/grub as needed. Then pivot in and run dracut -f, along with grub2-mkinstall if needed. Also, if necessary, grub2-install.
One advantage of BtrFS in this process, is that it's possible to avoid having to use a live-DVD or Anaconda's rescue shell to make changes in a system "at rest", afterward pivoting in to run dracut et al. You'd just use btrfs device add to add a device to the root, and then btrfs device remove the original. Then make relevant changes to the original partitions, afterwards reversing the add/remove. So it's possible to make changes by moving back and forth from one disk to the other.
We have an old server with disk failures that we've tried to clone into VMSphere. This resulted in an error from what that error came from we couldn't pin point.
With ddrescue we cloned the machine to a 2TB external hard drive that we can use to lab around with without having any downtime.
Then we used normal dd to try to create an image that we then later could convert or insert into the virtual environment.
Problem is that we have don't have any workstations that are able to handle a 2TB file. Is there any way that we can create an image of the drive with the partitions, data and mbr? Basically everything except for the unallocated space.
You could try using "dd". If you have some idea how big the OS and data partitions were, just chop that much plus a bit extra off the front of the image and save in a new file. Say you guess it was 4GB of OS and 8GB of data, do something like this:
dd if=yourimage of=newsmallerimage bs=1024k count=14000
which will get you around 14GB. Any Virtual Machine will likely ignore any blank space at the end anyway.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have a separate partition on my disk formatted with FAT32. When I hibernate windows, I want to be able to load another OS, create/modify files that are on that partition, then bring Windows out of hibernation and be able to see the changes that I've made.
I know what you're going to type, "Well, you're not supposed to do that!" and then link me to some specs about how what I'm trying to do is wrong/impossible/going to break EVERYTHING. However, I'm sure there's some way I can get around that. :)
I don't need the FAT32 partition in Windows, except to read the files that were written there, then I'm done - so whatever the solution is, it's acceptable for the disk to be completely inaccessible for a period of time. Unfortunately, I can't take the entire physical disk offline because it is just a partition of the same physical device that windows is installed on -- just the partition.
These are the things I've tried so far...
Google it. I got at least one "this is NEVER going to happen" answer. Unacceptable! :)
Unmount the disk before hibernating. Mount after coming out of hibernation. This seems to have no effect. Windows still thinks the FAT is the same as it was before, so whatever data I wrote to disk is lost, and any files I resized are corrupted. If any of the file was cached, it's even worse.
Use DeviceIoControl to call IOCTL_DISK_UPDATE_PROPERTIES to try and refresh the disk (but the partition table hasn't changed, so this doesn't really do anything).
Is there any way to invalidate the disk/volume read cache to force windows to go back to the disk?
I thought about opening the partition and reading/writing directly by using libfat and bypassing the cache or something is overkill.
So I finally got a solution to my problem. In my mind, I associated Mount Point with Mount. These are NOT the same thing. Removing all of the volume mount points does not make the volume unmounted. It's still mounted but not in the sense that you have a path you can access in explorer.
This is the article that started it all.
It also goes to show that searching for your EXACT problem, as opposed to the perceived problem can help a lot!
So there were a couple of solutions, one was to constantly call NtSetSystemInformation() in a tight loop to set the "SYSTEMCACHEINFORMATION" property to essentially empty/clear the cache whenever the system is going to hibernation. Then stop the loop when you come out. This, to me, seemed like it could affect system performance. So I discarded it.
Even better though, is the recommended solution to a slightly different problem presented in this MSDN article, which provides direction to an even better solution to the problem: Dismounting Volumes in a Hibernate Once/Resume Many Configuration
Now I have a service which will flush the write caches, then lock and dismount the volume whenever the system goes into hibernation/sleep and release the lock on the volume as soon as it comes out.
Here's a little bit of code.
OnHibernate>
volumeHandle = CreateFile(volumePath,
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
0 );
FlushFileBuffers( volumeHandle );
DeviceIoControl( volumeHandle, FSCTL_LOCK_VOLUME, NULL, 0, NULL, 0, &cbReturned, NULL ) ;
DeviceIoControl( volumeHandle, FSCTL_DISMOUNT_VOLUME, NULL, 0, NULL, 0, &cbReturned, NULL );
//Keep the handle open here.
//System hibernates.
OnResume>
DeviceIoControl( volumeHandle, FSCTL_UNLOCK_VOLUME, NULL, 0, NULL, 0, &cbReturned, NULL )
CloseHandle(volumeHandle)
Hopefully this helps someone else out in the future :)
Well, you're not supposed to do that! ;-)
Since the operating system (Windows in this case, but Linux is the same) writes some of its internal filesystem structures in the hibernation image, it is going to be very confused if the disk contents change while it's "running" (think of hibernation as just a long pause in the operating system's execution).
What I can suggest is that you completely bypass the issue: format the partition as ext2. There are Windows programs to read an ext2 partition, which you can use to get data out of it, and most modern operating systems should be able to read/write it (since it's a quite common Unix-style filesystem). Avoid ext2 IFS drivers; you want to take the filesystem access out of the kernel and into a program which you can open and close at will.
Use Linux to create the partition as a hidden FAT32 partition. Linux will let you mount the partition and write files. Windows will not let you mount the partition and read files, and Windows will not corrupt the partition. But there are third party libraries that will read the partition while Windows is running.
To clarify, hidden means that the partition type is different from an ordinary FAT32 partition type. If your ordinary partition type is 0x0C then the corresponding hidden type is 0x1C.
On a related but different problem, I used the following:
Running cmd as administrator (works from batch file)
DISKPART
SELECT G
REMOVE
ASSIGN LETTER=G
EXIT
This unmounts the volume (G:) and then remounts it. Any read of the disk (in my case a device pretending to be a USB Mass Storage Device formatted as FAT16) will actually read the device, so the read cache is effectively flushed.
Downside is that starting DISKPART takes about 4 seconds, but that's probably not a problem in a hibernating situation.
My memory is that the FAT table is read during the OS boot and mounting of the volume. Can't you do a shutdown, then modify the FAT, then reboot Windows?
As far as I can tell, Windows does caching at the disk level. However, if a partition has a type that Windows refuses to read or write (ext2, hidden FAT32, etc.) then that partition's contents should never get into Windows caches in the first place.
With DOS, it was typing ctrl+c, twice if I recall well.
With Linux, sync; echo 3 > /proc/sys/vm/drop_caches or a script thereof, of course ;-)
With Windows, interpolate ;-) Or install VirtualBox and Ubuntu+Wine to develop compatibly.
Well, I vaguely remember that former Windows used a diskcache program to start a process and that diskcache could be used to send the process a signal to flush and purge the whole cache. If things have evolved gently, you might be able to send such a signal to a Windows process. Sorry I'm no longer using Windows partly because of such obscurity.