You are not logged in.
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.)
I added haveged to Refracta isos so that it wouldn't take five minutes to boot while new ssh host keys were being made. The live iso makes new keys on every boot so we all don't have the same host keys. I didn't think it was needed for an installed system, but I could be wrong.
If you do get a login screen (maybe after you log out) the username/password combination is devuan/devuan (or root/toor).
Check the sha256sum on the .img file to make sure it downloaded correctly.
If you do nothing at the boot menu, you will get the first item, which is desktop-live i386. The system is set for automatic login, so if you got a login screen, something is wrong.
What kind of instructions would you like? There's not much to say. Just dd the image to a usb stick, boot the stick and choose a system. If you want to install one of those systems, it's probably better to download one of the 2.1 isos, because they are newer.
They're in ceres right now and should migrate to beowulf soonish. Made some changes around encrypted systems. (both installing to encrypted and making snapshot from encrypted.)
refractasnapshot (10.2.10)
* Updated splash, isolinux.bin, chain.c32, vesamenu.c32
* Copy filesystem before editing initramfs.
* Remove resume from filesystem copy when editing initramfs.refractainstaller (9.5.4)
* Exclude .kde/share/config/kdesurc
* fstab fixes for swap and /boot/efi
* Make some static entries in /dev
* Use luks1 format for encrypted /boot. (Debian bug #927165)
* Let terminal die when finished. (gui package only)
I don't forsee any immediate changes. Yesterday's vote leaves us in a slightly better position than before. There was no commitment at all to work with us. Now there is.
It wasn't my favorite proposal, but it's something we can work with. It could have been worse.
Proposal B
Choice 2: B: Systemd but we support exploring alternativesUsing its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus.
The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.
I forget exactly how I arranged the boot menu, but there should be four different systems you can boot: minimal-live and desktop-live both in i386 and amd64. Which one did you boot and what happened after you logged in?
If you want to make your own live-usb, you're in the wrong place. Use one of the usb creators or do it manually as mentioned in posts above.
I think the first thing to try would be the backports kernel. That's easy to do or undo, and it won't hurt anything. I'd try it with the ascii version of the xserver package.
The only difference I can find between the jessie version and ceres version of xserver-xorg-input-wacom is in the wacom.conf file. There's no difference between the ascii and ceres versions of 70-wacom.conf.
The udev rules file is the same (jessie/ceres), and the pkgconfig file was moved and is only different in the version listed within.
(jessie) -xserver-xorg-input-wacom: /usr/share/X11/xorg.conf.d/50-wacom.conf
(ceres) +xserver-xorg-input-wacom: /usr/share/X11/xorg.conf.d/70-wacom.confSorry I don't know what to do with this information, but here are the diffs.
$ diff -u 50-wacom.conf 70-wacom.conf
--- 50-wacom.conf 2019-12-26 11:19:49.159183000 -0500
+++ 70-wacom.conf 2019-12-26 11:21:26.183183000 -0500
@@ -1,24 +1,69 @@
+# Some of the below input classes appear 3x times, once for each of
+# "tablet", "touchscreen", and "touchpad" to ensure that the Wacom
+# driver is not accidentally bound to other types of hardware that
+# Wacom has made which are not handled by the wacom driver (e.g the
+# Wacom Bluetooth Keyboard)
+#
+# https://sourceforge.net/p/linuxwacom/bugs/294/
+
Section "InputClass"
- Identifier "Wacom USB device class"
+ Identifier "Wacom USB tablet class"
MatchUSBID "056a:*"
MatchDevicePath "/dev/input/event*"
+ MatchIsTablet "true"
Driver "wacom"
EndSection
Section "InputClass"
- Identifier "Wacom PnP device class"
- MatchPnPID "WACf*|WCOM*|WACM*|FUJ02e5|FUJ02e7|FUJ02e9"
+ Identifier "Wacom USB touchscreen class"
+ MatchUSBID "056a:*"
MatchDevicePath "/dev/input/event*"
+ MatchIsTouchscreen "true"
Driver "wacom"
EndSection
Section "InputClass"
- Identifier "Wacom class"
+ Identifier "Wacom USB touchpad class"
+ MatchUSBID "056a:*"
+ MatchDevicePath "/dev/input/event*"
+ MatchIsTouchpad "true"
+ Driver "wacom"
+EndSection
+
+Section "InputClass"
+ Identifier "Wacom tablet class"
+ MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
+ MatchDevicePath "/dev/input/event*"
+ MatchIsTablet "true"
+ Driver "wacom"
+EndSection
+
+Section "InputClass"
+ Identifier "Wacom touchscreen class"
+ MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
+ MatchDevicePath "/dev/input/event*"
+ MatchIsTouchscreen "true"
+ Driver "wacom"
+EndSection
+
+Section "InputClass"
+ Identifier "Wacom touchpad class"
MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
MatchDevicePath "/dev/input/event*"
+ MatchIsTouchpad "true"
Driver "wacom"
EndSection
+# Serial Wacom devices should always be one of tablet, touchscreen, or
+# touchpad so we can safely get away with just one match section in
+# these cases
+Section "InputClass"
+ Identifier "Wacom PnP device class"
+ MatchPnPID "WACf*|WCOM*|WACM*|FUJ02e5|FUJ02e7|FUJ02e9"
+ MatchDevicePath "/dev/input/event*"
+ Driver "wacom"
+EndSection
+
Section "InputClass"
Identifier "Wacom serial class"
MatchProduct "Serial Wacom Tablet"
@@ -56,4 +101,3 @@
Driver "wacom"
Option "Button2" "3"
EndSection
-4.19 kernel is in ascii-backports
What wacom package are you talking about? The only one I see is xserver-xorg-input-wacom which is still at version 0.34.
"Install bootloader" would have been the right choice.
https://devuan.org/os/documentation/ins … dl18.2.png
You can either reinstall or else boot the live, chroot the installed system and run grub-install && update-grub
Here's the link to the full install guide:
https://devuan.org/os/documentation/ins … e-gui.html
I wonder what devuan elements they have put into this venenux. Distrowatch has them using systemd only but also saying part devuan part debian. Confusing??
I went to their download page and saw this explanation:
The 0.X series are based on Debian and uses sysvini system, also all are live disc primary, ...
The 1.X series are based on Devuan and uses sysvinit system, and are install based disc and also package converters.
And I went to the 1.x area and downloaded the only two isos that don't have 'debian' in the file name:
venenux-minetest-1.0-i386.hybrid.iso 2018-03-20 1.1 GB
venenux-liveob-i386.hybrid.iso 2018-03-15 722.5 MB
The sources are all debian, not devuan.
I could find no packages from devuan installed in the live system.
They're using systemd.
If they have a devuan-based iso, I couldn't find it.
My recommendation is not impartial, and I won't try to debug unetbootin. Use my software to make a multi-boot usb.
refracta2usb download - https://sourceforge.net/projects/refrac … b/download
Instructions (at least read the Quick Start!) - https://refracta.org/docs/readme.refracta2usb.txt
It uses isolinux/syslinux. If you want grub bootloader on it, we can change it to that later.
60.9 in security has been replaced with 68.3
Try apt-get download thunderbird=1:68.3.0-2~deb9u1
or maybe apt update if you haven't done that lately, and then apt install thunderbird.