Roy's notes - Revision history

Roy at 18:53, 17 November 2020

2020-11-17T18:53:15Z

← Older revision		Revision as of 18:53, 17 November 2020
Line 1:		Line 1:
			= Page move =

			After borrowing space on Malin's wiki for some years, further edits will be done on the [https://wiki.karlsbakk.net/index.php/Roy%27s_notes my new wiki] so that next time the wiki goes down after something strange happened, she won't get a ton of mesages from me, but I'll have to fix it myself - oh well ;)

	= LVM, md and friends =		= LVM, md and friends =

Roy: /* Using an arduino Nano as a programmer */

2020-11-14T23:14:37Z

Using an arduino Nano as a programmer

← Older revision		Revision as of 23:14, 14 November 2020
Line 726:		Line 726:

	So, grab an arduino, plug it to your machine with a USB cable, and, using the Arduino IDE, use the ArduinoISP sketch there (found under Examples) to burn the software needed for the arduino to work as a programmer. When this is done, connect a 10µF capacitor between RST and GND to stop it from resetting when used as a programmer. Connect the MOSI, MISO and SCK pins from the ICSP block (that little isolated 6-pin block on top of the ardu). See [https://www.arduino.cc/en/Tutorial/ArduinoISP here] for a pinout. Then find Vcc and GND either on the ICSP block or elsewhere. Some sites say that on some boards you shouldn't use the pins on the ICSP block for this. I doubt it matters, though. Then connect another jumper wire from pin 10 on the ardu to work as the reset pin outwards to the chip being programmed (that is, on the printer). The ICSP jumper block pin layout is the same on the printer and on the ardu, and probably elsewhere. Sometimes [https://xkcd.com/927/ standardisation] actually works…		So, grab an arduino, plug it to your machine with a USB cable, and, using the Arduino IDE, use the ArduinoISP sketch there (found under Examples) to burn the software needed for the arduino to work as a programmer. When this is done, connect a 10µF capacitor between RST and GND to stop it from resetting when used as a programmer. Connect the MOSI, MISO and SCK pins from the ICSP block (that little isolated 6-pin block on top of the ardu). See [https://www.arduino.cc/en/Tutorial/ArduinoISP here] for a pinout. Then find Vcc and GND either on the ICSP block or elsewhere. Some sites say that on some boards you shouldn't use the pins on the ICSP block for this. I doubt it matters, though. Then connect another jumper wire from pin 10 on the ardu to work as the reset pin outwards to the chip being programmed (that is, on the printer). The ICSP jumper block pin layout is the same on the printer and on the ardu, and probably elsewhere. Sometimes [https://xkcd.com/927/ standardisation] actually works…

			When it's all wired up, change the setup in the Arduino IDE to use the Sanguino board (which may need to be installed there), the Atmega 1284 16MHz board with the programmer set to "Arduino as ISP". Also make sure to choose the right serial port. When all is done, choose Tools \| Burn programmer and it should take a few seconds to finish.

	[[File:Ardu-nano-as-programmer.jpg\|400px]]		[[File:Ardu-nano-as-programmer.jpg\|400px]]

Roy: /* Using an arduino Nano as a programmer */

2020-11-14T23:08:08Z

Using an arduino Nano as a programmer

← Older revision		Revision as of 23:08, 14 November 2020
Line 727:		Line 727:
	So, grab an arduino, plug it to your machine with a USB cable, and, using the Arduino IDE, use the ArduinoISP sketch there (found under Examples) to burn the software needed for the arduino to work as a programmer. When this is done, connect a 10µF capacitor between RST and GND to stop it from resetting when used as a programmer. Connect the MOSI, MISO and SCK pins from the ICSP block (that little isolated 6-pin block on top of the ardu). See [https://www.arduino.cc/en/Tutorial/ArduinoISP here] for a pinout. Then find Vcc and GND either on the ICSP block or elsewhere. Some sites say that on some boards you shouldn't use the pins on the ICSP block for this. I doubt it matters, though. Then connect another jumper wire from pin 10 on the ardu to work as the reset pin outwards to the chip being programmed (that is, on the printer). The ICSP jumper block pin layout is the same on the printer and on the ardu, and probably elsewhere. Sometimes [https://xkcd.com/927/ standardisation] actually works…		So, grab an arduino, plug it to your machine with a USB cable, and, using the Arduino IDE, use the ArduinoISP sketch there (found under Examples) to burn the software needed for the arduino to work as a programmer. When this is done, connect a 10µF capacitor between RST and GND to stop it from resetting when used as a programmer. Connect the MOSI, MISO and SCK pins from the ICSP block (that little isolated 6-pin block on top of the ardu). See [https://www.arduino.cc/en/Tutorial/ArduinoISP here] for a pinout. Then find Vcc and GND either on the ICSP block or elsewhere. Some sites say that on some boards you shouldn't use the pins on the ICSP block for this. I doubt it matters, though. Then connect another jumper wire from pin 10 on the ardu to work as the reset pin outwards to the chip being programmed (that is, on the printer). The ICSP jumper block pin layout is the same on the printer and on the ardu, and probably elsewhere. Sometimes [https://xkcd.com/927/ standardisation] actually works…

	[[File:Ardu-nano-as-programmer.jpg\|~~500px~~]]		[[File:Ardu-nano-as-programmer.jpg\|400px]]

	== Flashing the printer ==		== Flashing the printer ==

Roy: /* Using an arduino Nano as a programmer */

2020-11-14T22:45:29Z

Using an arduino Nano as a programmer

← Older revision		Revision as of 22:45, 14 November 2020
Line 727:		Line 727:
	So, grab an arduino, plug it to your machine with a USB cable, and, using the Arduino IDE, use the ArduinoISP sketch there (found under Examples) to burn the software needed for the arduino to work as a programmer. When this is done, connect a 10µF capacitor between RST and GND to stop it from resetting when used as a programmer. Connect the MOSI, MISO and SCK pins from the ICSP block (that little isolated 6-pin block on top of the ardu). See [https://www.arduino.cc/en/Tutorial/ArduinoISP here] for a pinout. Then find Vcc and GND either on the ICSP block or elsewhere. Some sites say that on some boards you shouldn't use the pins on the ICSP block for this. I doubt it matters, though. Then connect another jumper wire from pin 10 on the ardu to work as the reset pin outwards to the chip being programmed (that is, on the printer). The ICSP jumper block pin layout is the same on the printer and on the ardu, and probably elsewhere. Sometimes [https://xkcd.com/927/ standardisation] actually works…		So, grab an arduino, plug it to your machine with a USB cable, and, using the Arduino IDE, use the ArduinoISP sketch there (found under Examples) to burn the software needed for the arduino to work as a programmer. When this is done, connect a 10µF capacitor between RST and GND to stop it from resetting when used as a programmer. Connect the MOSI, MISO and SCK pins from the ICSP block (that little isolated 6-pin block on top of the ardu). See [https://www.arduino.cc/en/Tutorial/ArduinoISP here] for a pinout. Then find Vcc and GND either on the ICSP block or elsewhere. Some sites say that on some boards you shouldn't use the pins on the ICSP block for this. I doubt it matters, though. Then connect another jumper wire from pin 10 on the ardu to work as the reset pin outwards to the chip being programmed (that is, on the printer). The ICSP jumper block pin layout is the same on the printer and on the ardu, and probably elsewhere. Sometimes [https://xkcd.com/927/ standardisation] actually works…

	~~See https~~:~~//cloud~~.~~karlsbakk.net/index.php/s/zw48YJjzaf8Rc2F for a pic with the ardu (this wiki is broken atm, will fix it later)~~		[[File:Ardu-nano-as-programmer.jpg\|500px]]

	== Flashing the printer ==		== Flashing the printer ==

Roy: /* Recovery */

2020-11-12T13:00:09Z

Recovery

← Older revision		Revision as of 13:00, 12 November 2020
Line 418:		Line 418:

	This worked, and the filesystem on /dev/<vg>/<lv> could be mounted correctly.		This worked, and the filesystem on /dev/<vg>/<lv> could be mounted correctly.

			=== Renaming a RAID ===

			''Not finished''
			<!--

			Back around 2001, I asked on the linux-raid list for disk tagging, not default back then, but supported, and thought of the possibility of disk #1 getting replaced with disk #1 from another raid because of a messup. After this, the hostname was added to the raid name in the superblock. So when a RAID is created, it is named "hostname:raidname", where the raidname is either a number (0,1...) or a name.

			For instance, running this on my VM named "raidtest":

			mdadm --create --level=1 --raid-devices=2 /dev/md/stuff /dev/sd[st]

			mdadm --detail --scan now shows this

			ARRAY /dev/md/stuff metadata=1.2 name=raidtest:stuff UUID=c4cdf69f:393a28b1:47648ed3:726613de

			Now, you might want to change this name for some reason, and it's not supported under "grow", so what to do… The name is, after all, local to the disk, since it's there to avoid messing up a raid (or two) after a disk mixup.

			mdadm --assemble /dev/md/stuff --name 'someotherhost:stuff' --update=homehost /dev/sd[st]
			-->

	=== The badblock list ===		=== The badblock list ===

Roy: /* Which pi? */

2020-11-05T17:12:41Z

Which pi?

← Older revision		Revision as of 17:12, 5 November 2020
Line 615:		Line 615:
	While this works well, for the latter, the pi4, it doesn't tell how much memory I have. It comes in variants of 1, 2 and 4GB, and this is the latter.		While this works well, for the latter, the pi4, it doesn't tell how much memory I have. It comes in variants of 1, 2 and 4GB, and this is the latter.

	For a more detailed list, the command '''awk '/^Revision/ {sub("^1000", "", $3); print $3}' /proc/cpuinfo''' will give you a revision number, detailing the type of pi, who produced it etc. Please see [https://elinux.org/RPi_HardwareHistory] for a full table.		For a more detailed list, the command '''awk '/^Revision/ {sub("^1000", "", $3); print $3}' /proc/cpuinfo''' will give you a revision number, detailing the type of pi, who produced it etc. Please see [https://elinux.org/RPi_HardwareHistory https://elinux.org/RPi_HardwareHistory] for a full table.

	== Monitoring ==		== Monitoring ==

Roy: /* Which pi? */

2020-11-05T17:12:01Z

Which pi?

← Older revision		Revision as of 17:12, 5 November 2020
Line 614:		Line 614:

	While this works well, for the latter, the pi4, it doesn't tell how much memory I have. It comes in variants of 1, 2 and 4GB, and this is the latter.		While this works well, for the latter, the pi4, it doesn't tell how much memory I have. It comes in variants of 1, 2 and 4GB, and this is the latter.

			For a more detailed list, the command '''awk '/^Revision/ {sub("^1000", "", $3); print $3}' /proc/cpuinfo''' will give you a revision number, detailing the type of pi, who produced it etc. Please see [https://elinux.org/RPi_HardwareHistory] for a full table.

	== Monitoring ==		== Monitoring ==

Roy: /* The badblock list */

2020-09-18T19:40:11Z

The badblock list

← Older revision		Revision as of 19:40, 18 September 2020
Line 432:		Line 432:

	</syntaxhighlight>		</syntaxhighlight>

			If there's a BBL on the drive already, replace the --update part to 'force-no-bbl'. This is not documented anywhere as per se, but it works.

	I haven't found a way to turn this off permanently, but there may be something coming around when the debate on the linux-raid mailing list closes up on this. There's a bbl=no in mdadm.conf, but that's only for creation. I will continue extensive testing for this.		I haven't found a way to turn this off permanently, but there may be something coming around when the debate on the linux-raid mailing list closes up on this. There's a bbl=no in mdadm.conf, but that's only for creation. I will continue extensive testing for this.

Roy: /* mdadm stuff */

2020-09-18T19:22:02Z

mdadm stuff

← Older revision		Revision as of 19:22, 18 September 2020
Line 418:		Line 418:

	This worked, and the filesystem on /dev/<vg>/<lv> could be mounted correctly.		This worked, and the filesystem on /dev/<vg>/<lv> could be mounted correctly.

			=== The badblock list ===
			'''md''' has an internal badblock list (BBL), added around 2010, to list the bad blocks on the disk to avoid using those. While this might sound like a good idea, the badblock list is updated in case of a read error, which can be caused by several things. To make things worse, the BBL is replicated to other drives when a drive fails or the array is grown. So if you start out with sda and sdb and sdb suffers some errors, nothing wrong, md will read from sda, but flag those sectors on sdb as bad. So after a while, perhaps sda dies and gets replaced, with the same content, including the BBL. Then, at some point you might to replace sdb and it, too gets the BBL. So it sticks - forever. Also, there's no real point of keeping a BBL list, since the drive has its own and even if a sector error occurs, the array will have sufficient redundancy to recover from that (unless you use RAID-0 which you shouldn't). If a drive finds a bad sector, it'll be reallocated by the drive itself without the user's/admin's/system's knowledge. If a sector can't be reallocated, it means the drive is bad and should be replaced.

			There's no official way to remove it and although you can assemble it with the no-bbl option, this will only work if there's an empty BBL. Also, this will require downtime. As far as I can see, the only way to do this currently, is with a wee hack that should work. Just replace the names of mddev/diskdev with your own.

			<syntaxhighlight lang="bash">
			#!/bin/bash

			mddev="/dev/md0"
			diskdev="/dev/sda"
			mdadm $mddev --fail $diskdev --remove $diskdev --re-add $diskdev --update=no-bbl

			</syntaxhighlight>

			I haven't found a way to turn this off permanently, but there may be something coming around when the debate on the linux-raid mailing list closes up on this. There's a bbl=no in mdadm.conf, but that's only for creation. I will continue extensive testing for this.

	== Tuning ==		== Tuning ==

Roy: /* Disabling LVM cache */

2020-09-02T09:18:35Z

Disabling LVM cache

← Older revision		Revision as of 09:18, 2 September 2020
Line 74:		Line 74:
	==== Disabling LVM cache ====		==== Disabling LVM cache ====

	If you ~~for some reason~~ want to disable caching, ~~this~~ will do it cleanly and remove the LVs earlier created for caching the main device.		If you want to change the cached LV, such as growing og shrinking or otherwise, you'll have to disable caching first and then re-enable it. There's no quick-and-easy fix, but you just do as you did when enabling in the first place.

			Forst, disable caching for the LV. This will do it cleanly and remove the LVs earlier created for caching the main device.

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	lvconvert --uncache data/data		lvconvert --uncache data/data
	</syntaxhighlight>		</syntaxhighlight>

			Then, since you now have a VG with an empty PV in it, earlier used for caching, I'd recommend removing this for now to avoid expanding onto that as well. Since they're in the same VG, this might happen and if you get so far as to extend the lv and the filesystem on it, and this filesystem is XFS or similar filesystems without possibilities of reducing the size, you have a wee problem.

			Just remove that PV from the VG

			<syntaxhighlight lang="bash">
			vgreduce data /dev/md1
			</syntaxhighlight>

			The PV is still there, but pvs should now show it not connected to a VG

	==== Growing devices ====		==== Growing devices ====