I start X Windows with startx. Here is my .xinitrc and two programs I use: x.c and xh.c
2021-04-08 "What are you hiding, library? - L'historie de l'seconde."
2021-03-11 How I made a bootable disk from slackware - guidelines: "dd if=/dev/zero of=/root/img count=32768" will create a 16MiB zero filled file. "fdisk /root/img" to create partition, starting at 2048 512 byte blocks, then "losetup -P /dev/loop0 /root/img", then create filesystem "mke2fs /dev/loop0p1", then mount the partition somewhere, in my case "mkdir /mnt/a; mount /dev/loop0p1 /mnt/a", then copy the utilities there into bin/: bash cp dd ed login ls md5sum mkdir mknod mount mv rm rmdir sh stat stty sync umount, copy the libraries to /mnt/a/lib/ - checked which are necessary with "ldd /bin/cp" and the like, created /etc/inittab which just runs bash; created mostly empty /etc/passwd and /etc/shadow; "init=/bin/bash" is also an option. Made the image bootable with lilo patched as described below, "umount /mnt/a;losetup -d /dev/loop0", written. Later I made a initrd image out of the boot directory, "find | cpio -o".
2021-03-08 I have transferred a file through serial interface, using nullmodem cable and COM2 port. The first succesful transmission was with the help of minicom, which I used to setup the port to use. Then I found I can use "stty raw 115200 < /dev/ttyS1" to set the port up. This led to partial success. I have eventually checked all the settings with "stty -a < /dev/ttyS1" and turned off the following settings: "stty -hupcl -onlcr -iexten -echo -echoe -echok -echoctl -echoke < /dev/ttyS1" For the transfer of single file, I first checked the size of the file to transfer "ls -l file", set the ports on both sides in the above way, then ran the following command on the receiving side: "dd if=/dev/ttyS1 of=file ibs=1 obs=[filesize] count=[filesize]" and then start the transmission on the broadcast side: "dd if=file of=/dev/ttyUSB0 ibs=[filesize] obs=1" In my experience, the serial ports requires byte-by-byte reading from and writing to, and the access to disk tend to disrupt the transmission, which is why the caching to memory with ibs and obs on the broadcasting and receiving sides, respectively, is a good practice. I have also used gzip to compress and check the correct transmission at the same time. First gzipped the file to transmit "gzip file", then "dd if=/dev/ttyS1 ibs=1 obs=[filesize] count=[filesize] | gzip -d | dd of=outfile" and "dd if=file.gz of=/dev/ttyUSB0 ibs=[filesize] obs=1" on the broadcasting side. Before transferring large file, I have checked the transmission with smaller file, redirected to /dev/null
2021-02-21 20:37 moments ago, I've successfully transferred Slackware 3.0 running on an i486SX/25MHz-8MB from one PATA IDE disk to another, without using a floppy disk, with a one-line change in lilo 0.16 source code, recompiling lilo and using a specially crafted config file for lilo. The change is in geometry.c file, geo_comp_addr function, line 427, which originally copies the device number to addr structure from geo structure. When transferring the system from already booted device, the target disk is second, hence the device written by vanilla lilo to the boot sector and to the map file is the second ATA disk, 0x81, which after eventually reattaching the disk as first does not work. The solution is to simply assign 0x80, a number corresponding to first ATA disk, to device member of addr structure on the above mentioned line. I have mounted /dev/hdb1 to /mnt. The /mnt/etc/lilo.over file was as follows:
boot = /dev/hdb vga = normal ramdisk = 0 map = /mnt/boot/map install = /mnt/boot/boot.b image = /mnt/vmlinuz label = Linux root = /dev/hda1
The command to run, after patching and recompiling lilo in /mnt/root/liloover/ (over for "override") was "/mnt/root/liloover/lilo -C /mnt/etc/lilo.over" I have first verified the expected result with "/root/liloover/lilo -t -v -v -v -v -C /mnt/etc/lilo.over".
2021-02-25 update: lilo uses linux system calls to write to disk; the device number in the geo structure refers to bios calls used during bootup; I was in need to prepare a disk to boot on another motherboard, which necessitated linear adressing, so I have added "linear" on a separate line in /mnt/etc/lilo.over. The change in source code I now use is in geometry.c on line 229, where I simply assign 0x80 to the device number in geo structure, which is later used either on line 419 or 427, covering both linear and CHS addressing cases. In my case, the value is bitwise ORed with LINEAR_FLAG, which is 0x40, so the final device number used for bios calls, as seen in the verbose output is 0xc0.
Links: Slackware free software collection GNU Free software foundation TeX users group freeBSD arXiv
dd, lynx