Typing 詩歌 with mozc-ibus

For context, and to serve as fluff to intentionally bury the lead, I use mozc-ibus to make Japanese squiggly bits appear on Ubuntu. For the last few moons I have also enlisted myself as a slave to a thing that exists called The Crabigator as a way to drill into my numbskull the meaning of most Japanese squiggly bits.

Now, recently I’m at a point where I have to type the word 詩歌 rather frequently. Thing is, this numbskull was not reading properly, so I thought the only way to make that certain squiggly bit appear is to type しか. Because why not? [If you’re in the know, now is the time to start cringing.] But when I do, mozc-ibus is not giving me the right squiggly bit for the word. It just doesn’t.

So I do the stubborn thing and try to bend mozc-ibus to my will and add しか as a way to type 詩歌. I make the Mozc Settings thing appear, click on the Edit user dictionary, and start adding an entry. Thing is, when doing so I’m being asked to indicate which part of speech the thing I’m adding is so the recommendation magic would know how to sort the new thing properly when doing its thing; but the category list is in Japanese, and said list invoked all sorts of null-pointers causing me to segfault. (Also, how do I capture a screenshot of a GTK dropdown again? With a phone? What heresy! NO.)

So I go scavenging the mozc source code on github to arrive at this file (with text that I could feed to a translator). It must be the source of the part of speech thing I’m being asked to put in the category. I arrive at this file for an embarrassingly long amount of time (at least relative to the realization that follows).

As I was about to add the new entry in the user dictionary that instructs mozc-ibus to do things my way, it dawned on me. How about I try to type しいか? Of course.

Oh well. Now this numbskull doesn’t have to type しじん + Backspace + かしゅ + Backspace every damn time, nor needs bother with untranslated part of speech categories in Mozc settings.

Make big disks short in space grow

Title is stupid.

What I mean is that when you create an ext2/3/4 partition, by default 5% of the disk is allocated as reserved system space.

So things like this happen:

df -h shows 443G total, 420G used, but only 941M available space. Where did the 22G go?

Bad accounting: df -h output showing missing space allocation


If I have a size 443G disk and I used 420G, I should have 23G unused space, no?

So, imagine my surprise when this started to pop-up every so often:

the volume home has only 986.3 MB disk space remaining

Whut? Only 986.3 MB remaining, when I should have around 23G free space!

To make sense of what’s happening, this gibberish from some redhat geek provides some psychological comfort for what most tutorials instruct on what to do next.

What you do is alter the percentage of the aforementioned reserved system space  to something more reasonable for a large disk, like 1%, by issuing this command:

 $ sudo tune2fs -m 1 /dev/sda7

Take note that doing this is advisable for non-root partitions, since the reserved system space is reserved for a reason. This is one upside of having a partition for all them data separate from the OS, I think.

Btw, I blame youtube-dl for all that disk usage, because I download Youtube now, because adaptive streaming don’t cache videos anymore, and I don’t want to download the same data repeatedly when I watch instructional stuff and music videos, because I am billed by the amount of data I consume*, because I live on some island where internet access is only available wirelessly.

Plus, www [dot] skytorrents [dot] in. No ads, no popups. Hope it stays that way.

* Sort of, and yes, for most, but for me, not exactly.

Solving Boot Loop on Samsung NP500P4C

You switched to UEFI and was annoyed that you can no longer get to the BIOS setup, even through the Windows troubleshooting options (the thing that you get to after holding Shift while restarting) because the option to boot to change the BIOS UEFI settings is not there.

So what you did was to look for BIOS updates and alas, Samsung software pointed you to flash the BIOS with P07RAA.rom.

However, after setting the BIOS with the newly flashed rom to boot in UEFI mode, you lose access to the BIOS Setup again. The next time you want to flash, you can’t, because the flashing utility tells you that it cannot flash when the BIOS has a newer firmware.

So you find a workaround on how to flash the BIOS manually without using the official flashing utility by Samsung. This involves running the exe from Samsung, and while it’s displaying a confirmation dialog, sifting through C:\users\<user>\appdata\local\temp\__samsung_update for the rom file and winflash.exe utility.

However, this workaround only flashed the BIOS. Apparently there’s also a MICOM component that you could only flash using the official utility. So your strategy was to flash with an older firmware using the workaround (BIOS and MICOM mismatched as it will be), and then use the official flashing utility to flash a newer BIOS and MICOM firmware.

