• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

PC Construction

EEPhil said:
But how many fonts do you actually need?
Click to expand...
It depends what you're doing. If you are happy with a very plain presentation when browsing the web, just a serif and a sans serif.

On the other hand, if you are into publishing and graphic design, you can never have enough. I always intended to use a font manager, but never got around to it.

MikeSh said:
But once in a blue moon you want something special and spend ages going through all the 200 ones you have to find the right one.
And there isn't one :mad:
Click to expand...
It takes a trained eye, but what I do (when I have a specific need for a special rather than fall back on my tried and tested standards - I have about 20 of those) is go through them quickly and make a shortlist, then look at the actual text in each shortlisted font. A few words might look better in one font than another, but a different few words can reverse that result. If none of them shape up I go to the on-line font libraries and see what else there is, even paying if necessary.

And then, if the requirement is critical enough (like a sign), I will use it in a graphics design package rather than a word processor and manually adjust the spacing between each letter.

You might guess: I can tell when I see a sign knocked out by somebody who only thinks they're a pro.
 
Last edited:
Black Hole said:
The only thing I can think of is that the mobo connector wasn't seated properly, and yet the front panel sockets and card reader were working (my guess is that the four USB2's are on one mobo USB2 port, and the card reader is on the other - the mobo port hosts two USB2 connections). It seems an outside chance that the dicky fstab would induce USB problems, I guess the only way to find out is to corrupt it again.
Click to expand...
I put the HDD back in, to conduct experiments on the "mirror" installation (actually, it's been left behind now - it seems a useful idea to clone the SDD updates onto it and use it to trial any proposed tweaks before committing them to the SDD).

As is, dmesg recorded a boot time of 26.45 seconds (and I reckon another 18 seconds for the PC and GRUB to get going before handing control to the Mint boot), which is about twice the 14 seconds from SDD.

I then corrupted the swap partition UUID in fstab, and the dmesg boot time went up to 107.46 seconds with an 81 second delay while it complained about the superblock (that pretty much covers the extra time). No sign of USB trouble at all.

Conclusion: for want of any other ideas, the extra boot time caused by USB trouble was entirely down to a bad connection.

If I'm going to swap around between SDD and HDD, with clone operations to duplicate the primary partition, it will be a lot more convenient to give the swap partitions matching UUIDs than keep having to correct the fstabs:
  • Test the effect of forcing everything back to MBR (and how to do it);
  • Preview updating to Mint 19 or even Mint 20
 
Try this.
Leave the HDD as it is - lets call it HDD1.
Copy the updated SSD into spare HDD2 using something like this workflow

Attach SSD and HDD2 to MB
Boot a Live Linux
Duplicate all of SSD to HDD2
dd bs=1M if=/dev/sdX of=/dev/sdY # or similar ,where X=SSD, Y=HDD2
Shutdown Live Linux and remove boot media (ie CD/DVD/USB)
Attach only HDD2 to MB
It should work - with the updated OS etc
After that you can test whatever you like on the SSD, knowing you have HDD1 and HDD2 as working backups.
As always, be careful when using dd, check the command is correct before proceeding (especially the of= ).

The above assumes you will wish to normally boot up with only one of the drives, SSD, HDD1 or HDD2, as you will have duplicate UUIDs which is not ideal!
 
Last edited:
The dd method is not ideal, it doesn't always work and may not be ideal for cloning drives of different characteristics, but it does save editing files when you only wish to use either drive (the original or cloned) on the system (because you end up with duplicate UUIDs).

Utilities that respect the UUIDs will not duplicate UUID when cloning, so that means you need to persuade the cloned drive to work/boot properly (eg correcting grub, editing /etc/fstab, etc). This means if you still have different UUID on the source and destination drives, you can boot with them both powered up with little issues.
 
prpr said:
The whole point of UUIDs is that they are unique. The clue is in the name. Who knows what undefined behaviour you are going to get by doing daft things like this.
Click to expand...
What, you think I can't keep track? Anyway, it's doing things other people think daft that finds stuff out.

One reason to go back to MBR is to get shot of all this UUID malarkey, and you were all in favour of that. I doubt GParted cares about UUIDs, but I'll soon see.
 
Black Hole said:
What, you think I can't keep track?
Click to expand...
I don't know whether you can or not. It's something you shouldn't have to keep track of though, for the most part.
One reason to go back to MBR is to get shot of all this UUID malarkey
Click to expand...
MBR (are you confused with BIOS/UEFI here?) won't rid you of UUIDs. They are used regardless. It's not just a UEFI thing or GPT thing.
I doubt GParted cares about UUIDs
Click to expand...
Probably not, but other things do, as you know already.
 
Well, I've come to the limit of my endurance trying to convert a GPT+UEFI booting Linux install into a legacy boot (which is seems to me is the only way I can get the instruction for the boot process to check the optical drive first, to stick). I even updated the mobo Flash (clutching at straws, even though the website says not to update unless you have specific problems... my firmware was dated something like 2017 and there were a string of tweaks listed since then). The only success I had was by setting the mobo to legacy* boot only, and creating a fresh install on the HDD (with no SDD attached), unless you count discovering multiple ways to destroy a Linux system as "successes".

* Legacy is what I was referring to as MBR above - no, I wasn't confused: legacy boot needs a Master Boot Record to boot from, and GPT supports that too. It just happens that the (non-GPT) partition table is also held in the MBR... but it's called a BOOT record!

For expediency, I have settled for UEFI and its authoritarian ways... I shouldn't need to overrule it very often, and when I do I will just have to hit F2 during boot.

I bit the bullet and ordered a Chinese 4K HDMI KVM switch so I can have keyboard, mouse, and monitor on my desk, and the Zen and my notebook under it. In case that takes a while to come, Remmina works fine with the Tight VNC server already running on the notebook (SSVNC, as a Linux Mint VNC client, didn't).

Now to have a play with RAID. Overclockers have blown away my order for four sets of anti-vibration HDD screws, so I will engineer something myself using standard rubber grommets or even tap washers, but I have received the cables (0.9m SATA) and power adapters (Molex to twin SATA) I need. Four HDDs, SSD, and M Disc optical drive use up all six mobo SATA ports between them; if I want any other drives they will have to be adapted to USB3 (somewhere I have another DVD writer - but I expect that has IDE, so it is ideal to put on a USB port because the mobo only has SATA).

I have gone off the idea of RAID 1+0, because striping a pair of disks might well increase their overall read/write performance, but a striped disk needs its partner and a compatible RAID controller before it is readable. I have mentioned before that (years ago, on my AMD 486 home-brew with IDE RAID built in) a mains power glitch killed both drives of the mirror, and I recovered that only by patching in a motor control chip which got one drive running just long enough to pull the data off it. One drive of a mirrored pair is readable without special measures; one drive of a striped pair isn't, nor are both drives without the RAID controller to reconstruct the data.

By going RAID 1 (mirroring), I can have 4.5TB of storage (2 2TB and 2 1.5TB drives) instead of 3TB, insured against the failure of any one drive (or two, in the right combination), and if the mobo went tits-up I could still recover the data* by ordinary processes. Mirroring could still increase the read performance, if not the write performance. It's not insured against a surge on the 12V rail killing all the disks at once, but lightning doesn't strike twice, does it? Especially not if I put a power-conditioning UPS in front of it (which I have knocking about somewhere, when I unearth it and if it still works... might need a new battery).

* Or at least, I think I could - one objective of this "play with RAID" is to see what the raw disk looks like. Instructions always say about installing Windows drivers for RAID, but I never found that necessary - the 486 mobo handled the mirroring and just presented Windows with something that looked like an ordinary disk.

Incidentally, the PSU for my 486 system had a feed-through power socket for a monitor. Modern PSUs don't seem to do this, but I have a master+slave(2) mains adapter which works very well, turning the monitor on and off when the power demand on the master socket (feeding the PC PSU) goes above or below a threshold. I was worried that the monitor would still need user intervention to power it up after mains was restored, but it starts up of its own accord so that's great. Dunno how I'm going to tie that in with the notebook on a KVM...
 
Black Hole said:
I bit the bullet and ordered a Chinese 4K HDMI KVM switch so I can have keyboard, mouse, and monitor on my desk, and the Zen and my notebook under it. In case that takes a while to come, Remmina works fine with the Tight VNC server already running on the notebook (SSVNC, as a Linux Mint VNC client, didn't).
Click to expand...
...and it arrived today and works well. My fears were unfounded (this time), arriving (apparently) from Leicester in six calendar days including a weekend. That's just about long enough for something to be flown in from China!
 
If it had come from China, it would have had a customs dec on it. Not enough time for two PO trips.
 
I've had stuff that was definitely UK stock take far longer than that recently.
Partly delivery time but I think some small outfits are only working a day or two a week as well, so dispatch can be delayed.

But on the whole I'm impressed how good it's been (so far, touching wood).
 
bottletop said:
The dd method is not ideal, it doesn't always work and may not be ideal for cloning drives of different characteristics, but it does save editing files when you only wish to use either drive (the original or cloned) on the system (because you end up with duplicate UUIDs)...
Click to expand...

I think I should add if you do use RAID1 later, you will have duplicate UUID for the partitions you mirror (it is one of the exceptions to the general rule of not having duplicate UUID on a running system).

Booting from legacy or UEFI, BIOS settings
https://neosmart.net/wiki/enable-legacy-boot-mode
https://neosmart.net/wiki/enable-uefi-boot

After setting the options you what, see if you can rearrange the order in the BIOS boot order to boot from the optical drive first before the hard drive. Otherwise maybe try efibootmgr (after BIOS changes above and booting into EFI Linux) to check or change the boot order.
eg
sudo efibootmgr -v
sudo efibootmgr -o 0000,0001,00002 # (or whichever order you wish)

This has more info https://www.lifewire.com/change-the-efi-boot-order-efibootmgr-4028027
It is not a universal solution as it depends on the BIOS adoption of the UEFI/BIOS standards
 
Black Hole said:
Dunno why it says "do not use" though!
Click to expand...
I found out why this is: this particular monitor uses the ID code "WAN", which gets fed back to the graphics card over the HDMI. Linux then translates that via a look-up table where the entry for the three-letter code "WAN" says "do not use"! I presume that is meant to mean WAN is a reserved code. I just replaced it with "electriQ" and now the monitor announces properly on the display settings.
 
Hmm. I must have got lucky with my magazine version of Linux Mint 18.2 - I have been trying newer versions and find that they don't work with my display hardware! I get the "LM" splash screen, but then the HDMI turns off.

What do you have to do to execute a shell script on the command line? It's annoying that the current working directory isn't on the command search path, and the easiest way I have found to make it run is to prefix the file name with "../". Is there a better way?
 
Black Hole said:
What do you have to do to execute a shell script on the command line? It's annoying that the current working directory isn't on the command search path, and the easiest way I have found to make it run is to prefix the file name with "../". Is there a better way?
Click to expand...
I think either you add the directory to the path (I do it it by editing /etc/profile) or by using "./" (one full stop rather than the two in your post) as prefix.
 
Noted. I think I might have got lucky with "../" - how is it supposed to know what subdirectory of the parent directory I meant?
 
Black Hole said:
how is it supposed to know what subdirectory of the parent directory I meant?
Click to expand...
It doesn't. You have to tell it. '.' is current directory and '..' is parent directory. Everything's relative to something else with this! '~' is home directory, so just put your scripts in some directory e.g. ~/scripts or whatever and add that to the path if you so desire.
 
You must log in or register to reply here.
Back
Top