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 .


Narrowing an old Problem with Teredo

I happen to have a package installed on my Linux server named ‘Phoenix’, which gives me access to IPv6 via a remote ‘Teredo’ server acting as a tunnel, and which gives me this connectivity, even though my ISP does not yet support IPv6. The Teredo server I use is not the Microsoft Teredo server, which AFAIK has been shut down by now, on the assumption that Teredo is outdated.

This Teredo connectivity presents itself to me on the user / application level, as a virtual network interface, which applications can connect to as easily as to the physical interface, but which has been implemented behind the scenes, as a translation process for data, that finally communicates over the real, physical interface. Both Linux and some Windows computers can generally do this, via the ‘TAP Device’ or ‘TUN Device’ API, which in turn needs to be supported by either kernel.

In addition to the ‘teredo’ virtual network interface, I also have another one, which is simply named ‘tun0′ on this server, and which enables my ‘OpenVPN’ server. I will not go into the details in this posting, of how to set up OpenVPN, which is a somewhat complex process documented in several other places on the Web.

But my setup effectively causes two TAP and/or TUN devices to appear as part of my network configuration by default. These two devices should not interfere which each other in principle. But by default, my ‘tun0′ interface is created during the boot process, before my ‘teredo’ interface is created.

I seem to have a glitch in my kernel, which will require that they always be destroyed in the reverse order initially created. Hence, if my ‘teredo’ interface is Up, but I next shut down my VPN, and when I next restart my VPN, the ‘teredo’ interface will fail, and will seem to lose its IP Configuration, as far as my desktop tells me, and as far as an ‘ifconfig -a‘ will confirm. Thus, I will next need to restart my Teredo service as well, in order to reestablish that.

This is a minor problem, but may have led to earlier issues, which I had thought at that time must have come from the Teredo tunneling server, which I am using. More precisely, I now think that some Teredo-related problems I was having, were actually due to log rotations which my server does.

Some of my earlier Teredo, IPv6 issues were described in This Earlier Posting. As it happens, February 13 was a Saturday, and so it is not clear how a log rotation might have caused this exact malfunction. But the problem which I now anticipate, and which would be due to my client would be as follows:

Once per month, my VPN server is given a restart scripted by me, in order to be able to close its log file and to open a new log file associated with the process. This restart can happen more or less alphabetically, without respecting any preferences that the kernel might have, for the order in which one virtual interface might be affected by the other – while neither should affect the other in principle.

It is interesting to note that my VPN configuration is created by me, while the Teredo client runs out-of-the-box, and is intended to have no log rotation, by the package maintainers.

And the result can be, that my ‘teredo’ interface goes down, leaving me with no IPv6 connectivity for the moment. I find that in practice, the ‘tun0′ interface is not affected by this fragility. And so when that happens, I need to play with my Teredo service to get it running again. And this can all happen without any knowledge, from the people who run the remote Teredo tunnel.