So you look for your original firmware installer, which is P05RAA. However, you were unable to extract the rom file from this official installer because it only runs on Windows 7 and you already upgraded to Windows 10 which is the reason why you were enticed to convert the partition table to GPT from MBR and ditch Legacy boot for UEFI in the first place. You try the dumb idea to run the installer on another Windows 7 computer but of course, it has a different BIOS and didn’t even run, so that’s just dumb.

For the time being you settled on manually flashing with the P06RAA rom because that runs on Windows 10, and then using the official flashing utility to flash the P07RAA again.

At this point, you solved the BIOS and MICOM version mismatch, but not your original problem which was lack of access to BIOS setup while in UEFI mode. Also, you unnecessarily updated the BIOS from the original P05RAA to P07RAA and can’t downgrade for the moment. You will need Windows 7 to run again on this laptop to do that, and you cannot install Windows 7 because you know that after switching to UEFI boot, booting to an installer comes after Windows Boot Manager in boot priority. You cannot change that because you cannot access the BIOS setup, and Windows troubleshooting options does not list booting to USB as an option either. Weirdly, it lists your ubuntu entry on the EFI partition as the sole other option to boot from, and Windows sees it as a USB HDD at that. Supposedly, you have the option here to boot to BIOS settings, and any other boot options provided by the BIOS, if the BIOS firmware is following standards, that is. But at this point, you learn that Samsung has a history of not giving a shit about this. Because, who on earth dual boots anyway?

You are lost and defeated.

You muck around with bcdedit on Windows and efibootmgr on Ubuntu. The latter was a bad idea. A VERY BAD idea it turns out.

When lost, stop what you are doing and sleep.

Using bcdedit on Windows, you can see the entries on the Boot Configuration Data. Using efibootmgr, you cannot. You are weirded out about this. So you tried to recreate the bcd using efibootmgr. You feel uncomfortable about what you did, so on next reboot, you pressed F4 to boot to Windows recovery. Your full intention was to do the sane thing which was to repair startup from Windows. Possibly issue a bootrec.exe /rebuildbcd or something. But it was 4 a.m. and you mistakenly proceeded to shutdown the laptop instead.

That was stupid. efibootmgr corrupted the NVRAM.

The next time you powered up the laptop was fun. It starts the fan and shows SAMSUNG logo welcoming you, telling you to press F2 to access setup or F4 for recovery, but neither of which does anything. It then halts, and reboots doing the same thing. A boot loop.

Screwed as you are, you get the screwdrivers out, literally.

The first thing to get unscrewed was the laptop hard disk. The idea was that the boot priority will cascade to USB when HDD is not present. It did not. That was unnerving.

The next thing that got unscrewed is everything that has screws on the laptop. Because theoretically, if you remove the CMOS battery for a while, NVRAM will be cleared and BIOS will be reset.

So you watch disassembly videos of laptops with similar chassis design. (There are none for the exact make and model of the one you have). After a while, you feel simultaneously hopeful, desperate, and confident enough to disassemble the thing yourself. After successfully disassembling the laptop without physically breaking anything (that you know of), you remove the CMOS battery and let it rest. Boot loop persisted.

Well, at least you were able to clean the fan and replace the thermal paste. You find solder notches labeled BIOS CRS and RTC RESET and gets excited. Shorting these did nothing. Boot loop persisted.

Out of ideas, you just randomly smash keys. When nothing makes sense, everything is possible. Ex falso quod libet.

Of course, there is a method to randomly smashing keys. You figure that smashing any of the function keys was priority. Also, you do this while having a USB installer that can boot to either UEFI and Legacy plugged in to a USB 2.0 port and not the USB 3.0 one.

After a day of smashing keys while hopelessly thinking about other options including reading success stories about hot flashing the BIOS and fighting a very strong temptation to dust off a soldering iron somewhere, a breakthrough: pressing F9 allows you to boot to USB. You hear angels sing while Ubuntu liveusb loads. Light descends upon mankind once again. This is happiness.

The goal now is to flash the BIOS with the original firmware, return the hard disk partition table to MBR, and forget about using UEFI in this laptop altogether.

The only thing that’s needed is to find a way to boot Windows 7 from USB. This is supposedly unsupported by Microsoft. But compared to actually disassembling the laptop, this is easy.

You make a fresh install of Windows 7 on an old desktop, and figure out how to use a tool called Win2USB to transfer this installation to an external hdd. Booting to Windows 7, you can at last flash P04RAA rom first using the workaround method, and then flash the original firmware P05RAA using the official firmware installer from Samsung.

