I have one MBR partition(NTFS) with Windows 8.1 installed on it. I wanna install Arch Linux as the second OS. I need to make new partition from unused space of existing one. Is it possible? If so, how to determine what "start" and "end" sector of existiing partition I need to specify to create new partition (to not damage existing one)?
Yes, this is possible. However, it isn't quite as easy as you might think.
You cannot simply look for a "start" and "end" sector, as the existing file system might have scattered its data all over the partition. The right thing to do is the following:
Determine how much free space is left in the file system, and how much you could possibly take away (the file system might have some expectations about that).Then, move all the data to the start of the partition, making sure the file system understands the data is in new places.
After that, you can alter the size of the partition itself, and create new partitions.
All together, that is not a trivial task, and is best done by partition managers that can do file system re-sizing. In your case, you want one that understands NTFS and probably also is standalone, i.e. runs from a live CD or something like that - I'm not sure you can resize a NTFS file system that is currently being used. Arch Linux might even provide a "boot" or "install" DVD that will do this.
You can use diskmgmt.msc command in run box of windows 8.1 to know what part is empty and also you can create partitions through this and create empty space required for your arch Linux installation. Hope it helps
Related
I am looking for a program that would allow me to mirror one partition to another disk (something like RAID1) for Linux. It doesn't have to be a windowed application, it can be a console application, I just want what is in one place to be mirrored to another.
It would be nice if it were possible to mirror a specific folder that I would care for instead of copying everything from the given partition.
I was looking on the internet, but it's hard to find something that would give such opportunities, hence the idea to ask such a question.
I do not want to make fake RAID on Linux or hardware RAID because I read that if the motherboard fails then it is best to have the same second one to recover data.
I will be grateful for every suggestion :)
You can check my script "CopyDirFile" written in bash, which is located on github.
You can perform a replication (mirroring) task of any source folder to another destination folder (deleting a file in the source folder means deleting it in the destination folder).
The script also allows you to create copy tasks (deleted files in the source folder will not be deleted in the target folder).
The tasks are executed in background at a specified time, not all the time, frequency is set by the user when creating the task.
You can also set the task to start automatically when the user logs on.
All the necessary information can be found in the README file in repository.
If I understood you correctly, I think it meets your requirements.
Linux has standard support for software RAID: mdraid.
It allows you to bundle two disk devices into a RAID 1 device (among other things); you then create a filesystem on top of that device.
LVM offers another way to do software RAID; it doesn't seem to be very popular, but it's certainly supported.
(If your system supports hardware RAID, on the motherboard or with a separate RAID controller, Linux can use that, too, but that doesn't seem to be what you're asking here.)
When writing software which needs to cache data on disk, is there a way in libc, or a way which is specific to a certain file system (such as ext4), to create a file and flag it as suitable to be deleted automatically (by the kernel) if the partition becomes almost full?
There’s something similar for memory pages: madvise(…, MADV_FREE).
Some systems achieve this by writing a daemon which monitors the partition fullness, and which manually deletes certain pre-determined paths once it exceeds a certain fill level. I’d like to avoid this if possible, as it’s not very scalable: each application would have to notify the daemon of new cache paths as they are created, which may be frequently. If this were in-kernel, a single flag could be held on each inode indicating whether it’s a cache file.
Having a standardised daemon for this would be acceptable as well. At the moment it seems like different major systems integrators all invent their own.
You can use crontab job, and look for specific file extension and delete it. You can even filter based on time and leave the files created in last n minutes.
If you are ok with this, let me know, I will add more details here.
Suppose I have a deleted file in my unallocated space on a linux partition and i want to retrieve it.
Suppose I can get the start address of the file by examining the header.
Is there a way by which I can estimate the number of blocks to be analyzed hence (this depends on the size of the image.)
In general, Linux/Unix does not support recovering deleted files - if it is deleted, it should be gone. This is also good for security - one user should not be able to recover data in a file that was deleted by another user by creating huge empty file spanning almost all free space.
Some filesystems even support so called secure delete - that is, they can automatically wipe file blocks on delete (but this is not common).
You can try to write a utility which will open whole partition that your filesystem is mounted on (say, /dev/sda2) as one huge file and will read it and scan for remnants of your original data, but if file was fragmented (which is highly likely), chances are very small that you will be able to recover much of the data in some usable form.
Having said all that, there are some utilities which are trying to be a bit smarter than simple scan and can try to be undelete your files on Linux, like extundelete. It may work for you, but success is never guaranteed. Of course, you must be root to be able to use it.
And finally, if you want to be able to recover anything from that filesystem, you should unmount it right now, and take a backup of it using dd or pipe dd compressed through gzip to save space required.
i want to copy nk.bin to partition on wince 6.0.
i want that when i restart device then using redboot cammand it should be able to load nk.bin from partion. how to do this?
This is a broad and pretty platform-specific question. Forst, you've not told us much about your platform, so we have to make assumptions. I'll assume, based on you using redboot and talking about "partitions" that you'r running on ARM and that your OS image is stored in persistent storage (i.e. Flash).
The next question is "How and where is the OS stored?" This is platform specific, so only you (or your OEM) can say. It might be inside a FAT 32 volume or it might be written raw to a specific location in flash outside of any file system. If it's the former (it's probably not, or you likely wouldn't be asking the question), you could copy it. If it's just at some location raw, you're going to need APIs to directly access the flash. See if the OEM provided them (apps can't map direct to hardware in 6.0, so if there's no OEM-provided API, you'll have to write a driver).
You also need to know if you're XIP. If so, I don't think you're going to be able to copy the OS while it's running - at least I'd consider it a high-risk operation. In that case you likely need to set some sort of bit somewhere outside the existing file system (an EEPROM, scratch-pad regiter, raw flash, etc) and reboot, then modify the bootloader to make the copy.
THis all assumes you mean you want to copy it from on the device itself. You could mean you want to copy it using a JTAG tool as well, in which case everything I've said is irrelevant (except the location of the OS - and even that's not relevant if you're thinking you want to copy it from an outside source).
I have a linux busybox based system on a chip. I want to provide an update to users in the field and this requires updating some files in /lib /usr/bin and /etc. I don't think that it's safe to simple untar the files directly. Is there a safe way to do this including /lib files that may be in use?
Some things I strongly prefer in embedded systems:
a) Have the root file system be a ramdisk uncompressed from an image in flash. This is great because you can experimentally monkey around with it to your heart's content and if you mess up, all you need is a reboot to get back to the flashed configuration. When you have tested a set of change you like, you generate a new compressed root filesystem image and flash that.
b) Use a bootloader such as u-boot to do your updates - flashing a new complete image - rather than trying to change the linux system while it is running. Though since the flashed copy isn't live, you can actually flash it while running. If you flash a bad version, u-boot is still there to flash a good one.
c) Processors which have mask-rom UART (or even USB) bootloaders, making the system un-brickable - nothing more than a laptop and a serial cable or usb/serial converter is ever needed to do maintenance (ie, get a working u-boot image on the flash, which you then use to get a working linux kernel+compressed root fs image on it)
Ideally your flash device is big enough to partition into two complete filesystems and each update updates the other side (plus copying over config files if necessary) and updates the boot configuration to boot from the updated side.
Less ideal is to update in-place but have some means of detecting boot failure (watchdog that's not touched until after boot, for example) and have a smaller, fallback partition which is capable of accepting another update and fixing the primary partition.
As far as the in-place update of a live filesystem, just use a real installer (which will move the target files out of the way before replacing them to avoid the problem you describe).
You received two excellent answers above and I Strongly encourage you to do what you were advised to.
There is, however, a more simple way. In a matter of fact you can just untar your libraries, provided that the process that does this is statically linked.