Python reading file error - 'utf-8' codec can't decode byte

When reading in a file and getting errors such as example:

'utf-8' codec can't decode byte 0xa3 in position 2897: invalid start byte 

Add errors='ignore' as per the following example: 

 with open(fname,"r", errors='ignore') as fo:

How to enable SMB1 on Windows 10

Run optionalfeatures (WinKey +R then type optionalfeatures)

Install docker on Slackware

https://slackware.pkgs.org/

quick notes

google-go-lang-1.10.2-x86_64-1_slonly.txz
tini-0.13.0_949e6fa-x86_64-1_slonly.txz
docker-proxy-20180412_c15b372-x86_64-1_slonly.txz

libseccomp-2.3.3-x86_64-1_slonly.txz
runc-1.0.0_rc5-x86_64-1_slonly.txz
containerd-1.0.3-x86_64-1_slonly.txz
docker-18.03.1-x86_64-1_slonly.txz

Revised Sep 2024

See note below.

Revisited Aug 2024

The below is related to Slackware 15 and used the sbopkg method, see here for more information about getting sbopkg up and running.

So, I set about building Docker using the following order:

which is required to satisfy dependencies.

Once google-go-lang was installed, the build or runc failed and I found my way to the solution [here]. Essentially, you should build and install google-go-lang and then log out and back in before continuing with runc.

Once the above was done, or running the shell script at /etc/profile.d/go.sh then was good to continue (note, I done this using my current user, with and without sudo and also as root. I eventually had to open a new terminal to get it to work without error).

Once complete, do;

sudo groupadd -r docker

sudo usermod -a -G docker <username>

Note: 

then you need to install docker-cli which I chose to do using sbopkg thanks to Audrius Kažukauskas for this [https://slackbuilds.org/repository/15.0/system/docker/]

In hindslight, this should be added to the above packages order, after docker itself.

References

https://slackbuilds.org/repository/15.0/system/docker/

 

Change form GPT to MBR partition types

To change from GPT to MBR partitioning type under linux;

disk /dev/sda (assuming the drive is sda)

Then use the x option (extra functionality)

then use option z to destroy GPT

Now you can use cfdisk /dev/sda as per normal and choose DOS

Tested on Slackware 14.2

change eth1 to eth0

After cloning a system or replacing network card or for some other reasons, I have seen eth0 missing and ifconfig only showing eth1

removing the following file and rebooting resolved;

/etc/udev/rules.d/70*

Also this file can be edited and udevadm trigger refreshes.

This may also apply to /dev/hda /dev/hdb /dev/sda /dev/sdb etc (to be verified)

mount CD on RHEL 7 Linux

run blkid to find out the correct device, example /dev/sr0

Create a mount point if it doesn't already exist.

mount /dev/sr0 /mnt/cdrom

mount /dev/cdrom /mnt/cdrom (might work)

RHEL Network configuration

The primary network configuration files are as follows:

/etc/hosts

Resolve host names that cannot be resolved any other way, by DNA for example. 

/etc/resolv.conf

This file specifies the IP addresses of DNS servers and the search domain.

/etc/sysconfig/network

This file specifies routing and host information for all network interfaces.

/etc/sysconfig/network-scripts/ifcfg-interface-name

For each network interface, there is a corresponding interface configuration script. Each of these files provide information specific to a particular network interface.

Change Linux run level

On systemd (including RedHat) do the following;

Text Only

ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Graphical Envirment

ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

UNIX System V (including Solaris and Slackware), do the following;

Edit /etc/inittab

Look for the section Default Runlevel

and edit the line that follows (normally 3 for multiuser mode, 4 is X11 and 1 is single user mode)

Configure apache to run python scripts

Edit httpd.conf file to include the following;

Uncomment LoadModule
<IfModule !mpm_prefork_module>
        LoadModule cgid_module lib64/httpd/modules/mod_cgid.so
</IfModule>
<IfModule mpm_prefork_module>
        LoadModule cgi_module lib64/httpd/modules/mod_cgi.so
</IfModule>

Add ExecCGI
    Options Indexes FollowSymLinks ExecCGI

Add .py
    AddHandler cgi-script .cgi .py

When lilo fails to boot or there's a problem with MBR

Boot with Slackware install DVD, tested with 13.37 (only one I had to hand).


At boot prompt, follow instructions to boot existing system, something like;

huge.s root = /dev/sda1

Once system boots, we need to do the following:
Set keyboard map and login as root (no password).
cfdisk shows partitions (note root partition)

mount /dev/sda1 /mnt # where sda1 is the root partition. (discovered from cfdisk)

No need to mount any other partitions unless you need to make other changes.

The following was not needed but is documented as part of the process:

mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys

chroot /mnt /bin/bash


Once in here you can edit /etc/lilo.conf
Note, in the case of SCS, location of boot bitmap needed to be changed to /boot/...

I choose to have at least 2 working kernels listed in there one at /dev/hda1 and one at /dev/sda2
this was due to the system showing current disk as sda and I knew original system showed as hda
I leave boot= flag untouched.

install lilo using lilo -b /dev/sda
and reboot, removing Slackware installation DVD


One of the kernel images should boot and then change lilo.conf back to normal and install lilo using lilo

UPDATE: 09 JULY 2021

On a 14.2 install with a failed lilo installation, I was able to follow the above but it would seem I was able to boot my system using;

huge.s root = /dev/sda1 rdinit=ro

and did not need to mount the root partition in order to make the changes, I was able to make a change to /etc/fstab.conf although in this case I didnt need to and was able to simply install lilo using lilo -b /dev/cciss/c0d0p

Additional notes, we can run fdisk -l and use that information to look in the /dev/* directory for where we should be installing lilo, in this case we have a raid setup so the usual /dev/sda wasn't going to cut it.