Tesla Ye Nash

Since the advent of systemd the use of /etc/rc* startup-scripts has been discouraged and phased out. However, systemd still supports the use of certain local startup scripts for compatibility purposes. Nevertheless, to ensure full current- and future compatibility with systemd , administrators are encouraged to create own systemd service files or udev rules to run scripts during boot.  This post will briefly outline the use of a udev rule to assign a specific I/O scheduler to a specific HDD. NOTE To see an example using the phased-out rc-startup scripts, take a look at my previous post . Create a custom rules-file, e.g. 99-custom.rules , in the /etc/udev/rules.d/ directory with your editor of choice.  The following example will instruct udev to assign the deadline I/O scheduler to the /dev/sdb device: # vim /etc/udev/rules.d/99-custom.rules ACTION=="add|change", SUBSYSTEM=="block" , KERNEL=="sdb*", RUN+="/bin/sh -c 'echo dead

Since the advent of systemd the use of /etc/rc* startup-scripts has been discouraged and phased out. However, systemd still supports the use of certain local startup scripts for compatibility purposes. This post will briefly outline the use of the /etc/rc.local file to assign a specific I/O scheduler to a specific HDD. At the moment, I have an SSD drive (primary /dev/sda) and an "old-fashioned" HDD (/dev/sdb) in use on my RHEL7 system.  I'd like to be able to use the deadline I/O scheduler as the default and assign the cfq scheduler to the HDD device.  In RHEL7 the default I/O scheduler can change based on the selected tuned profile, which adds an additional layer of uncertainty if you're unaware of "tuned".  The default tuned profile is throughput-performance , which enables the deadline scheduler by default among other performance-related system settings.  However, if the default profile is changed to , e.g. virtual-host , the scheduler of choice

"God" help you if you make the mistake, as I did today on a newly-installed Fedora21 system, to delete an LVM swap partition without taking the proper precautions before rebooting. If you are in this position, or have been in the past, you've come face to face with the dracut rescue shell and its limited set of "shell" commands. While the rescue shell offers some potentially useful functions (commands), I could not successfully use it to implement any of the advised steps from manual pages and internet forums I came across when searching for a solution to this problem. The  Fedora Wiki page on "How to debug Dracut problems" suggested activating the root and any other logical volumes by executing  # lvm vgscan # lvm vgchange -ay "With the root volume available, you may continue booting the system by exiting the dracut shell" exit Though, in fairness, that resolution was dealing with unlocking an encrypted root volume with an addit