Feb 082018
 

Some time ago, I wrote about using new (for the time) partition tables to create a memory stick with 100 partitions; each with a mountable file system on. And decided the time was right to have another look to see if things have improved … or degraded. After all, things have moved on, and everything has been updated.

I also improved the creation script slightly :-

#!/bin/zsh

disk=/dev/sdb

parted $disk mklabel gpt
for x in {1..99}     
do
  echo Partition: $x
  parted -s $disk mkpart FAT $(($x * 100)) $((x * 100 + 99))
  sleep 0.2
  mkfs -t vfat -n DOOM${x} ${disk}${x} 
  sleep 0.2
done

And I used a zsh-ism – so shoot me.

The script ran fairly well, but :-

  1. The load average shot up through the roof as copies of systemd-udevd started, worked, and closed.
  2. Strangely the links in /dev/disk/by-label (and presumably elsewhere) kept disappearing and re-appearing. As if on each partition change to the disk, all of the disk’s devices were removed and re-created. This is probably not dangerous, but harmful to performance.
  3. Given that I used sleep within my script, it is hard to criticise performance, but it did seem slow. However this is not an area worth optimising for.
  4. Unlike last time, Linux did not refuse to create any file systems.

Now onto trying to stick the memory stick of doom into various systems…

Ubuntu 17.10

This was of course the machine I ran the script on initially.

This did not go so well, with the machine initially freezing momentarily (although it is a cheap and nasty laptop), apparently silently refusing to mount half the file systems, and “Files” (or Nautilus) getting wedged at 100% processor usage.

After some 10 minutes, Nautilus was still stuck with no signs of making any progress.

After I lost patience and restarted “Files”, it came up okay showing the mounted file systems and showing the file systems it had failed to mount. On one occasion the additional file systems were shown as unmounted (and could be mounted) and on another they were shown as mounted (even though they weren’t).

So both “Files” gets a thumb down for getting stuck, and whatever else gets a thumb down for trying and failing (silently) to mount all the file systems.

This is definitely a serious degradation from the previous try, although probably GNOME-specific rather than Linux-specific. Especially as a later mounted all the file systems from the command-line on a different system without an issue.

Windows 10

Windows 10 became unusually sluggish, although it may have been in the mysterious “we’ll run Windows update at the most inconvenient time possible” mode. It did attempt to mount the file systems, and failed miserably – it mounted the first set until it ran out of drive letters.

Which is just about understandable, as there aren’t 100 drive letters. However :-

  1. Where was the message saying “There are 100 partitions in this silly USB stick. You can see the first 22; additional ones can be mounted within folders if there is important data on them.”.
  2. Why is Windows still limiting itself with single letter device names? Okay it is what we’re used to, but when you run out of drive letters, start using the file system label – “DOOM99:”. Hell, I’d like all my removable disks treated that way under Windows.

As for the whole “ran out of drive letters, so don’t bother with the rest”, how many people are aware that drives can be mounted (as Unix does) in directories?

macOS 10.13 (OSX)

Oddly enough (but perhaps sensibly), macOS refused to have anything to do with the memory stick. Indeed it popped up a dialog suggesting initialising the disk, which is perhaps not particularly sensible with a disk that could contain data.

The “Disk Utility” happily showed the disk – increasing the size of the window inconveniently wide in the process – and happily indicated 99 partitions.

At the Terminal prompt, it was apparent that the operating system had created device files for each of the partitions, but for some reason wouldn’t mount them.

Summary

Inserting a “stick of doom” with 100 partitions on it into any machine is still a risky thing to do. It’s also a dumb thing to do, but something operating system developers should be doing.

Linux (or rather GNOME) performs significant worse this time around than previously, and my suspicions are that systemd is to blame.

But however bad Linux does, none of the operating systems actually do sensible things with the “stick of doom”. macOS arguably comes closest with refusing to have anything to do with the disk, but it also encourages you to reformat the disk without saying that it could be erasing data.

Ideally, a gooey would pop up a window listing the file system labels and ask you which you want to mount. That’s not even a bad idea for a more sensibly set up memory stick.

Pebble On Steel

Aug 272017
 

Every so often, somebody (or organisation) proclaims that this year is the year of Linux on the desktop. Given the number of times this has occurred, you would have thought that the Cassandras of the Linux world would stop trying to predict it. In fact I am not entirely sure what it is supposed to be – everyone using Linux on the desktop, or just some? And if it is just some people, how many?

It is essentially nonsense – if you use Linux on the desktop, every year is the year of Linux on the desktop; and if you do not, it isn’t.

