centos Administration and Usage Archives

Change Your Hostname in CentOS 8

Changing your computer or servers hostname is an infrequent activity for most. But if you are like me periodically I will hastily provision a VM. And only realize after the provisioning is complete that I should have used a more descriptive hostname. Or to have chosen a hostname that fits in the theme of the other servers (Middle Earth, Stormlight Archive, Planets, etc…). But sometimes that process can be tedious and end up with you questioning if you got it right. Fortunately it is easy to change your hostname in CentOS 8.

The ever useful “hostnamectl” command makes this a simple process. If you execute the command with no options it will give you the current hostname as well as many details about the system.

[bdoga@host ~]$ hostnamectl
   Static hostname: host.bdoga.local
         Icon name: computer-vm
           Chassis: vm
        Machine ID: b1ce9c049f6d4a9589ad540ae9aa1c43
           Boot ID: 1906ec0120c246aa84bd407e46a237b6
    Virtualization: kvm
  Operating System: CentOS Linux 8 (Core)
       CPE OS Name: cpe:/o:centos:centos:8
            Kernel: Linux 4.18.0-147.8.1.el8.lve.1.x86_64
      Architecture: x86-64

Change Your Hostname in CentOS 8

As shown in the example above, this servers hostname is “host.bdoga.local”. But I am ready for a change, and want to start naming my servers with Stormlight Archive Names. One of my favorite characters is Kaladin, and I want to have this server on my full domain “bdoga.com”. So to change the domain name to “Kaladin.bdoga.com” I would issue the following command.

[bdoga@host ~]$ sudo hostnamectl set-hostname kaladin.bdoga.com

After issuing the command you will not see any sort of confirmation. You should just be greeted with an empty command prompt, but with your new hostname.

[bdoga@host ~]$ sudo hostnamectl set-hostname kaladin.bdoga.com
[bdoga@kaladin ~]$

And there you have it, you have changed your hostname in CentOS 8. This method should also work for Ubuntu 16.04+, Debian 8.0+, CentOS 7+, and other Systemd based systems.

To learn some more details about this and other tools for changing your hostname on Centos 8 please visit linuxize’s post.

And feel free to check out some more of our content regarding CentOS based systems. Or visit some of our posts that will help you increase your Command Line prowess.

How to Fix: “warning: device is not properly aligned” with Parted

Because you are on this page I assume you have received the same warning I did. “warning: device is not properly aligned”. I allocated a new 1 TB iSCSI drive and I attached it to the initiating server. After the iSCSI device was connected I partitioned it to use 100% of the disk. Then I attempted to format the partition with the XFS file system using the following command.

mkfs.xfs /dev/sdb1

I immediately got the following response:

warning: device is not properly aligned /dev/sdb1
Use -f to force usage of a misaligned device

Finding the fix for “device is not properly aligned”

So I did some digging and came across this article about how to properly align the partition. I followed the post to grab the following values from the device.

[root@server ~]# cat /sys/block/sdb/queue/optimal_io_size
1048576
[root@server ~]# cat /sys/block/sdb/queue/minimum_io_size
131072
[root@server ~]# cat /sys/block/sdb/alignment_offset
0
[root@server ~]# cat /sys/block/sdb/queue/physical_block_size
131072

Following the formula that was outlined (optimal_io_size + alignment_offset) / physical_block_size. And got the following results: (1048576 + 0) / 131072 = 8. I plugged that information into parted, which resulted in mixed results.

(parted) mklabel gpt                                                      
Warning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes 
                                                              
(parted) mkpart primary 8s 100%
Warning: You requested a partition from 4096B to 1074GB.                  
The closest location we can manage is 17.4kB to 1074GB.
Is this still acceptable to you?
Yes/No? Yes     
                                                          
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? Ignore 
                                                    
(parted) align-check optimal 1                                            
1 not aligned

Making Sense of the Parted Alignment Response

So my drive was still not properly aligned, but I had some better info which would help me fix the problem. So let’s break down the Parted commands

(parted) mklabel gpt

Destroyed the existing partition table and cleared things out to start fresh.

(parted) mkpart primary 8s 100%

This command told Parted to create a new primary partition starting at sector 8 and use the rest of the drive. The response that came from this command gave me the clue that I needed to fix the alignment.

Warning: You requested a partition from 4096B to 1074GB.
The closest location we can manage is 17.4kB to 1074GB.

The warning output indicated that 8 sectors of 512B would only come to 4096B or 4kB. But Parted could only adjust the alignment to 17.4kB, so this was still out of alignment as the rest of the output indicated. That gave me the clue I needed to fix it though.

Alignment Fixed

Knowing now that Parted could only get within 17.4kB of the start of my drive I adjusted the sectors to match that. Since 8 sectors was 4096B, I adjusted it to be an even number of sectors beyond the 17.4kB point. Choosing 32768B, or 64 sectors. This change yielded the following results.

(parted) mklabel gpt
Warning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes                                                               

(parted) mkpart primary 64s 100%

(parted) align-check optimal 1
1 aligned

(parted) quit                                                             
Information: You may need to update /etc/fstab.

The partitioning was successful, using the 64 sector starting point pushed it beyond the 17.4kB point. Then it was properly aligned. I formatted the partition with XFS and all went swimmingly.

