You are not logged in.
From what I've heard, the task of building firefox is too difficult to justify for that simple change. However, something like that might be fixed by a script applied after the install. And such a script might be appropriate in the much-neglected devuan-sanity package. (It's an orphan and it would love to be adopted by some loving maintainer.)
If you're using wicd or some other network manager, you should not configure /etc/network/interfaces. They will fight with each other if you do.
The most common cause for wicd to fail to see the wireless interface is that wlan0 is not set as the default wireless interface in wicd preferences. Maximize the wicd window and you'll see where to get to Preferences. (Or click on the little arrow if you can find it.) It's also possible to set the wireless interface in /etc/wicd/manager-settings.conf -
wireless_interface = wlan0
Here's the link for the list of https package mirrors. I gave the link for iso mirrors yesterday by mistake. That post above has been corrected.
http://pkgmaster.devuan.org/mirror_list.txt
If you use https with deb.devuan.org and you are lucky enough to get directed to a mirror that provides https, it should work. But if you get directed to a mirror that only uses http, you will get errors. To use https, your sources.list should have sources that provide https.
Note that you need to add (append) "/merged" to the end of the Base URL given for the mirrors, even if they end in /devuan. For example:
BaseURL: sledjhamr.org/devuan
looks like this in sources.list
deb https://sledjhamr.org/devuan/merged ascii main
We don't have control over the mirrors' choice of providing https or not.
If you want to use https, use a mirror in your sources.list that provides https. There's a list of them here -
http://pkgmaster.devuan.org/mirror_list.txt
If you use https, your ISP won't be able to see what you're installing. Package security is provided by gpg signing keys.
Edit: Corrected links: I posted this link first. This is the list of mirrors for downloading isos, not for getting packages.
https://devuan.org/get-devuan
It's ambiguous. (Maybe not in UK?)
, and overriding the network.trr.mode setting from Otto's change to 3.
Could mean "Otto changed it to 3, change it to something else if you want DNS over HTTPS"
or "Change what Otto did ("Otto's change") and set it to 3 if you want DNS over HTTPS"
I think the latter makes more sense given the instructions from the wiki.
If you get rid of avahi-daemon, that should be enough. The library won't do anything.
If removing avahi-daemon wants to remove other things that you know you want, you can disable it with sysv-rc-conf (or update-rc.d if you like commands.)
^ Well that is interesting, I though I had misunderstood the network.trr.mode options but it seems otto@ has set it to "3" in OpenBSD, which would still use CloudFlare for portal detection and telemetry.
DoT ftw!
Well, that's confusing. The way I read it, Otto changed it from 3, not to 3, and that way the log message makes sense. But I just downloaded firefox from mozilla, and it's set to 0 by default there. (amd64 linux version). So which did Otto really do?
The most likely scenario (by a long shot) is that we will continue to provide the version of firefox-esr packaged by debian, just like we do for almost all the packages we provide.
It looks like trr is turned off by default. I'm looking at ff-esr 68.4 in beowulf.
network.trr.mode;0
However, if you turn it on, you'll get cloudflare. This value can be modified. I haven't tried it.
network.trr.uri;https://mozilla.cloudflare-dns.com/dns-query
To turn it on, they say to go into Preferences, Network Settings, and then way down at the bottom is a checkbox to turn on DNS over HTTPS and a place to enter a different server.
Thanks for the info.
https://wiki.mozilla.org/Trusted_Recursive_Resolver
network.trr.mode
The resolver mode. You should not change the mode manually, instead use the UI in the Network Settings section of about:preferences
0 - Off (default). use standard native resolving only (don't use TRR at all)
1 - Reserved (used to be Race mode)
2 - First. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.
3 - Only. Only use TRR. Never use the native (This mode also requires the bootstrapAddress pref to be set). Note that the native resolver will be used anyway for portal detection and telemetry (Bug 1593873)
4 - Reserved (used to be Shadow mode)
5 - Off by choice. This is the same as 0 but marks it as done by choice and not done by default.
Could avahi be the culprit here? It likes to connect to things for you.
how many years was passed .. umm only 3 years.. and there's less event more? puff we need change something for sure!
do you know that LXDE/LXQT git are directly the sources for packagin rather a tar watch as does traditionally with packages .. since almost always?
It might be five years. I'm not sure. The major change that I see is that jessie was 2 years late (after the release of debian jessie) ascii was one year late, and beowulf is about half a year late. Collaborative efforts have sprung up between devuan and debian, and as a result, elogind is available in debian. I see new devuan developers who have arrived in the past year, and we continue to get new users who thought they were ok with systemd but changed their minds after they used it for some time. I think we're doing just fine.
I'm aware that almost all packages start out as upstream tarballs that get turned into debian packages by debian developers. They also get turned into other kinds of packages for other distros. But I don't understand what you're trying to say about lxde/lxqt.
It might be possible for devuan and tde devs to collaborate in the future. Right now, there are too few of us, and we're all busy with other things. TDE would be an addition, not a replacement. We aren't planning on dropping any desktop environments, but we'll see how they work when we start playing with Chimaera.
@dzz: Nice to see you around! Hope all is well with you.
With any luck, the gtk3-nocsd package will continue to work.
I think there are two problems.
1. cryptsetup was not in the initramfs, even though I had CRYPTSETUP=y in /etc/cryptsetup-initramfs/conf-hook. I added dm_crypt and dm_mod to /etc/initramfs-tools/modules and ran update-initramfs -u. That fixed the initramfs, but it still dropped me to initramfs prompt. It was still looking for the non-existent UUID, which is the UUID of /dev/mapper/sda3_crypt.
2. GRUB can't deal with luks2 format. That seems to be OK with a separate boot partition, but it might be complicated by the btrfs. That's a guess. If I'm right, creating the luks volume with cryptsetup luksFormat --type luks1 <device> might be the answer.
Note: on one reboot, I created /run/cryptsetup at the initramfs prompt before I opened the luks volume, and that got rid of the error message about the missing locking directory. But it didn't help with booting.
https://www.debian.org/releases/buster/ … etup-luks2
https://cryptsetup-team.pages.debian.ne … -boot.html
I missed you in IRC by a few minutes. There's a 5.3 kernel in beowulf-backports. And there's a refracta live-iso I made with that kernel for testing purposes. It's here: https://get.refracta.org/files/experime … 5_0440.iso
To install a backports kernel:
Add this line to /etc/apt/sources.list, apt-update, find the kernel you want and install it.
deb http://deb.devuan.org/merged beowulf-backports main
Run:
apt -t beowulf-backports install linux-image-5.whateverreboot. The highest version kernel will be the first choice in the boot menu.
HA! I got it to boot. It was dropping me to initramfs prompt and complaining about a missing UUID. That was after about a hundred lines of looking for the floppy and looking for a raid array (neither of which exist).
So, at the boot menu, I edited the entry to remove that uuid and changed it to
root=/dev/mapper/sda3_crypt
And it still dropped me to the initramfs prompt. So I manually opened the volume with cryptsetup, was asked for the password, then I ran exec /sbin/init and it booted.
fsmithred wrote:refractainstaller run in a root terminal (the live installer) won't show you the btrfs volumes. I manually opened the encrypted volume, and when the installer asked for the root partition and the home partition, I entered the /dev/mapper path for the opened luks volume.
OK so basically you set $install_dev and $home_dev to the same /dev/mapper/storage device that you opened with cryptsetup?
Yes.
You'll get a warning that the partition doesn't end with a digit (unless you named it that way) but you can still proceed. I had to edit the mount commands for / and /home inside refractainstaller to add the subvolid option,
do you mean the mount commands for $install_part and $home_part? was this the only change that you had to make in the script? would these changes make the GRUB installation not work?
Yes, I added a subvolume option. This should not affect grub. I used subvolid, but you could also use the path to the subvolume.
To get the subvolid, run btrfs subvolume list <path> where path is the path to the mounted luks volume.
# btrfs subvolume list /mnt
ID 257 gen 37 top level 5 path devuan/rootfs.subvol
ID 258 gen 20 top level 5 path devuan/homefs.subvolOn or around line 1137 of /usr/bin/refractainstaller:
mount -o subvolid=257 "$install_part" /target ; check_exit
Line 1163:
mount -o subvolid=258 "$home_part" /target ; check_exit
fsmithred wrote:and I also had to manually edit fstab on /target. (subvolume path should work here instead of subvolid.)
can you explain what and when exactly you did this fstab edit? after installation but before rebooting?
I did it in the middle of the installation. There's a pause when it's ready to install the bootloader, so that you can go to another terminal and modify files on the target or even chroot the target. Then go back and tell the installer to do the bootloader. All I did was add the subvol option. You might use more or different options.
/dev/mapper/sda3_crypt / btrfs defaults,noatime,subvolid=257 0 1
/dev/mapper/sda3_crypt /home btrfs defaults,noatime,subvolid=258 0 2
/dev/sda2 /boot ext2 defaults,noatime 0 1
/swapfile none swap sw 0 0Yup. netinst = installer iso (one of them, anyway) = regular installer = debian-installer (the actual package name)
refractainstaller run in a root terminal (the live installer) won't show you the btrfs volumes. I manually opened the encrypted volume, and when the installer asked for the root partition and the home partition, I entered the /dev/mapper path for the opened luks volume.
You'll get a warning that the partition doesn't end with a digit (unless you named it that way) but you can still proceed. I had to edit the mount commands for / and /home inside refractainstaller to add the subvolid option, and I also had to manually edit fstab on /target. (subvolume path should work here instead of subvolid.)
Full path missing in grub is probably why it won't boot.
Yes, if you can get the installer (on the netinst iso) to install to the root subvolume, you should be able to copy /home/* to the second subvolume. I've done the equivalent with encrypted or non-encrypted ext partitions many times.
I got it to install with the live installer if I do a lot of manual fiddling with it. But I can't get it to boot, even with a separate /boot partition.
See if you can get the regular installer to work without formatting as I described above. If that doesn't work, we can come back to a more manual approach.
Edit/Update: I can't get it to work with the installer isos, either. I tried ascii-2.1. Expert install, check cyptsetup at the extra installer components list, drop to a shell when it reaches partitioning, try to open the encrypted volume with cryptsetup, and the command is not found. (the debs are on the media, but they haven't been installed at this point.)
If I try to select the btrfs partition to use as btrfs, it tells me that no root has been selected. Looks like you have to do it the way it was described in the other thread (install to a temp dir and then rsync it all into place.)
When you get to the partitioning phase in the installer, if your subvolumes are listed, you should be able to highlight one, press enter, and get to a screen that shows options for that parititon - use as (filesystem type), format, mountpoint, etc. If you highlight a line and press enter, you can edit that line. For the format line, pressing enter will toggle yes/no.
When you're at the screen that lists your partitions, there may be an upper-case F or K on each line. F means the partition will be formatted, K means keep the current filesystem (don't format).
Meanwhile, I will try to reproduce your configuration and see if I can do it with the live installer.
OK, I tried a couple of times. I think it's possible with the live installer, but I haven't succeeded yet - I'm booting to a grub_rescue prompt.
I had to hard-code the subvolid into the mount commands in the install script. If/when I try it again, I will make a separate /boot partition. Oh yeah, I just remembered. In beowulf, you have to use luks format type1 for full-disk encryption to work. That's probably why my grub is lost. (I did add the cryptodisk line to /etc/default/grub.)
When you get to the partitioning phase in the installer, if your subvolumes are listed, you should be able to highlight one, press enter, and get to a screen that shows options for that parititon - use as (filesystem type), format, mountpoint, etc. If you highlight a line and press enter, you can edit that line. For the format line, pressing enter will toggle yes/no.
When you're at the screen that lists your partitions, there may be an upper-case F or K on each line. F means the partition will be formatted, K means keep the current filesystem (don't format).
Meanwhile, I will try to reproduce your configuration and see if I can do it with the live installer.
This (below) is a different problem. The security update delays have been fixed. The problem you're seeing here is the reason we recommend using the codenames in sources.list.
ascii is stretch
beowulf is buster
stable is not the same release in debian and devuan right now. They will be the same again when beowulf is released. Until debian moves to their next release.
devuan
$ apt policy firefox-esr
firefox-esr:
Installed: 68.3.0esr-1~deb9u1
Candidate: 68.3.0esr-1~deb9u1
Version table:
*** 68.3.0esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/main amd64 Packages
100 /var/lib/dpkg/status
60.7.1esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-updates/main amd64 Packages
60.6.3esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii/main amd64 Packages
-------------------------------------debian:
firefox-esr:
Installed: 68.4.1esr-1~deb10u1
Candidate: 68.4.1esr-1~deb10u1
Version table:
*** 68.4.1esr-1~deb10u1 500
500 http://deb.debian.org/debian-security stable/updates/main amd64 Packages
100 /var/lib/dpkg/status
68.2.0esr-1~deb10u1 500
500 http://deb.debian.org/debian stable/main amd64 Packages
devuan (beowulf)
firefox-esr:
Installed: 68.3.0esr-1~deb10u1
Candidate: 68.4.1esr-1~deb10u1
Version table:
68.4.1esr-1~deb10u1 500
500 http://pkgmaster.devuan.org/merged beowulf-security/main amd64 Packagesbasati wrote:The group of developers has to have an idea of where things are going
I can't speak for the developers but fsmithred has just released the first beowulf beta for Refracta so the release is approaching.
Yup. As soon as we get the installer isos right, we'll let you play with them. Meanwhile, I switched my main box to beowulf. (Bye bye Jessie. I'm sorry it didn't work out as we first expected, but I had nothing to do with that. I kept you as pure as I could.)
Any news about iso for testing?
Soon. We're working on making good isos.
Meanwhile, some of the derivative distros have beowulf-based isos.
These isos were made with refractasnapshot, which has a pretty extensive rsync excludes list and a high compression on the squashfs. Before that, most of the packages are installed without Recommends. The initrd is xz compressed - that saves a few MB.
I started with the no-X isos I made with live-sdk, installed onto virtual disks, added software and customized some stuff and then made a snapshot. Until ascii, these things fit on a CD.
Betas:
https://get.refracta.org/files/testing/
I know there are a couple of issues with the high contrast theme. (wrong icon set, one wrong launcher.)
What else? (other than missing documentation. Don't worry, you'll figure it out. Release notes will come later, but they won't be much different from the last notes.)