Assuming you are someone who has more than two brain cells to rub together and are prepared to do some learning, it is perfectly possible to run Linux on the desktop. You can do pretty much everything with Linux that you can do with Windows. In fact the one area that Linux is traditionally weak – upgrading firmware of third party devices (such as media players, wireless mice – is beginning to change with LVMS and fwupd.

To give an example, I was recently upgrading some Logitech wireless mice to eliminate a serious security flaw, and I tried with Windows, OSX, and finally Linux. Both the Windows and OSX methods failed, whereas the Linux method just worked.

In fact even if the Windows method had worked, it would have been a lot more complex. I had to download the Logitech software (admittedly this step would probably be unnecessary if I was used to using the wireless mouse under Windows), know that a firmware upgrade was necessary, download the firmware upgrade, and finally load it into the upgrade tool.

Under Linux? Assuming I had been using some gooey tool like GNOME Software, it would have notified me that an upgrade was available and after a request would have upgraded it for me. I (of course) chose to do it the geeky way from the command-line, but even so running :-

# fwupmgr refresh
# fwupmgr update

… is a great deal simpler than the Windows way. And that is before you consider that with Windows, you need to download a firmware update tool for every device whereas the Linux way it is just one tool.

Of course in practice, the Linux method only works for a handful of devices – of the innumerable Linux machines I run only one has available updates for the desktop computer’s firmware (the Dell at work), and of the peripheral (or not so peripheral) devices only a tiny handful can be upgraded today.

But it is not inconceivable that in the not too distant future, the sensible way to upgrade the firmware of various devices will be to install Linux, and let it do it for you. Particularly if device manufacturers realise that by adopting Linux as the firmware upgrade delivery method, they can save time and effort.

“But I know Windows” – actually you know Windows 7, or Windows XP, or Windows 10; each of which is very different from each other. And whilst Linux has even more variability at first glance, there is actually more commonality between different versions of Linux. Or in other words, the effort of learning Linux in the first place is rewarded by less of a need to completely re-educate yourself every time you upgrade.

This is not intended as encouragement for you to switch to Linux (although if you are involved in IT you should at least be familiar with Linux), but intended as a criticism of the concept of a year of the Linux desktop. It isn’t useful, and what is worse it leads to the false impression of failure – if everyone is not using Linux on the desktop, then Linux has failed.

Linux on the desktop has not failed because I use it on the desktop.

Mar 182017
 

The TiPro programmable keyboards are quite fun for those who are into their keyboards, but with one big problem: the programming tool is Windows only. Well at least if you happen to have a USB-based TiPro; otherwise you need to set up the serial interface as the PS/2 interface is only usable for programming with a 32-bit Windows.

As it turns out, if you try to run it under a virtual machine and assign the USB device of the keyboard to the virtual machine, it still fails – somehow it doesn’t like staying assigned to the virtual machine. However there is a fix for this – using the command-line VirtualBox tools to set up a permanent USB filter.

To assign, first of all determine the name of your virtual machine with :-

VboxManage list vms

Next, add a USB filter – you can normally assign it to “slot” (or index) 1, but you may have to check what slots are available if you already do this :-

VBoxManage usbfilter add 1 --target "W10" --name TiPro --vendorid 0x1222 --productid 0xfaca

Once that is done, the Windows tool should be able to find the keyboard to start programming it. If necessary, reboot the virtual machine or try assigning the USB device via the menu option.

During programming it is helpful to remember than raw USB HID codes can be used by right-clicking in the input field for a key, selecting “Text Input” and inputing the code in the form “/${hex hid code} ${hex hid code}\” – such as “/69 69\” (a list can be found at: http://www.usb.org/developers/hidpage/Hut1_12v2.pdf)

Removal at the end:

VBoxManage usbfilter remove 1 --target "W10"

After the removal it seems that disconnecting and reconnecting the device is necessary for Linux to pick it up (or possibly a udevadm trigger).

b

Sep 012016
 

One of the advantages that ZFS brings, is that it is so easy to create file systems, that you can create them for purposes that you would not previously do. For example, I have an additional file system mounted under my home directory for a certain application that generates a lot of data that I do not need backed up. Because the script I use to back up stuff does not cross file system boundaries (i.e. it does not descend into a directory that contains a mounted file system), I can simply exclude a large amount of frequently changing data by making a file system.

Or I might (as it happens I do not, but I could well do) create file systems for large lumps of data to easily see how much space they occupy – perhaps ~/Pictures. You can run a command like du -sh ~/Pictures, but that is an expensive command (it takes a while) and it tells you how large the files are; not how much space they occupy on disk. And on-disk compression can make that a significant difference! So simply run df -h ~/Pictures if that directory is on a separate file system.

But there is a bit of a gotcha with that. If you create such file systems in the normal way (such as zfs create pool/mikes-pictures; zfs set mountpoint=/home/mike/Pictures pool/mikes-pictures) you risk creating a situation that may prevent your home directory from mounting. If the “child” file system is mounted before the parent, it will not be possible for the parent file system to be mounted when booting.

Instead create the hierarchy properly :-

zfs create pool/h2
mkdir /h2
zfs set mountpoint=/h2 pool/h2
zfs create pool/h2/mike
zfs create pool/h2/mike/Pictures
ls /h2/mike/Pictures

You will also have to fix the permissions, but this is a far safer way of organising things suitable for future file system creation.

damascus-unix-prompt

Aug 292016
 

It seems that occasionally GNOME can go a little screwy and its fancy mouse pointer plugin can result in an invisible mouse pointer. Which makes doing anything just a little bit tricky.

If you can open a terminal, enter the command :-

gsettings set org.gnome.settings-daemon.plugins.cursor active false

And all should be well. At least until it decides to turn itself back on again (so make a note of this fix!).

damascus-unix-prompt

WP Facebook Auto Publish Powered By : XYZScripts.com

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close