The officially official Devuan Forum!

You are not logged in.

#1451 Re: Other Issues » Patch Firefox like OpenBSD » 2020-01-28 19:16:34

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.)

#1452 Re: Hardware & System Configuration » SOLVED - BCM4352 wireless card problem » 2020-01-27 18:57:00

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

#1453 Re: News & Announcements » sources.list confusion. » 2020-01-27 18:49:13

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

#1454 Re: News & Announcements » sources.list confusion. » 2020-01-26 12:24:15

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

#1455 Re: Other Issues » Patch Firefox like OpenBSD » 2020-01-25 19:23:00

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.

#1456 Re: Installation » SOLVED: Stop printers from being added - kill Bluetooth » 2020-01-25 19:05:51

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.)

#1457 Re: Other Issues » Patch Firefox like OpenBSD » 2020-01-25 16:41:44

Head_on_a_Stick wrote:

^ 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?

#1458 Re: Other Issues » Patch Firefox like OpenBSD » 2020-01-25 15:20:27

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.

#1459 Re: Installation » SOLVED: Stop printers from being added - kill Bluetooth » 2020-01-23 13:13:44

Could avahi be the culprit here? It likes to connect to things for you.

#1460 Re: Devuan » make TDE desktop default and sothen devuan as different distro option » 2020-01-21 19:56:37

mckaygerhard wrote:

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.

#1461 Re: Devuan » make TDE desktop default and sothen devuan as different distro option » 2020-01-21 19:12:00

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.

#1462 Re: Off-topic » Xfce 4.15 and client-side decorations (CSD) » 2020-01-20 19:39:39

With any luck, the gtk3-nocsd package will continue to work.

#1463 Re: Installation » [solved] install to existing encrypted Btrfs subvolumes » 2020-01-17 01:31:57

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

#1464 Re: Installation » [solved] install to existing encrypted Btrfs subvolumes » 2020-01-15 17:24:48

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.whatever

reboot. The highest version kernel will be the first choice in the boot menu.

#1465 Re: Installation » [solved] install to existing encrypted Btrfs subvolumes » 2020-01-14 23:29:58

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.

#1466 Re: Installation » [solved] install to existing encrypted Btrfs subvolumes » 2020-01-14 22:42:53

waynedpj wrote:
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.

fsmithred wrote:

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,

waynedpj wrote:

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.subvol

On 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

waynedpj wrote:
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	0

#1467 Re: Installation » [solved] install to existing encrypted Btrfs subvolumes » 2020-01-13 18:04:41

Yup. 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.

#1468 Re: Installation » [solved] install to existing encrypted Btrfs subvolumes » 2020-01-13 14:11:13

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.)

#1469 Re: Installation » [solved] install to existing encrypted Btrfs subvolumes » 2020-01-13 13:12:04

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.)

#1470 Re: Installation » [solved] install to existing encrypted Btrfs subvolumes » 2020-01-13 11:11:02

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.

#1471 Re: Other Issues » [SOLVED] Security update delays » 2020-01-10 01:21:48

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.

anonymous wrote:

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 Packages

#1472 Re: News & Announcements » It'll be when It's ready, I know, but an approximation? » 2020-01-06 20:27:28

Head_on_a_Stick wrote:
basati 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.)

#1473 Re: Installation » [Solved] Beowulf installation image » 2020-01-03 00:09:28

IdeaFix wrote:

Any news about iso for testing?

Soon. We're working on making good isos.

Meanwhile, some of the derivative distros have beowulf-based isos.

#1474 Re: Devuan Derivatives » Refracta beowulf xfce isos » 2020-01-01 15:21:54

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.

#1475 Devuan Derivatives » Refracta beowulf xfce isos » 2019-12-31 14:51:38

fsmithred
Replies: 14

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.)

Board footer

Forum Software