I 'm use command disk oid (.1.3.6.1.4.1.2021.9.1.2.1) reference
set file "snmpd.conf" and restart serviec (service snmpd restart)
in file snmpd.conf"
disk /var/logs 10%
It is output image
but set file snmpd.conf
disk / 10%
It is work
but I want check size pathfile "/var/logs"
What should I do ?
Just a guess:
is /var/logs mounted from a partition? You can't check the space used by a generic directory, it must be a mount point.
Related
Context:
I am transferring a backup dir from Server A to Server B.(RHEL)
Directory size (to be transferred) on Server A: 48GB
Available space on Server B: 154GB
Command I'm using on Server A(user: root):
scp -r -C <nameof-backup-dir> user#severB:/path
Unexpected Behaviour:
The backup directory appears on the target server B #/path occupying all available 154GB of space.
Meanwhile the SCP run on the source server A terminates with an "Insufficent space message" for the remaining files.
Question/Help needed:
What am I doing wrong here?
What changes do I need to make to the SCP command to achieve the result?
One thing I can think of is that block sizes are different.
If block size on the destination machine is bigger, small files will occupy more space.
To find out block size :
sudo tune2fs -l /dev/sda1 | grep -i 'block size'
# Replace /dev/sda1 with your device (found out with command [df])
If it's indeed the case, you can recreate destination file system with the same block size as the source file system.
I have an odroid (raspberry-like) machine with an arch linux system installed. Now I want to move the system from one microsd (A) to another microsd (B). When I tried this, the system became corrupted, information about files attributes were lost:
Copy files from A to osx-host cp -R /Volume/microsd_a/* ~/Desktop/backup
Copy files from osx-host to B cp -R ~/Desktop/backup/* /Volume/microsd_b
Is it real to copy linux-system using osx-host with preserving integrity?
Update:
dd. I tried this way, but there is a problem. My sd cards have different sizes, 64 Gb and 16 Gb, but system installed on 64 Gb disk has no more than 8 Gb. So when I launched the copying process, output image file exceed 16 Gb and I killed the process. By the way, the MBR contains information about partition table which should be different (one partition 64Gb / one partition 16 gb). And notice, I do not need to copy bootloader from MBR, I have an ability to flash disk bootloader by other ways.
cp. What I wanted to listen as the answer is the list of flags I need to make this operation. Reading man cp didn't help me. cp -a does not copy all files because of Cannot allocate memory error. Tried cp -aX, no attributes were restored after copying data to second sdcard.
tar. I tried multiple times with flags, last one was tar -cvpf; tar --same-owner -xpf. But file attributes were still corrupted.
Again:
- Are you sure, it is possible to preserve file attributes through copying ext4 -> APFS -> ext4?
- If this is possisble, how does it work and which command with which flags should I use?
cp -R results in change of permissions, time stamps and missing of hidden files, you can't use that command to create a disk image.
what you need is a disk copy/clone. The command to use is dd.
Check out this webpage:
https://pbxbook.com/other/dd_clone.html
I have mounted a xen guest partition on /dev/mapper/vg01.
I also create a file let say in /home/user/a.txt
then I also ssh to the guest server and create file in /home/user/b.txt
in the terminal i did not see a.txt, b.txt
also the same in the mounted partition. i only see a.txt not b.txt
how can i fix this ? or maybe there is some other way for me to change the file ?
You can't mount a non distributed local filesystem from multiple locations at the same time, you'll end up corrupting it.
I am running Ubuntu Precise.
In my /etc/init.d I have a bash script that, does the following on startup:
loop mounts an image on an NTFS drive. That image contains an ext2 file system with a directory named home
It then does a mount with a --rbind option that mounts the home within the image file onto /home.
Works well so far, although having open files in /home doesn't prevent the loop mount from being unmounted.
Unfortunately, Nautilus displays the loop mount in the list of removable drives with an icon that allows a user to unmount the loop mount. Unmounting the drive on which /home is mounted is not conducive to a well running system.
How can I keep Nautilus from displaying this loop mounted device?
man udisk(7) says that one of the 'Influential device properties in the udev database' is:
UDISKS_PRESENTATION_HIDE
If set to 1 this is a hint to presentation level software that the device should not be shown to the user.
I assume that setting this property on the /dev/loop would tell Nautilus not to show the device.
How would I set the UDISKS_PRESENTATION_HIDE in a bash script?
The answer should now be updated (at least for Ubuntu 12.10).
You don't have to write this anymore (as was originally written in the other answer):
KERNEL=="sda1", ENV{UDISKS_PRESENTATION_HIDE}="1"
KERNEL=="sdb2", ENV{UDISKS_PRESENTATION_HIDE}="1"
Instead, you should write this:
KERNEL=="sda1", ENV{UDISKS_IGNORE}="1"
KERNEL=="sdb2", ENV{UDISKS_IGNORE}="1"
The rest is the same :)
You have to write the following on /etc/udev/rules.d/99-hide-disks.rules:
KERNEL=="sdxy", ENV{UDISKS_PRESENTATION_HIDE}="1"
Where sdxy is the partition inside /dev. You can easily find the partition by running mount (but I think you already know it).
Another approach is to mount the device somewhere other than under /media. I chose under /run, which allows /mnt to be used for temporary mounts.
According to the udisk page on archlinux wiki and to sum up the others answers:
Add a file named /etc/udev/rules.d/99-hide-disks.rules
For udisk:
# hide the device sda1
KERNEL=="sda1", ENV{UDISKS_PRESENTATION_HIDE}="1"
For udisk2:
# hide the device sda1
KERNEL=="sda1", ENV{UDISKS_IGNORE}="1"
# hide the device sda2 using UUID
# use: blkid /dev/sda2 to get the UUID of /dev/sda2
ENV{ID_FS_UUID}=="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX", ENV{UDISKS_IGNORE}="1"
I'm using udev to detect USB drive connection and disconnection on my Ubuntu 10.04 LTS x64 server. Everything works fine when USB devices are connected while the machine is running, but if one is already present at boot time, my script does not complete, apparently because mkdir /tmp/blah doesn't work.
If I subsequently type sudo udevadm trigger at the terminal, everything is okay.
I'm assuming that at the point that udev first evaluates connected devices against its rules, the root filesystem has not been mounted.
My questions are therefore:
Have I correctly identified the problem?
Is there a standard way to solve it - i.e. is there an alterative to /tmp/ that I can use both
before and after / has been mounted?
The root filesystem is mounted, but is read-only at the time. /dev/shm (an in-memory filesystem) should be available; newer linux distributions may also have a /run ramdisk. You can also pick a permanent directory somewhere, mount a tmpfs over it in your script, and do your work there.
One solution to this problem is to write a script that's called by your udev rules that immediately detaches, and waits for some event to occur to ensure the system is "booted enough" to create mount points, etc. to mount your devices. The person who answered the following post (http://superuser.com/questions/53978/ubuntu-automatically-mount-external-drives-to-media-label-on-boot-without-a-u) wrote a script that checks if "httpd" is running before continuing on. I'm sure there are probably other "better" ways to do this too.
1- I don't know, even in the initramfs, before the root filesystem is mounted, there is a writable /tmp directory.
True, when the real root is mounted this /tmp will be discarded and the final /tmp will be empty. Are you sure that the mkdir /tmp/blah command is failing? Or do you assume that because it is not there when you look for it?
2- In Ubuntu (I don't know of other distros) you have a hidden directory in /dev/.initramfs for these kind of needs. Since /dev is a tmpfs (or devtmpfs) mountpoint preserved in final root filesystem you will still have it there.