Is the intel-microcode package installed? That injects a binary into the initrd. I'm wondering if that could be causing the confusion.

You're sure it's there? You didn't change directory between running xzcat and running file? Try using the full path to the real file instead of the symlink. (/boot/initrd.img-<version>)

BTW, it's better if you don't have the initrd inside the directory where you extract it. You don't want it to end up inside the new initrd when you repack it.

It goes by too fast for me to see what it says. There are only about four lines of output, and there's no red. I did add 'local vgs vg'  to the beginning of do_stop() but I don't know if that would make a difference.

Forget about the timeouts. The old patch still works. Here's what my do_stop function looks like now. I added the lines between 'dmsetup mknodes' and 'log_action_begin_message...'  I did not add the local variable declarations. Those are no longer in this function. Maybe I should.

do_stop() {
    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
    log_action_end_msg 0
}

Go ahead and modify refractasnapshot as I indicated a couple posts above and see if it works. If you use the cli script, please add the -d option for a verbose log. If that doesn't work, you may need to do the steps listed below.

More info...

https://lists.debian.org/debian-user/20 … 00195.html

Hmm..  My resume file contains 'RESUME=none' but there's no RESUME variable in /etc/initramfs-tools/initramfs.conf. I guess the scripts in /usr/share/initramfs-tool/ figured it out in my system. You could add RESUME=none to initramfs.conf then run update-initramfs -u -k all and then make a new snapshot. Note that this would change the host initrd. (both of them)

The script is set to remove conf/conf.d/resume and conf/conf.d/cryptroot. Those files don't exist. They changed the name of resume to zz-resume-auto, and not relevant to your case, they moved cryptroot from conf/conf.d/ to the root of the initrd.

OK. Edit /usr/bin/refractasnapshot. Change this:

   274          if [ -f conf/conf.d/resume ] ; then
   275                  echo "Removing resume"
   276                  rm -f conf/conf.d/resume
   277          fi

To this:

   274          if [ -f conf/conf.d/zz-resume-auto ] ; then
   275                  echo "Removing resume"
   276                  rm -f conf/conf.d/zz-resume-auto
   277          fi

The line numbers might be offset by a few. In the gui version it's around lines 321-323.

Edit: Wait. See next post when it arrives. I'd like to know what's inside that file.

There's a resume file in your initrd that has that uuid inside it. In a live session, run lsinitramfs /initrd.img | grep resume to see if it's there. That uuid should correspond to a swap partition. There's a way to avoid this when making the snapshot. It's in the readme. Starting with refractasnapshot-10.2 the script will do it for you (or ask what to do.) 

If you have no swap partition, you can probably get rid of the file by running update-initramfs -u. The other way to get rid of it is to unpack the initrd, remove the file (conf/conf.d/resume) and then repack the initrd. If you need the commands for that I can post them after another cup of coffee.

I tried copying .Xauthority and that didn't work for me in beowulf. Are you using that in beowulf now?

I also tried xhost + and that didn't work, either.

The problem you're running into is the change in root's path when you run su in a terminal. That path no longer contains the sbins. If you use su - instead, you'll get the root path that you're used to. But then you won't be able to start graphical apps as root from that terminal. For that, you're supposed to use pkexec. When you figure all that out, I'll read your posts. Until then, or until someone gives me good reasons not to do this, I'm working around the problem.

# grep PATH /root/.bashrc
export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Oh yeah, the other workaround is to use the full path for commands.

/sbin/blkid
/usr/sbin/update-grub

Go into rescue mode and get a shell in the installed system. Run dpkg -l | grep grub and if a package named grub-efi-amd64-signed is installed, remove it.

If that's not possible, try grub-install --bootloader-id=debian and see if that fixes it.

Note: I had the same problem with an encrypted install of beowulf, and I was able to fix it with either of the methods I described. If neither of these can help, post the contents of /etc/fstab, /etc/crypttab and /boot/grub/grub.cfg, and the output of the following comands:

fdisk -l
df -h
blkid

Either boot from grub command line or go into chroot and remove grub-efi-amd64-signed. Then run grub-install and update-grub.

"not stable" means that they might change the way it works. If it stops working, you'll notice that you're not getting notified about updates, and you can change the script then.

If anyone reading the thread knows python well enough to get it to feed the list of packages to notify-send, please tell me about it. I can get them to print all on one line, but I want one package per line the way my short script does it.