Cinnamon and Rosemary are now both happily rack-mounted in the basement (where it is cool, and where their many disk drives and fans can make as much racket as they wish).
Mostly I control them from the office with ssh and or vnc, but once in a while I need to actually be down there. My neighbor gave me a monitor, I have plenty of mice and keyboards, so I hooked up a KVM switch on the two of them so I didn’t have to keep getting behind the rack to move the monitor.
But alas, neither of them picked up the resolution of the monitor, I suppose (not sure) that with the KVM in the middle, they can’t really read the EDID and such stuff from the monitor. And since it is an “unknown” monitor, the display panel only shows 1024×768, 800×600 etc. The monitor itself helpfully tells me that it wants to be 1440×900 @60Hz.
Continue reading Forcing Monitor resolution
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.
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
A few months ago Fedora crashed, and wouldn’t boot. It seems to do that from time to time. I have about had it with Fedora. I have at least three times as much trouble with Fedora as I do with Ubuntu.
So I reinstalled Fedora. I was back-level anyway, as I have grown very cautious of their automatic update – which about a third of the time ends up requiring a full system rebuild. My thinking about it wasn’t quite this black and white, but might has well have been: “It’s going to crash eventually, and require me to scrape it down to the bare metal – I might as well wait till that happens, rather than hastening the process by trying to update fedora.”
Anyway, on that occasion back in May, I rebuilt a new Fedora 30 system on a new disk, and restored everything.
Continue reading Root Account is locked
Preparing to go off on my semi-annual visit east I was trying to ensure that the primary systems here that have encrypted root drives (oregano, cinnamon and rosemary) could each be rebooted from afar by attaching to a dropbear instance during the initramfs. See article on booting notes about that.
Somehow Oregano became unbootable. Again. It usually takes three or four hours of flailing around to figure out what little thing has caused it to point its casters to the sky. It takes only a little longer to just rebuild from scratch with the latest release.
Continue reading Fedora Crash, again
Owing to the failure of oregano detailed in the last post, I have finally taken steps to clean up a long standing issue in my internal network, viz: that oregano, the primary development computer was offering essential network services which all the other boxes relied upon. When oregano was down, almost everything else suffered.
This problem dates back at least 20 years. In early days I began the practice of having my primary linux computer act as a firewall separating the rest of the network from the internet, and as the dhcp server. I won’t try to defend the practice – it was what I did; but it has made less and less sense over the years. Plus it had the very undesirable side effect that when that primary computer was down the other systems lost their dhcp server and their path to the net.
I had this generic Chinese openwrt router which I bought last year, for reasons passing understanding. I’d planned to replace the primary router with it, but that proved a bad plan. I decided to use this extra router to fill the role oregano had filled, of separating the internal and external networks.
So this router, named obelisk, performs dhcp and dns forwarding. Henceforth Oregano will be just another box on the internal network.
I tried doing an update of fedora the other day, with the dnf system upgrade business, to upgrade in place. I should have known better. The failure is almost certainly related to the ongoing frustration of the graphics card.
One is offered the choice of two nice poisons. One may elect to use the open source nouveau driver, in which case the graphics driver will spontaneously crash about once a week forcing a reboot. Or, alternatively, one may choose instead to install the proprietary nvidia driver, in which case every few months one will get a new kernel that invalidates the driver, and the machine will suddenly not boot at all, requiring that you get in and fool around with grub and intitramfs until you can get it up enough to download and rebuild a new nvidia driver. Continue reading Automatic update of Fedora Fails
Experimenting with VMs on Ubuntu, I had the system running on a relatively small root disk. Was troubleshooting problems in the disk array, doing a lot of booting, and crashing, when suddenly the boot wouldn’t finish. Fortunately the boot wasn’t quiet and I could watch as it tried 20-30 times to start the gdm service.
I change the default to multi-user.target and got it up, and what do you know, the root filesystem is at 100%. Cleaned up some logs and crash logs and it came right up.
Interesting that it doesn’t have a way to at least alert you that is what its problem is.
I find the whole clamav subsystem to be fragile. I think this is because it is written as a tool which stands on its own, but I’m only using it as a subsystem hung onto the side of amavisd. So there is some hand-waving and jiggery pokery with the sockets and the permissions to enable the two to communicate, which has to be done manually, and is not properly a part of either subsystem.
I have another article on setting up this subsystem here, which records some of the stuff being done. I think basically, amavisd has to know where the shared socket is, in order to send messages to clamav to check, and they have to agree on the ownership and permissions of the socket and its directory.
Once in a while that stuff gets crosswise, and since I only vaguely understood what was going on, and only did the hand-waving by rote, I got annoyed with it. I’ve grown used to being able to just have things slot in and work, without my having to actually dig in and understand them. The nerve of these people, to expect me to know what is going on in order to make it work! Irony intended. Continue reading Clamav and Amavisd
At one point I was getting low on space on tarragondata, so I added an additional physical device to the btrfs filesystem containing tarragondata.
[root@tarragon backup_scripts]# btrfs fi show
Label: 'tarragon_data' uuid: d6e4b6fc-8745-4e6e-b6b4-8548142b5154
Total devices 2 FS bytes used 92.04GiB
devid 1 size 120.00GiB used 120.00GiB path /dev/xvdf1
devid 2 size 30.00GiB used 30.00GiB path /dev/xvdg
This is fine, but there are a couple of problems. The main one is that I can no longer use the EC2 snapshot capability on tarragondata, which meant that the nightly EC2 snapshot feature I was using had to be deimplemented.
But now I am about to create a new tarragon instance, and it would be really helpful to be able to snapshot tarragondata (Amazon snapshot, not btrfs snapshot) and then create a new Amazon volume with a consistent snapshot for testing. Continue reading Adjusting the size of the tarragondata volume