Recent comments on posts in the blog:

Re: rescue section

tincho, yes, the mount command is there, but this one:

chroot /target mount -a

did not mount the boot partition and there were no errors either so I had no idea that it was not mounted :)

By the way, thanks for the guide!

Comment by vanix
Re: rescue section

Vanix,

Then you missed one step. The mount command is in the guide! :)

Comment by tincho
Rescue section

After reading the comments and the tip from kuschelmaus I've made needed changes to /etc/defaults/grub file. And it didn't work, I tried every possible solution out there. But the problem was that I had to manually mount boot partition

mount /dev/sda1 /target/boot

Otherwise, update-grub2 didn't have any effect and I was getting stuck with error message that eth0 unknown device. I had to simulate installation on my local VirtualBox machine because there is no console access available at Kimsufi.

Comment by vanix
Thanks
Kuschelmaus: Thanks a lot for noticing that! I think that when I last reinstalled my server I had to do this, but forgot to update the notes!
Comment by tincho
Stretch network setup struggle

Just in case you encounter the same problem when setting up Debian 9.

After setting up everything based on this guide, which I used since wheezy, thanks for that by the way :), I noticed that my server wasn't coming back online after rebooting.

Problem: eth0 doesn't exist anymore... so no network if I setup a non-existing nic.

Solution: Either disable the new naming schema in GRUB_CMDLINE_LINUX="net.ifnames=0" or check your predictable device name by running udev and look for eth0 (since the rescue system is still a debian 8 based OS). I just dumped it to a file then searched for eth0 with vi. To dump everything just run: udevadm info -e > /tmp/udev.log then look for the predictable name in this order: ID_NET_NAME_FROM_DATABASE ID_NET_NAME_ONBOARD ID_NET_NAME_SLOT ID_NET_NAME_PATH ID_NET_NAME_MAC

In my case it is an onboard device and the name it got is enp1s0. After adding that to GRUB_CMD_LINE and in /etc/network/interfaces I could finally get into my dropbear and unlock the system. Took me two days to figure that out. Maybe it safes someone a lot of time...

Comment by kuschelmaus
Downloading
The BlankStore (although deprecated) from microG works well for me for downloading, searching and updating applications I don’t find in F-Droid.
Comment by mirabilos
comment 2

Hi Martin,

Using microg/nogapps for around 4-5 years now and also very happy!
Signature spoofing allows microg to replace google play service by giving microg the same signature. Google implemented a forced dependency model in Android which gives app suppliers the power to create a dependency on a company instead of a library. This makes conditional sale possible and easy. If I am correct, the signature spoofing patch only allows microg+blankstore and not other apps to replace google play service. Personnally I think it would even be better if you had the freedom to redefine all dependencies yourself and get rid of the possibility of conditional sale entirely. It is up to the user to decide what company to use and not the supplier. There is no extra danger from malicious actors with the patch unless you download an app with a microg signature and give that app the signature spoofing permission. I think this risk is equal or less to the risk of downloading an app which has a Google signature. Cyanogen's argument is solely based on the idea that google play services should not be replaced by another app, even if it is disabled by default and the user has to explicitly enable it a couple of times. End of cyanogen argument. Since then I am avoiding cyanogenmod when possible. Very happy with Omnirom right now.

Best! Bob

Comment by debianbob
make your own app repo
With F-Droid, you can make custom app repositories from any APKs that you have, so you can make your own automated Google Play channel using apt-get install fdroidserver gplaycli
Comment by hans
And what about the license?

Apart from the security problems that most non-system package installers impose on their users, there is another severe problem: Uncertainty about software freedom.

When I use apt with official repositories from Debian, I can be confident, that all stuff is free software and license incompatibilies are unlikely. When using npm, pip, and friends, I faced many problems in the past: Very often compressed, minified, combined (JS) files with totally insufficient information about their authors and respective licenses. Or convenience copies of other programs or parts of other programs with minor or not-so-minor changes without clear indication, what this software was and by whom, and what the changes were and by whom.

Comment by debacle