You are not logged in.
W: GPG error: http://pkgmaster.devuan.org jessie Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BB23C00C61FC752C
W: GPG error: http://pkgmaster.devuan.org jessie-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BB23C00C61FC752Capt install devuan-keyring
And say 'yes' to the scary warning.
W: Failed to fetch http://pkgmaster.devuan.org/merged/dists/jessie-updates/main/binary-i386/Packages 404 Not Found
W: Failed to fetch http://pkgmaster.devuan.org/merged/dists/jessie-backports/main/binary-i386/Packages 404 Not FoundRemove jessie-updates and jessie-backports from your sources. They no longer exist.
The fix appears to be the same, but the file is not. The last diff I posted was between the copy
of cryptdisks-functions in the mx package, which is named same as the original file in beowulf, against the cryptdisks.functions file from ascii. I didn't notice the different filenames when I ran the diff because I used tab-completion.
The diff between the mx version of the file and the original file in beowulf, looks a lot different. I haven't examined it closely, but it's obviously not the same file. It's too big to copy the whole thing from a terminal, so I pasted it here:
https://termbin.com/xle7
This is really the diff between cryptdisks-functions in beowulf and cryptdisks.functions+patch in ascii
Unless antix or mx is still using cryptsetup 1.7, they should update their package to use the file from cryptsetup 2.1. for buster.
They also didn't include the fix for lvm. Here's what I changed in beowulf:
diff -u cryptdisks-functions.orig-2.1.0-5 cryptdisks-functions.patched
--- cryptdisks-functions.orig-2.1.0-5 2019-08-01 22:24:09.400000000 +0000
+++ cryptdisks-functions.patched 2019-07-19 02:03:11.972000000 +0000
@@ -179,7 +179,18 @@
# Removes all mappings in crypttab
do_stop() {
+
+ local vgs vg
+
dmsetup mknodes
+ if [ -x /sbin/lvm ]; then
+ vgs="$(/sbin/lvm vgscan | sed -n '/"/s/^.*"\([^'\'']*\)".*$/\1/p')"
+ if [ -n "${vgs}" ]; then
+ for vg in ${vgs}; do
+ /sbin/lvm vgchange -a n ${vg} >/dev/null 2>&1
+ done
+ fi
+ fi
log_action_begin_msg "Stopping $INITSTATE crypto disks"
crypttab_foreach_entry _do_stop_callback
@@ -187,7 +198,7 @@
}
_do_stop_callback() {
local i rv=0
- for i in 1 2 4 8 16 32; do
+ for i in 1 2 ; do
remove_mapping "$CRYPTTAB_NAME" 3<&- && break || rv=$?
if [ $rv -eq 1 ] || [ $rv -eq 2 -a $i -gt 16 ]; then
log_action_end_msg $rvYes, it's the same solution. Here's the diff against the same file in ascii. The advantage of the mx/antix package is that it uses dpkg-divert to keep the file from being clobbered on upgrades. Do they have a version for buster?
diff -u /usr/lib/cryptsetup/cryptdisks.functions cryptdisks-functions
--- /usr/lib/cryptsetup/cryptdisks.functions 2017-05-09 11:50:59.000000000 +0000
+++ cryptdisks-functions 2018-11-30 03:02:16.000000000 +0000
@@ -769,7 +769,7 @@
log_action_begin_msg "Stopping $INITSTATE crypto disks"
egrep -v "^[[:space:]]*(#|$)" "$TABFILE" | while read dst src key opts; do
- for i in 1 2 4 8 16 32; do
+ for i in 1 ; do
handle_crypttab_line_stop "$dst" "$src" "$key" "$opts" <&3 && break || ret=$?
if [ $ret -eq 1 ] || [ $ret -eq 2 -a $i -gt 16 ]; then
log_action_end_msg $retI tried it with a small install (just standard system utilities) and a big install (kde). Neither one was easy, but it is possible. I won't attempt to give you instructions. Even if I looked at my command history, I wouldn't be able to tell you what worked and what didn't.
Don't try it on a system you care about. Not now, anyway.
A fresh install should go smoothly. The installer isos are just like installing debian. The live isos use refractainstaller. Install guides can be found on this page. (scroll down about half way)
https://devuan.org/get-devuan
Confirmed. No boot menu in uefi boot. Must be a grub.cfg missing. Next iso should be better.
it seems it's still possible to access the backports through archive.debian.org.
Is there a same thing for devuan?
Packages that we don't change can be downloaded from archive.debian.org and installed manually. Don't add the repo.
Packages that we do change can be found here. You have to know what version you want. The Packages.gz file for jessie-backports is empty, so I'm not even sure if the packages you find in pool will be for jessie-backports.
https://pkgmaster.devuan.org/devuan/pool/
I'll see if I can find out more.
The TDE wiki has a page for installing on devuan:
https://wiki.trinitydesktop.org/Devuan_ … structions
No more jessie-backports or jessie-updates. Just jessie and jessie-security still work.
Looks like ascii has both of those versions. Am I looking at the wrong package?
$ apt-cache policy emacs25
emacs25:
Installed: (none)
Candidate: 25.1+1-4+deb9u1
Version table:
25.1+1-4+deb9u1 500
500 http://deb.devuan.org/merged ascii/main amd64 Packages
500 http://deb.devuan.org/merged ascii-security/main amd64 Packages
$ apt-cache policy emacs24
emacs24:
Installed: (none)
Candidate: 24.5+1-11+deb9u1
Version table:
24.5+1-11+deb9u1 500
500 http://deb.devuan.org/merged ascii/main amd64 Packages
500 http://deb.devuan.org/merged ascii-security/main amd64 PackageIt depends on what you have installed and how good you are at getting around conflicts with the package manager. Scratch that. Package managers. Plural. Start with apt or apt-get upgrade, probably a couple times with a reboot in there, then try the dist upgrade and switch to aptitude when apt (and you) can't figure out what to do next.
Is this a system you actually use to do things you want to do? If it works, don't mess with it.
If you're getting a grub prompt instead of a normal boot menu, the easiest thing to do is use that command line to boot the installed system. Then you can run update-grub to generate a new boot menu.
grub prompt looks like this:
grub>If you iinstalled the system on /dev/sda1, you would use the following commands:
set root=(hd0,msdos1)
linux /vmlinux ro root=/dev/sda1
initrd /initrd.img
bootNote: it's possible your computer will see the usb as the first drive. In that case, (hd0,msdos1) would need to be changed to (hd1,msdos1). You can use tab-completion to figure it out. Type set root=(hd0 and press TAB (maybe twice) and it will show you the partitions on that drive.
Once you've booted the system run update-grub
You got hit with an old version of devuan-baseconf. I think you had to hit the enter key on a dialog screen without noticing it said 'ceres' in the text-entry box. The updated version is in ceres now and won't add any lines to sources.list, but it also won't remove the lines that were added. Do that manually. It should be in beowulf soon, too.
The newer version will remove /data/etc/apt/apt.conf.d/05disable-recommends. (Bet you didn't notice that one.)
Sorry for the mixup.
I used the one on this page, but I think it's the same one.
http://pkgmaster.devuan.org/devuan/dist … s/netboot/
The kernel in my beowulf is dated July 19. The mini.iso is dated June 27. It might not work now. Normally when that happens, you can get part way through the installation and then get a message about kernel modules being wrong. You didn't get that.
for the Jun 27 amd64 mini.iso I get the following. Check yours to see if it was a bad download.
$ sha256sum mini.iso
85a227cb9bdf79352851195ed7e8c78c3e649dbc4b5f59a8d6232da62ef2fed9 mini.isoObviously you'll need to do all that every time you boot, until you get persistence set up.
That's true only for booting from usb. The changes to inittab will be present in the running system. Since this is a live iso that uses refractainstaller, those changes will be copied to the hard drive (or SD card?) during installation and be persistent.
You might want to look at these before you run the installer. The install guide is for the graphical installer, but the cli installer is similar. Instead of getting lists of partitions to select from, you type in the partition (like /dev/sda1 or /dev/mmcblk0p1).
https://devuan.org/os/documentation/ins … e-gui.html
https://refracta.org/docs/readme.refractainstaller.txt
Yes, devuan mounts the efi partition at /boot/efi. The problem is that grub is looking for efi/EFI/debian but efi/EFI/devuan was created. If someone wants to keep the -signed package, they need to run grub-install --bootloader-id=debian in chroot or with whatever option grub uses now to point to another target. (--boot-directory or --root-directory?)
And you don't need to specify /dev/sda when running grub-install on uefi. It knows to put the bootloader in the efi partition.
Also, someone is working on a fix for this in devuan.
Your sources.list looks good.
any idea how I can fix this?
Um, no. But let's see if we can figure out why lz4 is in modules.
Run dpkg -l | grep lz4 to see what apps are installed that have it in the name.
Then on each of those packages, run aptitude why <package> Maybe something you installed messed with those files.
Maybe also look in root's history to see if/when you edited that file.
Maybe install the debsums package and run debsums -ca to see what system files have been changed from their defaults.
Maybe 'aptitude reinstall initramfs-tools' would give you different results or other options. Try it with -s (--simulate).
OK, we got the architecture issue sorted out. Burned through a few version numbers on the way. 10.2.4 though 10.2.8 are essentially the same.
$ apt-cache policy refractasnapshot-*
refractasnapshot-base:
Installed: 10.2.8
Candidate: 10.2.8
Version table:
*** 10.2.8 100
50 http://deb.devuan.org/merged ceres/main amd64 Packages
100 /var/lib/dpkg/status
refractasnapshot-gui:
Installed: 10.2.8
Candidate: 10.2.8
Version table:
*** 10.2.8 100
50 http://deb.devuan.org/merged ceres/main amd64 Packages
100 /var/lib/dpkg/statusHere's what I have in ascii:
$ ls -l /etc/initramfs-tools/
total 24
drwxr-xr-x 2 root root 4096 Apr 26 2017 conf.d
drwxr-xr-x 2 root root 4096 Apr 26 2017 hooks
-rw-r--r-- 1 root root 1107 Feb 18 2017 initramfs.conf
-rw-r--r-- 1 root root 246 Nov 10 2017 modules
drwxr-xr-x 12 root root 4096 Nov 10 2017 scripts
-rw-r--r-- 1 root root 378 Oct 27 2014 update-initramfs.confI recognize this as the default. Yours has been changed. I don't understand why the reinstall failed.
$ cat /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax: module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_modWhat does this show?
ls -l /etc/initramfs-tools/Are you running jessie, ascii or beowulf?
Check to see if the file is really missing or if it's there but has a permission problem
If it's missing, try reinstalling initramfs-tools.
New version, refractasnapshot 10.2.6 is in ceres. We had some trouble building it, and it turns out there are separate i386 and amd64 packages. I haven't tried downloading the packages installing them on the wrong architecture to see if they work. (They'll work if they install - they're just bash scripts.)
So, if you want a portable package that you can use on either arch, or if you don't want to add ceres repos and install from there, I built the same version and uploaded it to sourceforge:
https://sourceforge.net/projects/refracta/files/tools/
The above might sound confusing. I tend to carry several deb packages of different versions of the tools on my live-usb sticks. (I try to carry the latest one, and the old ones just accumulate.)
I was lazy and now have 2 repositories in my sources list.
If this is a bad idea, please someone enlighten me...
I see only devuan and ascii in your sources. You're safe. If you started adding non-devuan or non-ascii sources, you could run into problems. Without pinning, apt will take the highest available version, so right now, if you installed/upgraded firefox-esr, you'd get 60.8 from ascii-security on auto.mirror, because that's a higher version than what's in deb.devuan.
But that will change in a few minutes or a couple hours. Repo is updating again. (Thanks, Ralph.)
I'm not marking the thread as Solved this time. Let's wait and see what happens.
It'll work with either ascii or ceres version. You could even run it from your download directory. It knows where to find the config file and excludes list.
Thanks.
05disable-suggests was a useless file. Suggests are not installed automatically. Disabling Recommends should be left to the user. Functions will be missing without them. I sure don't want to have to figure out which packages are missing when people come here with problems.
I agree that a lot of unnecessary bloat will also be missing without them. I exclude Recommends for myself and in my Refracta releases. I'm pretty sure some (most?) of the other Devuan derivatives also exclude them.