I have a CentOS7.0 VM with virtio disk that has multiple partitions.
These disk partitions are named as vda1, vda2, vda3 etc by default.
But, I want to name them as sda1, sda2 etc as the application that
i am running on it expect the partition name start with sda.
I have tried to chage the rules for virtio-blk in
/lib/udev/rules.d/60-persistent-storage.rules from
# virtio-blk
KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
to
# virtio-blk
KERNEL=="sd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
KERNEL=="sd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
But, I still see the partition name starts with vda.
Hence, I am trying to create a symlink for the vda device.
I am not sure how to write a udev rule to create the following
symlinks.
sda1 -> vda1
sda2 -> vda2
sda3 -> vda3
Could anyone please let me know how to do this?
$ ln -s vda1 sda1
$ ln -s vda2 sda2
$ ln -s vda3 sda3
should do it, assuming you're in the directory where the vdan's are.
Related
I'm trying to backup a large directory (several terabytes) to google cloud, using the following command:
gsutil -m rsync -r -e local_dir/ gs://target/bucket
In summary, run in parallel (-m), recursively (-r) search the directory local_dir/ (don't follow symlinks -e), and store it remotely in the bucket gs://target/bucket.
This operation completes succesfully:
[666.4k/666.4k files][ 6.3 TiB / 6.3 TiB] 100% Done
Operation completed over 666.4k objects/6.3 TiB.
One thing that worries me, however, is that the folder size is different when I run du:
$ du --max-depth 1 -h local_dir/
...
7.6T local_dir
Can anyone explain where the discrepancy of more than 1 TiB comes from, compared to what gsutil transfered, and what du reports?
Part of the difference is that Linux du is reporting in units of terabytes (10^12 bytes), while gsutil cp is reporting in units of tebibytes (2^40). Thus, the Linux du units are 1.0995 times larger than the gsutil cp units. Additionally, directories and inodes consume space beyond the file data bytes. For example, if you run these commands:
mkdir tmp
cd tmp
for f in {1..1000};do
touch $f
done
du -h
it reports 24K used, even though each of the files is empty (so, an average of 2.4k bytes per inode). And if you remove the temp files and run du -s on the directory, it consumes 4k bytes. So, your 666.4k files would consume approx 16 MB plus however much for the number of directories that were contained. Also, the amount used may differ depending on the type of filesystem you're using. The numbers I reported above are for an ext4 filesystem running on Debian Linux.
I have a linux application which loads *.so libraries using a modified rpath (set during installation). It also needs to run with realtime priority.
To get realtime priority it does this:
sched_param sched;
sched.sched_priority = 70;
sched_setscheduler(getpid(), SCHED_FIFO, &sched);
However sched_setscheduler is a privilaged method, protected by the CAP_SYS_NICE capability. Therefore, to get realtime priority without running as root, I add setcap to my postinst:
setcap cap_sys_nice+ep /path/to/myapp
However, linux decides that programs should not be allowed to load libraries from rpath if they have extra capabilities.
Is there a way for me to set my own priority and load rpath libraries?
Note: I'd prefer to do this in the application or in the postinst. I'd like to avoid deploying scripts as the only way to launch the application. I know sudo chrt -f -p 70 $! could do it from a script.
I have two solutions which do not involve modifying libc. Both solutions require us to replace the calls to sched_setscheduler() with a call to launch another process directly.
Install a file to /etc/sudoers.d/ with the following line:
%users ALL=NOPASSWD: /usr/bin/chrt
Then from our application launch sudo as a process with arguments chrt -f -p X Y where X is the configured priority and Y is the result of getpid().
Create a custom chrt with:
cp $(which chrt) $(DESTDIR)/bin/chrt
sudo setcap cap_sys_nice+ep $(DESTDIR)/bin/chrt
sudo chmod 755 $(DESTDIR)/bin/chrt
Then from our application launch chrt as a process with arguments -f -p X Y
Not sure which solution is better. Note this is effectively embedded (or at least purpose built) so I'm not too worried about the security exposure.
I am trying to create a kickstart for Centos 7.3. I have a windows desktop with VMware Workstation Player installed. I started with a dvd that has Centos 7.3 on it. I then created a vm in VMware Workstation Player and installed the os. I restarted the vm and copied over all the files from /dev/sr0 from my dvd to a new place. I copied the anaconda file and renamed it to ks.cfg. I then used the command below to make an iso.
mkisofs -o /home/kickstart.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-road-size 4 -boot-info-able -J -R -v "centos7.3"
Next I took this and burned it to a blank cd using
growisofs --dvd-compat -Z /dev/cdrom=/home/kickstart.iso
When I use this in VirtualBox as the optical drive mounted the installer gets stuck on
Started Show Plymouth Boot Screen
Started Device-Mapper Multipath Device Controller
Starting Open-iSCSI...
Reached target Paths.
Reached target Basic System.
Started Open-iSCSI.
Starting dracut initqueue hook..
then on VMware Workstation Player it goes to
Started Show Plymouth Boot Screen
Started Device-Mapper Multipath Device Controller
Starting Open-iSCSI...
Reached target Paths.
Reached target Basic System.
Started Open-iSCSI.
Starting dracut initqueue hook..
... [sda] Assuming cache: write though
Why is it hanging on these spots? I have tried looked everywhere and can't seem to find any solutions so far.
you've probably found something else for this but in case not, or in case someone else encounters this... I encountered some issues with this as well. I don't know if I have the exact issue, though it was hanging on dracut init, and changing this bit allowed the install to continue.
What it turned out to be was the -V flag on the mkisofs command. Whatever you name it with the -V flag (which it doesn't look like you have), it needs to be the value of LABEL in your /isolinux/isolinux.cfg file. In my fiddling I was using "MyLinuxISO" for this value.
in my /isolinux/isolinux.cfg:
label linux
menu label ^Install CentOS Linux 7 with KS
menu default
kernel vmlinuz
append initrd=initrd.img inst.stage2=hd:LABEL=MyLinuxISO ks=cdrom:/ks.cfg
using mkisofs
mkisofs -o /home/kickstart.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-road-size 4 -boot-info-able -J -R -v -V "MyLinuxISO"
Don't know if this will help you but give it a shot?
Cheers
I'm trying to establsih serial communication with an Arduino through USB (running Arch Linux). I can do it in a straightforward way trough a C++ program and using boost::asio, but recently I installed Matlab and been encoutering some issues. I manage to create the serial object with s0=serial('/dev/ttyACM0') but when I call fopen(s0) I get the following error:
Error using serial/fopen (line 72)
Open failed: Port: /dev/ttyACM0 is not available. No ports are available.
Here is what I did to get serial port communication work in Matlab R2014a on Arch Linux 64 bit:
1a) follow the steps described here: http://www.matlabarduino.org/serial-communication.html:
sudo chmod 777 /dev/ttyACM0
Alternatively, add your user to the group uucp: > sudo gpasswd --add username uucp
sudo nano $MATLABROOT/bin/$ARCH/java.opts --> add: -Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyACM0
1b) check that the connection works in gtkterm (select port ttyACM0)
2) additionally (critical only for Matlab):
sudo chmod 777 /run/lock
/run/lock was symlinked from /var/lock on my distro, so you might have to do this with the latter dir (was 755); alternatively, you can manage access rights to /run/lock/ by ACL.
How I got to this solution:
sudo strace -p 4668 -f -s100 2>&1 | grep -C3 --color -i -e /dev -e serialports -e uucp
-p: process ID == second column from > sudo ps -aux | grep -i matlab
Then, in Matlab type >> sps=instrhwinfo('serial') (which in my case always returned a structure of empty cell-arrays) and monitor the output of strace.
Hope that helps!
cheers :)
By default, only root can use the serial port.
And you can add your id to the serial group "dialout", so you can use the serial port.
Just make soft link from /dev/ttyACM0 to /dev/ttyS[0-255].
ln -sf /dev/ttyACM0 /dev/ttyS100 # for example
Below Matlab R2017a may face this issue.
Detailed Description can find here:
Why is my serial port not recognized with MATLAB on Linux or Solaris?
Hope this can be helped.
I've got problems installating the VMWARE ESXi Server.
The Installation finishes without any error messages and prompts me to reboot.
After pressing Enter the System reboots. While booting through the yellow loading-screen it switches to black and displays the following Error-Message:
PANIC: Failed to find HD boot partition
All modules have been loaded without any errors.
After typing unsupported into the console the busybox comes up.
I tooked a look into the /dev/disks directory but no disk devices gets listed in difference to the installation process.
Switching to the system-console during installation both sata disks on MPC51 controller are shown.
The controllers are named vmhba0 and vmhba32.
Does anyone know how to solve the problem?!
Hardware is a ESPRIMO P5615 (nForce4) from Fujitsu-Siemens.
The only solution I have found is to run the server from a thumb drive and use the embedded hard drive to store your virtual servers. This solution worked for me.
To achieve this in this way you will need:
A USB thumb drive 1GB or larger
An active Linux machine (or, use a liveCD option on your PowerEdge such as Knoppix or Gentoo LiveCD)
Mount your ESXi ISO:
mount -t iso9660 -o loop VMware-VMvisor-InstallerCD-3.5.0_Update_2-110271.i386.iso /mnt/esx
Write the installer file to the thumb drive:
tar xvzf /mnt/esx/install.tgz usr/lib/vmware/installer/VMware-VMvisor-big-3.5.0_Update_2-110271.i386.dd.bz2 -O | bzip2 -d -c | dd of=/dev/sdb
Assumptions here (adjust to your settings):
/dev/sdb is where your thumb drive resides
VMware-VMvisor-InstallerCD-3.5.0_Update_2-110271.i386.iso is the name of your ISO file
usr/lib/vmware/installer/VMware-VMvisor-big-3.5.0_Update_2-110271.i386.dd.bz2 is the name of the dd file in your iso (run tar ztf /mnt/esx/install.tgz to see what your exact file name is, it should be similar and relatively obvious)
It will take a few minutes to write, and when it's done simply boot off of this thumb drive. The PowerEdge servers have an internal USB (at least mine does) if aesthetics are important to you.
Source: http://cyborgworkshop.org/2008/08/30/install-vmware-esxi-onto-a-usb-thumbdrive/
EDIT 12/19/2009: ESXi 4.0.0 uses image.tgz instead of install.tgz to store it's dd file