You backup the HDD somewhere else, convert the partition table to MBR, copy the partitions back, use Windows installer startup repair to fix booting into Windows 10, and then use Ubuntu live usb to switch grub on the installed Linux system back to grub-pc from grub-efi. At this point, all these was trivial and a joy to be able to do to a laptop that was near death just moments, no, days ago.

Contents of /etc/apt/trusted.gpg.d/ shouldn’t reach 40 items


So if you are fond of adding PPAs to your Ubuntu system (who isn’t?), sooner or later you will reach this limit and suddenly the next sudo apt-get update you do will throw multiple “…public key is unavailable: NO_PUBKEY …” errors, which will be cryptic as hell.

You will first blame your internet connection, and then be paranoid that perhaps your VPN host is mucking with your security, and then after trying multiple sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys XXXXXXXXXXXXXXXXX with processed:1 unchanged:1 results, you will realize that you need to ask Google, which will eventually tell you that there’s this bug.

And that, yeah, you have to go check  /etc/apt/trusted.gpg.d and remove duplicates and entries that aren’t in use anymore, because apparently, it happens that even after a ppa-purge the gpg keyring remains in there, filling up space, waiting for this resource limit to be reached, finally putting a rather innocent apt-get update into tantrums.

So, do a sudo apt-key list right now, and keep those gpg files at /etc/apt/trusted.gpg.d to less than 40 entries, perhaps while pondering about the life of Werner Koch, and the decisions that led him to institute such a resource limit.

softether vpnclient via http proxy thru a ppp connection on linux

Instructions are already available here and here. Basically, read the official documentation here and establishing a connection to a server is the easy part.

The tricky part is, vpnclient/vpncmd on linux doesn’t yet manage your ip routes automatically, so it has to be done manually.

The point of this post is to mention that if you’re using http-proxy*, after a connection is established on vpncmd, don’t forget to make an exception for the http-proxy-server-ip when routing ‘default’ traffic to use the tunnel. If you don’t, the connection will loop, and softether will be cut off from the server. (This is annoyingly obvious in hindsight, which is why it is very easy to miss.)

So, before doing:

ip route add remote_ip via default_gateway dev ppp0 proto static
ip route del default
ip route add default via vpn_server_local_ip dev vpn_se

Make sure to first do:

ip route add http_proxy_ip via default_gateway dev ppp0

On the other hand, the client on Windows has a feature complete GUI, plus an integrated list of servers to connect to.

* a rare case, I think, but is the point of this whole affair in my use case, because I route my traffic to the ISPs own http proxy intended for GPRS connections, in order to bypass data-capping

Huawei 3G modem, usb_modeswitch, and udev rules

Ubuntu wouldn’t detect my trusty Huawei E1550 3G

I run lsusb and it’s listed.

I look at the Disks utility and the faux CD drive and SD slot is there.

What do I do?

Well, apparently, this particular gadget I have is called a USB composite device. Meaning, there are actually many “devices” in one USB connection, each accessible by switching to its USB mode. One mode is for the modem, another is for the faux cd-rom where the installer for its connection utility on Windows is located, and yet another is for the SD card slot controller.

The thing defaults to the faux cd-rom mode when first plugged in because it makes sense on Windows. Not on Ubuntu.

So what do we do?

First, check if we can make it switch to the modem mode. Run lsusb again.

It lists devices on vendorID:productID format. Huawei’s vendorID is 12d1. The faux cd-rom product ID is 1446. We want it to switch to 12d1:1001.

try this:

sudo usb_modeswitch -v 0x12d1 -p 0x1446 -M "55534243123456780000000000000011062000000101000100000000000000"

Run lsusb again. If it’s now listed as 12d1:1001, in less than a minute it should appear on the network manager indicator. Of course, we do not want to remember all that, so we make a config file on /etc/usb_modeswitch.d/ and call the file 12d1:1446.

$sudo nano "/etc/usb_modeswitch.d/12d1:1446"

We copy the following and Ctrl+Shift+V it to the nano editor. Ctrl+X, Y+Enter.

DefaultVendor= 0x12d1
 TargetVendor= 0x12d1

On the Disks utility, Power Off Huawei MMC storage. Unplug the device and plug it back.

(Machines with correct udev rules should usb_modeswitch it automatically at this point, considering we already have the correct config file. But, no. In my case it didn’t.)

It will still be listed as 12d1:1446. What we want is to test the config file we just made.

sudo usb_modeswitch -c "/etc/usb_modeswitch.d/12d1:1446"

