I had in mind (still do) to use Cinnamon as a host for virtual machine. In fact, I have had that idea in the back of my mind for many years. Recently that idea percolated up to the top again, and one thing I did was to buy some additional ram for it, I bought a 16G stick and tried to add it. It wouldn’t boot. The very poorly written manual on the motherboard seems to suggest that it absolutely requires one to have balanced sticks in the dimm slots. I find that hard to believe, but decided it couldn’t hurt to comply, and bought another stick, so I would have 2 8G sticks, and 2 16G sticks, 48G.
It still wouldn’t boot. But I noticed that this doesn’t look like the hardware is failing – it gets up into Xen and then stops. I don’t think this is a hardware problem with the memory.
After some googling around I found an article on the Suse website with a similar thing, saying that Dom0 won’t come up if it has more than 32G of memory, and offering a solution.
I’m very ignorant about Xen. I have never really gotten beyond installing it, with my Cinnamon ubuntu installation in Dom0 and using all the resources. But, but it is clear of course that the right way to do this is for the Dom 0 to be small and confined to its management job, and Cinnamon should actually be a Dom U.
What seems to be true is that if you do not specify on the command line, the Dom 0 will come up with all the memory. And that if you have more than 32GB of memory for it to come up with it will fail. Thus if you have more than 32GB of memory, you MUST avail yourself of the command line to limit the memory available to Dom 0.
I added to the linux command line in the default grub,:
And the box came up fine. Once I manage to get Cinnamon and it’s functions into separate Dom U, I will reduce the dom0 down to 1 G or so.
I suddenly had a problem on the laptop (ubuntu 18.04, Bionic), and I’ve seen similar problems on Cinnamon. One manifestation is that when I try to start terminal using the gnome-terminal.desktop app, i.e. the icon in the dock, the launch fails, with no stated reason. A look in the log reveals a problem in Python loading _gi.
I resolved to look at it later. I was able to start the terminal from the desktop by right clicking, and open terminal.
Later I had a similar problem trying to launch gnome-tweak. It failed in the same way, trying to start up the python app it attempted to load _gi.
I have only the vaguest clue what is going on here. I looked at the python code. Indeed they are attempting:
From . import _gi.
And the directory /usr/lib/python3/dist-packages/gi does not have a library named _gi. It does however have two library files:
Perusing the net, I find some suggestion that these libraries, with the 36m designation are somehow specific to or found by Python 3.6, and that if I want this to work under Python 3.7, I have to copy these files, and change 36m to 37m.
Ok, what have I got to lose? I did that simple thing – with just a simple copy in the above named directory. Lo and behold, it fixed the symptom that I was experiencing.
I don’t really like fixing things with magic when I don’t know what is happening, but now is not the time to go on a voyage of discovery with Python.
A good friend had mentioned to me that he used Arch linux in one of his recent installs. I’ve never tried it. I have this old HP laptop that a different friend gave me, when he replaced it. It isn’t that old! I decided to try installing Arch on it.
I had a bunch of issues, and ultimately today I resolved to reinstall the thing again, and record my experience. One of the issues – as usual a self-inflicted wound – is that this is a UEFI capable laptop, but the disk that is in it is MBR partitioned, not GUID partitioned. It probably would have been smarter to just partition the disk with a GUID table. But I didn’t. Below is the description of what I did.
Continue reading Setting up Arch on UEFI laptop →