Pixel C Crash Yesterday Night

Yesterday evening, my new Pixel C Tablet did something for the first time, which was ominous. Its screen just went dark, and then started to display the logo, which it displays during a restart. It followed through with a successful restart.

Some people mistakenly think that this behavior is a reboot. If we were to call it that, then this behavior would need to be called a Hard Boot – as opposed to a Soft Boot, which happens when the user shuts the tablet down from the software-side, in telling it to reboot. In fact, a Hard Boot would be happening when the user uses the power-button to force a Hard Boot, and would have an explanation in that.

In reality, what the tablet did was a spontaneous reset. This type of event is also a File System Event, as the File System was never unmounted. Hence, the tablet also needed to repair its file system when it booted anew.

But, there are certain safety-factors built into how any serious O/S works, and built into how any file system works. So in most cases, the repair to the file system succeeds.

The fact that this has happened to a brand-new tablet, causes me to question how (un)stable it might really be. I’ve only had this tablet for a few short months now.

One of the features of how this happens, which is even less reassuring, is that after the reset, there is nothing displayed in the user interface, which betrays the fact that the reset happened. What this means is that in theory, this could be happening every night as I sleep, even while the tablet is charging, because by the next morning, there would be nothing displayed, to betray the fact that it has happened.

It just happens to have taken place once now, while I was sitting in front of it.


(Edit : )

I should add, that this tablet is running the May 5 patch of Android 7.1.2 .


A Possible Oversight on my part, Concerning FS Corruption

One of the facts which regularly concerns me about Linux, is that we Mount a File System so that we can access its files, and that we Must Unmount it at the end of any Kernel-Session, before we can power down or restart the machine, and that failure to do so results in FS Corruption.

But there is a thought which has only occurred to me recently, about how that might not translate correctly into Windows. It could be that under Windows, there is no hidden Mount or Unmount procedure, when we boot the computer or shut it down. In the past I had always assumed that this step does exist, but that Windows keep it hidden in the BG.

If Windows has no analog to this, then the problems I was describing in This Posting, may simply be due to a weak, dodgy hard-drive on the computer I name ‘Mithral’, purely in how it functions as hardware.

Also, I should next take steps to take a closer look at OS/X, which was originally derived from some form of UNIX (‘BSD’), but which may also have done away, with any sort of Mount or Unmount taking place in the BG.



I appreciate Plug-and-Play USB Keys.

I am used to an older time, when the stores did sell customers USB Drives / Keys, which were formatted with NTFS, and which, if we inserted them into our Linux PCs, would not mount. Today, the USB Keys we buy, can in some cases be plug-and-play, with modern Linux computers.

But the gap that once existed here, mainly existed between what a Linux computer could mount from the command-line, and what the desktop manager / HAL daemon was willing to mount, simply because the user plugged it in.

For example, I can perfectly-well format my USB Pen Drive to the ‘ext4‘ file system, but then the desktop manager would not accept that, because to do so would imply a security violation. It would effectively give any user ‘root‘, because any ext4 content could be stored as root, with ‘setiud, and be as the user provided. And yet, with the root password, it would still be possible to mount that…

There is a word of caution I should give fellow computer users though. Whichever computer you are on – be it Windows, OSX, Linux or other – you should still assume that if you mount a file system other than one native to your O/S, it will be mounted without journaling enabled. This means, that we will need to be extra careful, not to pull the key out, without first having done an explicit Safe Disconnect / Unmount.

It is the file system journal which will ensure, that only files are lost or damaged, which we were editing, and if so, atomically altered. Without this in place, we can end up with a USB Key which will only mount again explicitly in read-only mode, which also means that we will need to reformat again, before we can write new data to it. Hence, with no journaling, if the USB Key is pulled out while active, we could lose the whole content – although that is not usually what happens.

And so it could be said that Linux kernels as early as 2.4 had some ability to mount NTFS file systems, it would have been premature to say that those would be fully compatible with the USB Key, as provided, just because the desktop managers did not mount it. Even though they could already be mounted from the command-line.

I guess that the people who configure Linux these days, have figured out, that for their desktop manager to auto-mount an NTFS volume, does not present a security risk.

There does exist a type of NTFS driver under Linux, which will do an NTFS mount, more the way Windows does NTFS. It is called ‘ntfs-3g‘. But the only real purpose of that is to allow the owners of dual-boot laptops, to mount their Windows partitions from within Linux, which remains the only easy way to exchange data between Linux and Windows sessions. ntfs-3g was not meant for USB Keys, nor for automatic service from HAL.

Speaking of which: I just needed to trash a USB Key. I was able to mount it under Linux, and then to save a folder of data to it, which seemed to join the already-present folders in ‘Dolphin‘. But after that, whenever I removed the USB Key and remounted it, all the changes I had made were just gone. It seemed as though they had been cached, and with the cache cleared, the actual mass-storage device did not remember anything. This was accompanied by some very strange error messages, whenever I tried to repair the old key with software tools.

And so at some point I had to acknowledge that either the H/W had to have become defective, or that I had done so much reformatting, that I could reformat the little thing no more. Scientifically, the second option makes less sense, because no matter how many times one reformats the key back to FAT32 finally, its configuration should go back to one that at least works, even if it can only handle up to 40GB total. Mine would not recover into this state.

And it should also have been possible to format it with ‘etx2‘ on one specific Linux computer, to store data on that partition, to remove, reinsert and then remount the key on the same computer, and to retrieve the data. This experiment had also failed, at the point where the key had been remounted but failed to show the new data.

So now I have a brand-new USB key with a capacity for 128GB, which is plug-and-play compatible with my Linux boxes, and which remembers everything I stored on it (Insert Evil Scientist Laugh Here.)

I did not even bother to open it with ‘gparted‘ first, just to satisfy my curiosity. I do not care what FS they used. I just tried plugging it in, and it worked. And my two main Linux machines are on exactly the same build.

I had bought the old USB Key, before this present computer – ‘Phoenix’ – was installed, when its hardware was host to a system I had named ‘Thunderbox’. And Thunderbox was not able, to mount that older USB Key directly.

However, that USB Key was useful to me, in migrating some of my data, around the time that I was reinstalling ‘Aphrodite’ as ‘Venus’, and ‘Thunderbox’ as ‘Phoenix’. The key was formatted with FAT32 and held its data at the time. But what I really wanted today was a full-capacity USB Key, not limited to 40GB.

I would bet, that if I had re-partitioned it with FAT32 using my Windows PC, it would have played its old game with me: Of seeming to store data for a longer time, but then just forgetting it again.

What I needed was a new USB Key, which I now have.


(Edit 06/06/2016 : ) I just found out, that what Sony did, was just to format this new USB Key with FAT32.

A part of that which I do not understand, and which contributed to my initial confusion, was my memory to the effect that, FAT32 file systems were once not allowed to be bigger than 40GB. But this is a 128GB stick. I do not understand this.