[root@server ~]# mkfs.xfs /dev/sdb1
 specified blocksize 4096 is less than device physical sector size 131072
 switching to logical sector size 512
 meta-data=/dev/sdb1              isize=256    agcount=32, agsize=8191872 blks
          =                       sectsz=512   attr=2, projid32bit=0
 data     =                       bsize=4096   blocks=262139648, imaxpct=25
          =                       sunit=32     swidth=256 blks
 naming   =version 2              bsize=4096   ascii-ci=0
 log      =internal log           bsize=4096   blocks=128000, version=2
          =                       sectsz=512   sunit=32 blks, lazy-count=1
 realtime =none                   extsz=4096   blocks=0, rtextents=0

Now the device is formatted, mounted, and working like a champ. Who would have known that a simple offset of 32kB could make such a problem.

If you are working with iSCSI then you may find you need to force disconnect and reconnect iSCSI on from time to time. Check out my post on how I handle that.

Force Disconnect iscsi and Reconnect iscsi on centos6+

We’ve all been there, having a webserver which is running low on diskspace. I added an iscsi filesystem to provide sufficient space for creating backups of the system. I host the iscsi filesystem on a FreeNAS box, which usually runs great. But periodically it appears that a bug in the system causes the FreeNAS box to reboot. Then my webservers iscsi connection gets confused and I get to take drastic measures. I force disconnect iscsi and reconnect it.

Force Disconnect iscsi

After ensuring that the FreeNAS box is running properly, I unmount the drive on my webserver.

umount /dev/sda1

I get the details of the existing zombie session with this command.

iscsiadm -m session -o show
 
tcp: [3] 192.168.0.253:3261,2 iqn.2005-10.org.freenas.ctl:tmpfs (non-flash)

The response shows the details of the active session, the IP address and port, as well as the iqn string. I use them in the following command to force disconnect iscsi.

iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:tmpfs -p 192.168.0.253:3261 -u 
 
Logging out of session [sid: 3, target: iqn.2005-10.org.freenas.ctl:tmpfs, portal: 192.168.0.253,3261]

After getting confirmation that the session has been logged out, I then restart the iscsi service for good measure.

service iscsid restart

Reconnect iscsi

Now that the iscsi service has been restarted the system is ready to reconnect to the iscsi filesystem. Execute the following command to log back in to your iscsi connections.

iscsiadm -m node --login 

Logging in to [iface: default, target: iqn.2005-10.org.freenas.ctl:tmpfs, portal: 192.168.0.253,3261] (multiple)
Login to [iface: default, target: iqn.2005-10.org.freenas.ctl:tmpfs, portal: 192.168.0.253,3261] successful.

Once the login has been successful you should be ready to mount your drive again. But I have found that sometimes when reconnecting the filesystem it gives it a new drive identifier. My system will bounce between /dev/sda and /dev/sdb. I use the following command to verify which drive identifier it has used.

Remount your iscsi filesytem

cat /proc/partitions 
 major minor  #blocks  name
 

   11        0    1048575 sr0
  252        0  524288000 vda
  252        1  505411392 vda1
  252        2   18874368 vda2
  252       16  104857600 vdb
  252       17  104857568 vdb1
    8        0 1310720000 sda
    8        1  734002176 sda1

The last 2 lines show that it connected as /dev/sda where it had been /dev/sdb before it was disconnected. I then change the settings in /etc/fstab to use the new drive identifier. After that you might be good to go, but I have also found when the drive identifier changes that issues with UUID’s can occur. As in my case when I attempted to mount the filesystem.

mount /var/lib/dumps/ 
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
        missing codepage or helper program, or other error
        In some cases useful info is found in syslog - try
        dmesg | tail  or so

That didn’t look very good, so I ran the command it recommended to check dmesg.

dmesg | tail
 [9638158.235890] sd 5:0:0:0: [sda] 2621440000 512-byte logical blocks: (1.34 TB/1.22 TiB)
 [9638158.235895] sd 5:0:0:0: [sda] 32768-byte physical blocks
 [9638158.237537] sd 5:0:0:0: [sda] Write Protect is off
 [9638158.237541] sd 5:0:0:0: [sda] Mode Sense: 7f 00 10 08
 [9638158.238100] sd 5:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 [9638158.238193] sd 5:0:0:0: alua: transition timeout set to 60 seconds
 [9638158.238204] sd 5:0:0:0: alua: port group 01 state A non-preferred supports TolUSNA
 [9638158.252324]  sda: sda1
 [9638158.256859] sd 5:0:0:0: [sda] Attached SCSI disk
 [9638245.008254] XFS (sda1): Filesystem has duplicate UUID 1615e711-25b3-4120-aa87-2514feebb1c4 - can't mount

The last line of the output indicated that the filesytem had a duplicate UUID (because it used to be /dev/sdb). XFS tools v5+ have a command to change the UUID of a filesystem. But I was running v3.1.1, so I opted for a different solution. I added an option to the fstab entry that tells the system not to check the UUID.

/dev/sda1 /var/lib/dumps/ xfs _netdev,nouuid 0 0

Now the filesystem mounts fine, even with a duplicate UUID. This may not be the perfect solution. But when you need to force disconnect iscsi and reconnect iscsi, these commands do the trick for me.

Here are some of the resources that I used when researching this topic:

Want to learn how to find a Replacement for Netstat on Linux, check out this post to find out how.