I need to create a floppy file to mount and copy files. I also need to change the mbr. When I do this:
mkdir -p disk_images
rm disk_images/floppy.flp
dd if=/dev/zero of=disk_images/floppy.flp bs=1k count=1440
mkdosfs -F 32 disk_images/floppy.flp
mkdir floppydisk
dd status=noxfer conv=notrunc if=build/boot.bin of=disk_images/floppy.flp
sudo mount -t vfat -o loop,defaults disk_images/floppy.flp floppydisk
I get the error
mount: /home/user/myos/floppydisk: wrong fs type, bad option, bad superblock on /dev/loop13, missing codepage or helper program, or other error.
omitting the last dd works but that way, I can't control the mbr.
Related
I'm experimenting with cryptsetup. My target is to be able to store data into and encrypted file into a non-encrypted hard drive.
I'm doing the following
mkdir /data/test && /data/test
# Create a key
openssl genrsa -out luks_key 4096
# Create file container
dd if=/dev/zero of=device bs=1G count=50 status=progress
# Create and open luks device
cryptsetup -v -y --batch-mode luksFormat device luks_key
sudo cryptsetup -v --batch-mode --key-file=luks_key --type luks open device device_name
# Format the device
sudo mkfs.ext4 -j /dev/mapper/device_name
# Create mount point
mkdir mount_point
# Mount the device
sudo mount -t ext4 /dev/mapper/device_name mount_point
cd mount_point
sudo dd if=/dev/zero of=random_data.bin bs=1G count=1 status=progress
# This will fail until I close the terminal window with "target is busy." error
sudo umount /data/test/mount_point
cryptsetup -v close device_name
All works well up to the point were I try to unmount. The error is:
umount: /data/test/mount_point: target is busy.
The only way to be able to unmount is to close the terminal window. Opening a second one isn't enough. I'm little bit puzzled :)
I run on LinuxMint 18.04 with Linux kernel 5.15.30-25.
Anyone seeing the same thing?
Thanks,
I am operating a Linux live image on a small USB flash drive and would like to flash an SD card with it. The image is zipped already too big for my flash drive, so I can not write it to disk. I have enough RAM to buffer the zipped and the unzipped image, so my solution was this:
$ sudo mount -t tmpfs -o size=2.5G none /mnt
$ cd /mnt && wget http://example.com/linux.zip
$ cd /mnt && unzip linux.zip
$ sudo dd if=/mnt/linux.img of=/dev/sdb bs=4M
This feels cumbersome. How one write an image to SD card, unzipped from an archive, downloaded from the internet, without writing anything to disk in one line?
Try with this:
wget http://example.com/linux.zip -q -O -| funzip | dd of=/dev/sdb bs=4M
If your live image comes with curl, funzip and dd, something like the following should work:
$ curl -L http://example.com/linux.zip | funzip | dd of=/dev/sdb bs=4M
I am new to fuse. When I try to run a FUSE client program I get this error:
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
I understand that a mountpoint is the directory where you will logically attach the FUSE filesystem. What will happen if I mount to this location? What are the dangers? Is it just that the directory will be overwritten? Basically: what will happen if you mount to a non empty directory?
You need to make sure that the files on the device mounted by fuse will not have the same paths and file names as files which already existing in the nonempty mountpoint. Otherwise this would lead to confusion. If you are sure, pass -o nonempty to the mount command.
You can try what is happening using the following commands.. (Linux rocks!) .. without destroying anything..
// create 10 MB file
dd if=/dev/zero of=partition bs=1024 count=10240
// create loopdevice from that file
sudo losetup /dev/loop0 ./partition
// create filesystem on it
sudo e2mkfs.ext3 /dev/loop0
// mount the partition to temporary folder and create a file
mkdir test
sudo mount -o loop /dev/loop0 test
echo "bar" | sudo tee test/foo
# unmount the device
sudo umount /dev/loop0
# create the file again
echo "bar2" > test/foo
# now mount the device (having file with same name on it)
# and see what happens
sudo mount -o loop /dev/loop0 test
Just add -o nonempty in command line, like this:
s3fs -o nonempty <bucket-name> </mount/point/>
Apparently nothing happens, it fails in a non-destructive way and gives you a warning.
I've had this happen as well very recently. One way you can solve this is by moving all the files in the non-empty mount point to somewhere else, e.g.:
mv /nonEmptyMountPoint/* ~/Desktop/mountPointDump/
This way your mount point is now empty, and your mount command will work.
For me the error message goes away if I unmount the old mount before mounting it again:
fusermount -u /mnt/point
If it's not already mounted you get a non-critical error:
$ fusermount -u /mnt/point
fusermount: entry for /mnt/point not found in /etc/mtab
So in my script I just put unmount it before mounting it.
Just set "nonempty" as an optional value in your /etc/fstab
For example:
## mount a bucket
/usr/local/bin/s3fs#{your_bucket_name} {local_mounted_dir} fuse _netdev,url={your_bucket_endpoint_url},allow_other,nonempty 0 0
## mount a sub-directory of bucket, Do like this:
/usr/local/bin/s3fs#{your_bucket_name}:{sub_dir} {local_mounted_dir} fuse _netdev,url={your_bucket_endpoint_url},allow_other,nonempty 0 0
force it with -l
sudo umount -l ${HOME}/mount_dir
What variables can produce different md5sum of the same dd image of a partition?
If I execute this code over two storages (same size, brand and geometry) why I obtain different "partition.image" files:
sfdisk /dev/sda < /partition.table
mkfs.ext4 /dev/sda1
mount /dev/sda1 /mnt/
tar -xf somefiles.tar -C /mnt/
umount /mnt
dd if=/dev/sda1 of=/partition.image
P.S. tar is preserving all files timings!
When you make a new ext4 filesystem with the mkfs utility, it generates a unique UUID between invocations(unless you pass the -U option with an explicit UUID). Since the UUID is stored in the superblock of the file system, the images you generate between different runs of the above code will not be bit-for-bit identical.
Sources: http://wiki.debian.org/fstab#UUIDs
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Time of creation, access etc. And that's good - no two images, created at different storages should be the same. Or otherwise, you could have something called "collision".
I have an embedded device where i need to put my /var and /tmp in ram in order to diminish the number of writes on the drive (Compact flash). I know how to do it with /tmp as i don't have to recover anything whenever i reboot or shutdown.
But the /var directory has important stuff. I have been researching and i found this, but it doesn't seem to be working.
Here is the script:
# insert this on file 'rc.sys.init'
# after the mount of the root file system
# to create the /var on ramdisk
echo "Create ramdisk........."
#dd if=/dev/zero of=/dev/ram0 bs=1k count=16384
mkfs.ext2 -j -m 0 -q -L ramdisk /dev/ram0
if [ ! -d /mnt/ramdisk ]; then
mkdir -p /mnt/ramdisk
fi
mount /dev/ram0 /mnt/ramdisk
if [ -L /var ]; then
tar -xf /vartmp.tar -C /mnt/ramdisk
else
tar -C / -cf /vartmp.tar var
cp -a /var /mnt/ramdisk
rm -rf /var
ln -s /mnt/ramdisk/var /var
fi
# insert this into file 'halt'
# to stop the ram disk properly on shutdown.
#
if [ -e /vartmp.tar ]; then
rm -f /vartmp.tar
fi;
tar -C /mnt/ramdisk -cf /vartmp.tar var
Is there any problem with this script? If not, in which inicialization and termination script should i include them?
For all that have the same problem i do i have solved my problem (kind of)
The two scripts i posted are correct and accomplish the job. What you have to be careful is where you put them.
In Slackware the first run script is rc.S. At first i copy pasted my first script into the middle of that one. It definitely should be there, just not where i put it. You have to see where does the script rc.S call for a particular directory or file from /var. The creation of the ramdisk should be before those lines.
the shutdown script should be added in the bottom of the rc.6 script (shutdown script)
Also i should point out that although this improves the life expectancy of the drive, it is a little volatile and sometimes randomly reboots, so be careful.
Nice script...but it seems to me that it is volatile for several reasons. First did you tell the system max ramdisk size...first as a kernel argument.....linux /vmlinuz ramdisk_size=204800......then in rc mke2fs -t ext2 /dev/ram1 204800.....and maybe use ram1 not ram0.......also use a script for manual saving of ramdisk contents to /var.....cp -a /mnt/ramdisk/var/. /var........backup real /var to another directoryusin tar compression, but introducing tar compression to reduce data size probably introduces lag, latency and instability. Just seems to me to be so.