Solaris basics: booting process on SPARC systems

SPARC systems rely on OpenBoot (IEEE-1275).
The environment behind is a configurable and programmable session run by the OpenBoot PROM (OPB).

The OPB utility sets up a SPARC system to accept and execute the kernel.
The boot process reduces to four phases:

  1. OpenBoot PROM
  2. Booter
  3. Ramdisk
  4. Kernel

The OpenBoot PROM starts by looking for a file system reader.
If you’re booting from a disk, you first need its layout. The boot disk stores a partition map (VTOC) at sector 0.
OBP will find and load a file reader from sector 1-15 (boot block), then it can find and read the boot archive, a collection of configuration files and drivers.

The boot utility will pass the OPB environment variables to the kernel.
By calling boot -a, you can invoke an interactive session to override the values passed as defaults.

boot -m will override the default running state or logging level:

boot -m milestone=<milestone>

Values for milestones are:

  • none (point where you can repair the services facility)
  • all
  • single-user
  • multi-user
  • multi-user-server

The second option for boot -m is:

boot -m [quiet | verbose | debug]

reboot -f will apply the Fast Reboot feature (default on x86 but not on SPARC).

rpmdb: Thread died in Berkeley DB library

While trying to update a CentOS server I got this error:

[root@washingmashine ~]# yum update
error: rpmdb: BDB0113 Thread/process 47226/140411903506496 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 -  (-30973)
error: cannot open Packages database in /var/lib/rpm
CRITICAL:yum.main:

Error: rpmdb open failed

The RPM database seemed corrupted.

First, I deleted the DB:

[root@washingmashine ~]# rm -rf /var/lib/rpm/__db*

Then I used the rpm --rebuilddb command to rebuild it.

resize2fs: bad magic number in super-block

After extending a virtual drive on VMWare, I had to add the additional disk space to the logical volume.

After adding adding the space, you need to resize the file system. On the infrastructure I was working on, I usually use resize2fs command but this time it didn’t work:

[root@washingmashine ~]# resize2fs /dev/mapper/data-archive
resize2fs 1.44.6 (5-Mar-2019)
resize2fs: Bad magic number in super-block while trying to open
/dev/mapper/data-archive
Couldn't find valid filesystem superblock.

The resize2fs program will resize ext2, ext3, or ext4 file systems; I took for granted that LVM was using a ext4 fs but I was wrong:

[root@washingmashine ~]# mount | grep data-archive
/dev/mapper/data-archive on / type xfs (rw,relatime,...

XFS fs has its own command set; in this case I had to use the xfs_growfs command:

[root@washingmashine ~]# xfs_growfs /dev/mapper/data-archive

File system resized!

SMB/CIFS connection timeout kernel-3.10.0-957.21.3.el7

After upgrading to kernel-3.10.0-957.21.3.el7 on a CentOS server, I experienced connection timeout issues on Windows servers trying to access SMB shares. On the contrary, I was able to access the share using a Linux system without any problem.

The bug was reported in CentOS Bug Tracker and it’s caused by one of the patches applied to address CVE-2019-11478.

Some applications set tiny SO_SNDBUF values and expect TCP to just work.
Recent patches to address CVE-2019-11478 broke them in case of losses, since re-transmits might be prevented.

To (temporarily) fix this issue, I increased SO_SNDBUF value in /etc/samba/smb.conf:

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=65536 SO_SNDBUF=65536