Run lsusb again. If it’s now listed as 12d1:1001, in less than a minute it should appear on the network manager indicator. Of course, we do not want to issue that command every time the device is plugged in. We want it to happen automatically.

udev is the program responsible for watching device changes and listing rules as to what such events would trigger. It’s located on /lib/udev/rules.d/40-usb_modeswitch.rules so we sudo gedit into that.

sudo gedit /lib/udev/rules.d/40-usb_modeswitch.rules

Notice something odd?

The format is like this (XXXX being the vendor ID and YYYY being the product ID):

ATTR{idVendor}=="XXXX", ATTR{idProduct}=="YYYY", RUN+="usb_modeswitch '%b/%k'"

Oddly, my machine’s udev rules follows that format except for Huawei entries, which it listed like this:

ATTR{idVendor}=="Huawei", ATTR{idProduct}=="1446", RUN+="usb_modeswitch '%b/%k'"

Notice listing idVendor as Huawei instead of 12d1?

So I replaced every instance of ATTR{idVendor}=="Huawei" with ATTR{idVendor}=="12d1". Ctrl+H. Input preceding data accordingly. Save file.

On the Disks utility, Power Off Huawei MMC storage. Unplug the device and plug it back. It should now switch mode automatically.

Reference: http://ubuntuforums.org/showthread.php?t=2224305

What to do if foomatic doesn’t have the ppd on its database even after installing the printer driver

Here’s what happened to my computer in the last couple of hours (about two couples, actually). I deleted the printer entry for my Epson L110 in CUPS, because I was trying to print ID pictures for my mom and somehow the printer got stuck at “processing” in the print queue dialog and also I know that it doesn’t print when I set the document I’m on to a custom page size. Something like that. So I figured that the linux-y thing to do is to start from scratch because I have no idea what’s happening.

Now, the fun part. I cannot install the printer back. I turned on the printer, plugged in the usb, and went to the friendly “Printing” dialog in Ubuntu 12.04 and clicked that nifty Add Printer button. It recognized the printer up to it’s exact make and model, Epson L110, and so I was kind of happy. And then I clicked forward, it opened a dialog box that says searching for drivers, found em, and installed something, and then after saying on a window that looks like Jockey (the Additional Drivers thing) that the driver has already been installed, the wizard went on to ask me if I’d rather provide a PPD file, or instead search for one on an accompanied database, which I observed is playfully labeled foomatic. What is an ignorant fool like me to do? I’m seeing no ppd file anywhere, so off to the foomatic database I went. Clicked Epson, scrolled through a list of lots of Epson printer models, from the L-300s to the Stylus C45’s, and voila, no Epson L110. So I’m like, whuuut? Didn’t you say you just successfully installed something a while ago? What was that for?

The takeaway in this story, after lots of thread-untangling  at ubuntuforums.org, is that the PPD files are are installed at /opt/<name of printer driver>/<blah blah>/<something>.ppd.gz. And alas, you have to unzip the files yourself, repeat the above procedure, but instead of going to that foomatic trap, you have to feed the PPD files yourself to that tease of a seemingly friendly wizard. And, juju! I can print again.

By the way, PPD means postscript printer description, I learned. Even if the drivers are already installed, your printer needs a PPD tailored to its make and model as some sort of identification for your printer to get a ride. So yeah. And the reason I’m writing about this, is because I know I kind of already figured this out before, since I can actually print normally before I deleted the driver and the printer from CUPS. It’s just that this custom paper size requirement for printing the ID photos won’t work. If I can already print back then, then it makes sense that I already went through this steps, right? Yet, fool as I am, I have no idea. Hence this blog post, for the future me.

So back to the ID photos. I was using photoprint, sudo apt-get install photoprint, to print the ID pictures on a 4R sized photo paper, and alas, linux as it is, it still refused to work. I was wiser at this moment though, since I figured out it was asking me to provide this same PPD file that the Add Printer wizard was asking. So, in the end, I was kind of wrong to uninstall the printer, because it was photoprint that actually begs for a PPD file and that’s the reason why printer tasks coming from it are stuck in processing mode at the print queue.

Basically, I had a problem, I made another bigger problem, I solved the bigger problem, and in doing so I was also able to solve the original smaller one. Kind of like how Fermat’s Last Theorem was finally solved, but no, that was far grander an endeavor than wanting to print 1×1’s for my mom, so I’m retracting the analogy. It’s for her senior citized ID, by the way, don’t tell her.