I am looking for some one to direct me,
I have developed a software that automatically erase data from lan attached workstation's hard disk drives. Once the data is erased storage device is emptied and there is nothing on the hdd. I am thinking about writing a text file on each hard drive that contains the hardware information such as hdd size, ram, processor and etc, this file will be placed on each hdd after successful wipe.
Wgen the workstation that was just wiped is booted each time, l want to display a data erasure report similar to this one on every boot, obliviously data is read from text file and displayed on every boot. I want to display logo and the text together so it will be combination of text and graphics.
The question is how i can display such information without installing full operating system.
Your help is appreciated.
This is an example of the data i want to display on each boot. Once the data is display system should be halted.
Related
Today I just realized in my Ubuntu Linux, I can mount and store files on my newly purchased hard drive as a raw device without a file system. (as long as I partitioned the disk correctly)
So, I am not sure if my below statement is correct, looking for expert to answer:
Looks like it's not required to create a file system on a disk in order to use it in Linux? Is it correct?
I have some very basic understanding of how a file system works. In Linux, is the concept of "inode" a file system feature or a Linux feature?
I understand that the "inode" file system works unlike NTFS or FAT32 that it tries to spread out the data across the disk so that Linux/Unix doesn't need as Windows like "defgramentation" program to keep data in consecutive chunks. My question is, if I am storing my data on a raw device without a file system, and if "inode" is a file system feature not a Linux feature, what will the actual data layout look like on the raw device then?
Thanks in advance
I am wondering if it is possible to have a usb key in a raw format and still read/write files on it.
It should be cross-platform and understood by a dedicated software we ship.
I am kind of creating a non-bootable file system in a hurry, and I just need to read/write some values at some offsets on this raw storage space.
People who will use it will be shipped the software able to read those values (not the operating system who will surely see raw/free space, but we don't care about that).
Will I run into troubles with the mounting, or whatever?
Or is it green light?
Thanks
Yes, absolutely, you can read and write the "unformatted" SD card or USB memory. You can also format it to whatever filesystem you need by writing to pages of that memory. The only possible difficulty is that the OS (at least later Windows versions) might not allow writing to the disk if the user account doesn't have admin rights.
I've recently bricked one of my embedded Marvell ARM systems, was upgrading to a new u-boot.bin over TFTP from within u-boot via the bubt tool. bubt fetched the image, burned it to Flash, didn't give any output saying there was anything wrong.
On reboot the system got stuck in an endless loop on the primary bootloader.
Therefore my question is, does the u-boot.bin file have any inbuilt checksums, magic header numbers etc. that could be used to validate the file is good before burning it?
No, there isn't. .bin is a raw image of u-boot.
You could do it yourself encapsulating the raw file into a image file, e.g.: with a file header the hold a CRC32, length of file and so on.
Take notes that the standard u-boot upgrade procedure delete the existant one before to flash the new one. If something happend between cancellation and re-flash the board will be corrupted.
BTW are you sure that your problem belong to a wrong write to memory, and not to a bugged u-boot?
After running BitBake on several different recipe files, BitBake generates a file of type '.hddimg'. I haven't been able to find a clear explanation on what this file is used for, the closest that I have found is some speculation on the mailing list here. The author Paul states that:
the image isn't an image of a regular bootable system drive, but is a "live
image" of a smaller system that can either boot the real system from a
virtualized file system in RAM whose image is read from a single file in the
first level, or it can install the real system to a different drive.
The 'bootimg.bbclass' is what generates the .hddimg, and in the opening comments it is written that:
A .hddimg file [is] an msdos filesystem containing syslinux, a kernel, an initrd and a rootfs image. These can be written to harddisks directly and also booted on USB flash disks (write them there with dd).
Which appears to corroborate with what Paul wrote, but still leaves a lot of ambiguity on how to go about booting from this file (at least to a greenhorn like me).
Well, the doc says "write them there with dd". So:
dd if=/path/to/your/hddimg of=/path/to/raw/usb/device
so, if you have the file as my.hddimg and the usb flash disk appears as /dev/sdg
dd if=/home/karobar/my.hddimg of=/dev/sdg
As it's name implies, it's an image, so needs to be written as such. The actual file system is inside of the rootfs file, which is similarly an image!
Once you have that on the usb stick, the usb stick itself should be bootable. Depending on what you're trying to do this may not be the easiest kind of output from bitbake to work with.
Is there a way to purposefully corrupt a FAT file system using only Win32 calls or must you do it at lower level? We're encountering FAT corruption on a WinCE 5.0 device and have written a utility to detect and attempt to correct it, but don't have a means to create FAT corruption on demand. Thanks.
The media is a CF card, but it's not removable as a normal course as it's mounted internal to the device.
What's the FAT on (e.g. inserted USB, on-board flash, etc)? That's going to make a large difference.
If it's the on-board flash, you need to get underneath the file system driver (FSD), which is typically going to be the flash driver itself. It's going to have access to the raw flash sectors (it's what the FSD uses for its reads and writes) either through Xxx_Write or Xxx_Ioctl. Exactly how it works is going to depend on the flash driver in use, so looking at the driver source is your best path.
You can access device data as a raw file and write random data in that file to corrupt FAT. E.g. if you write random data on:
\?\Device\HarddiskVolume1
This would corrupt first partition.
This page has some hints on how to figure out paths for HDD/USB drive etc.
http://www.chrysocome.net/dd