At first I thought I will get used to it quickly, but that was not the case so I wanted to swap it. I’ll spare everyone about the digging I had to do to achieve this simple task, in the end it boiled down to only one line of change:

The file program/js/app.js contains a this.env.widescreen_list_template list on line 274 where you need to reorder the list so 'subject' is the first item:

You might need to do a hard refresh in your browser (Ctrl-F5), but that’s it.

Probably there is a nicer way to do this but after chasing this for an hour I wasn’t motivated enough to find it. If you know it then let me know.

The OpenSSH client starting from version 8.4 also deprecated ssh-rsa keys so it refuses to use it with the following message (when using the -v switch for verbose output):

$ ssh -v -i /path/to/id_rsa user@server
[...]
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /path/to/id_rsa RSA SHA256:1a2b3c4d[...] explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug1: No more authentication methods to try.  
Permission denied (publickey).  

Although the no mutual signature algorithm seems to be a server issue at first, it might be as well a problem on the client side – the client refuses to use the key despite not stating it clearly.

You can extend the accepted key algorithms using the option -o "PubkeyAcceptedAlgorithms +ssh-rsa" and this should solve the problem:

$ ssh -v -o "PubkeyAcceptedAlgorithms +ssh-rsa" -i /path/to/id_rsa user@server
[...]
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /path/to/id_rsa RSA SHA256:1a2b3c4d[...] explicit
debug1: Server accepts key: /path/to/id_rsa RSA SHA256:1a2b3c4d[...] explicit
Authenticated to server ([192.168.1.1]:22) using "publickey".

# touch test.txt
# setfattr --name test --value 42 test.txt
setfattr: test.txt: Operation not supported
# getfattr --name test test.txt
test.txt: test: Operation not supported

… then make sure you’re using the “user” namespace (the name of the attribute is prefixed with user.), like this:

# setfattr --name user.test --value 42 test.txt
# getfattr --name user.test test.txt
# file: test.txt
user.test="42"

And please don’t ask me why I’m posting this.

VLC reports:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9030c5ea00] moov atom not found

Ffprobe and ffmpeg reports:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55c2c17aa600] moov atom not found
videofile.mp4: Invalid data found when processing input

The details

The moov atom is basically and index and technical description to the mp4 file, as it contains info about the whole video it can only be written once the video is complete, so it is usually located at the end of the file.

If the recording device loses power, crashes, runs out of disk space, or a download fails for any reason, the file gets broken.

Unfortunately the moov atom is unique to every video, even the recorders/encoders have different parameters.

This can affect GoPro videos, iPhone recordings, live stream recordings, etc.

The (possible) solution

There is a tool called untrunc, but I recommend the fork by anthwlock as it has several improvements over the original (better performance, easier build and better compatibility).

It works by analyzing a video that was recorded by the same recorder/encoder (“good.mp4” in the example) then tries to recreate a moov atom for the broken video (“broken.mp4” in the example) based on that.

All you need to do is download the code, compile it, then run:

./untrunc good.mp4 broken.mp4

This has worked for me several times but there are detailed description in the repository so check that out if you need more info.

Note: the “good” video should be recorded with the same settings (i.e. same video mode, slow motion, etc.) with the same version of the same software as the broken one.

Although rebooting system solves the problem, fortunately it is enough to restart the systemd manager only:

sudo systemctl daemon-reexec

I suspect this is a systemd bug as daemon-reexec said to be doing nothing special apart from restarting the daemon with the config reread.

# xl create /etc/xen/configs/a.conf
Parsing config from /etc/xen/configs/a.conf
xc: error: panic: xc_dom_boot.c:395: xc_dom_gnttab_hvm_seed: failed to add gnttab to physmap [errno=22]
: Internal error
libxl: error: libxl_dm.c:1388:device_model_spawn_outcome: domain 13 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1492:kill_device_model: Device Model already exited

And to make it easier, not all the tried XEN hosts produced the above message (6 in 7 produced).

After a lot of google searches (some with no results at all) I could not get around this problem, and after some trial and error guesses I found the problematic part.

It seems that the default shadow_memory = 8 (in MB) parameter was too low. After finding this out I found a post on the Xen-devel maillist mentioning the approximate requirements of the shadow_memory: there should be 2KB of memory for every one MB of RAM assigned to the guest domain, plus a few MB per vcpu (~2MB).

Anyway, doubling this number seems to be solving this problem, my config now looks like the following:

name = "a"
vcpus = 2
memory = 6000
vif = [ "bridge=br0,mac=aa:ab:ac:ad:ae:af" ]
boot = "n"
vnc = 1
vncpasswd = "xxxxxxxx"

builder = "hvm"
acpi = 1
apic = 1
pae = 1
shadow_memory = 16
sdl = 0
vnclisten  = "0.0.0.0"
vncconsole = 1
stdvga = 0
serial = "pty"
usbdevice = "tablet"

on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"

1. Create a temporary directory:
   mkdir ./tmp
2. Extract the package contents:
   dpkg --extract package.deb ./tmp
3. Extract the control files (must be done to a directory called DEBIAN):
   dpkg --control package.deb ./tmp/DEBIAN
4. Create the new package (-Z accepts gzip, bzip2, xz and none):
   dpkg-deb --build -Zgzip ./tmp package_gzip.deb
5. Profit.

Fortunately enough there is a solution to skip all the hassle and make the modem jump right into modem mode!

To disable the CD-ROM, the SD card reader the need of usb_modeswitch and jump straight to modem mode on Huawei E173 mobile internet stick you need to send the following AT command: AT^U2DIAG=0

Note: you can use any program that can communicate with a modem via serial interface (minicom for example or hyperterminal (for Windows guys)). You might also still need to do a modeswitch one time to be able to enter this command.

The AT^U2DIAG sets what component/function is available on the stick to the user. (See the previous link for more info.) You can also check the current setting entering AT^U2DIAG? (yes, the questionmark is the part of the command).

See also:

• http://www.3g-modem-wiki.com/page/Huawei+AT-commands
• http://sysadmin.toshiro.biz/hardware/disable-cd-rom-and-sd-storage-in-huawei-e173-usb-modem/

I wrote this post for the reason I could not find these info easily enough from time to time… I had to try a few google searches to find the answer, maybe I am not the only one who had this problem and I might have used better keywords.

# dd if=/dev/vg0/test of=/dev/null bs=8M iflag=direct
1280+0 records in
1280+0 records out
10737418240 bytes (11 GB) copied, 16.0664 s, 668 MB/s
# dd if=/dev/zero of=/dev/vg0/test bs=8M oflag=direct
1281+0 records in
1280+0 records out
10737418240 bytes (11 GB) copied, 15.8712 s, 677 MB/s

Read speed: 668 MB/s

Write speed: 677 MB/s

Note: this is sequential read/write, random would be far worse, although I have not performed more tests (yet?).