A fantastic “feature” of Linux, BSD, and even Windows 10 is you don’t really need to reinstall to migrate an installation to a new computer. A common misunderstanding is if you get a new PC, you must use the new OS install, or install a new copy of your OS. If you’re intending on replacing an existing PC (and disposing of or re-purposing the old one), there is probably no need to reinstall your OS and deal with user data migration.
I seem to have a lot of suggestions to share with friends about managing disks on a linux livecd. Here are some of the tips I’d like to share. See the table of contents above for a breakdown of the topics discussed. Some disk related topics are out of scope for this article, as they deserve their own blog post. The topics not covered include partitioning, setting up a boot loader, using LVM2 or ZFS, that sort of thing.
You want to use sudo -i or su - to log into root. sudo su anything is superfluous, because you probably should be using sudo -i or sudo -s, which are roughly equivalent, depending if you want to simulate a login (su - or sudo -i) or not (su or sudo -s).1 When to use su -? You want to log into root using the root password. Typically you must be in the wheel group (check your PAM configuration).
Sometimes I find myself setting up servers on networks with less than ideal network configuration. Most home internets use dynamic IP addresses, which requires extra work to ensure I know the IP address to use when logging into the network from the internet. Another concern is how unreliable home networking gear can be, especially with users tweaking settings without fully appreciating what they’re doing. As a result, I’ve devised an alternate solution to ensure I can always log into boxes hosted on home internet connections.
For a couple months now, I have noticed that running dmesg -w on my workstation does not appear to print out new kernel messages. In other words dmesg --follow “hangs”. Additionally when running tail -f /var/log/kern.log to monitor new dmesg messages picked up by sysklogd (part of syslogng), the latest messages do not come through until sysklogd periodically “reopens” the /dev/kmsg kernel message buffer. Why is this a problem? This is a problem because I use the dmesg log to monitor important hardware related messages such as the kernel recognizing a USB device or diagnosing bluetooth/wifi issues.
Most of my workstations & laptops require a passphrase typed in to open the encrypted root filesystem. So my steps to booting are as follows: Power on machine Wait for FDE passphrase prompt Type in FDE passphrase Wait for boot to complete and automatic XFCE session to start Since I need to know when the computer is ready to accept the passphrase, it is important the framebuffer is usable during the early part of the boot.
Redshift is a screen-tinting program that achieves similar goals to the popular f.lux1 program. I perused through the redshift man-pages and noticed there is no documented way to toggle redshift. Of course one can click the notification area icon when using redshift-gtk or SIGTERM the redshift process, but neither is very user friendly. (The mouse is not user friendly.) After some awkward DuckDuckGo-ing and Googling I found an obvious solution on the redshift homepage2: simply send SIGUSR1 to the redshift or redshift-gtk process.