You are not logged in.
Add set -x to the top of the script and run it from terminal. You'll get output for every command. I checked, and they didn't move sudo. It's still in /usr/bin. I want to see where this is screwing up.
Clicking on Yes didn't produce another notification saying that I needed to install xterm or synaptic. I tried running upgrade-yes in the terminal, and received this output...
dan@deboowulf:~$ /usr/bin/upgrade-yes /usr/bin/upgrade-yes: line 9: xterm: command not found
That's weird. Does /var/lib/dpkg/info/xterm.list exist after you remove xterm? If so, the test needs to be changed.
Clicking Yes opened xterm. However, when I entered my sudo password, it gave me this output...
Enter your password [sudo] password for dan: sudo: : command not found
Again, weird. Script tests to see if you're in the sudo group. I don't think that group exists if sudo is not installed.
.
Figure out where the proxy settings are stored, and we can probably adjust the snapshot excludes file to keep them.
Yes, that was upgrade-yes.
That script is working for me now with either of these lines:
pkexec /usr/sbin/synaptic --dist-upgrade-mode true --non-interactive
synaptic-pkexec --dist-upgrade-mode true --non-interactive
"working" means it brings up the pkexec auth window and then it brings up synaptic and shows the updates. I keep canceling so I can do it again.
Currently testing in beowulf.
Synaptic could be a Recommends instead of a Depends. Those who install without Recommends are likely to have xterm installed. That could be a Suggests. Most people will get synaptic without trying.
This tests for synaptic and pkexec and falls back to xterm if they aren't both installed, and if xterm isn't there you get a popup error message.
if [ -e /usr/sbin/synaptic ] && [ -e /usr/bin/pkexec ] ; then
pkexec /usr/sbin/synaptic --dist-upgrade-mode true --non-interactive
elif [ -e /var/lib/dpkg/info/xterm.list ] ; then
sudo_allowed=$(sudo -n uptime 2>&1 | grep load | wc -l)
# for sudo with no password
if [[ $sudo_allowed -ne 0 ]] ; then
xterm -fa mono -fs 12 -hold -e 'sudo "$command"'
# for sudo with password
elif $(groups $USER | grep -qs sudo); then
xterm -fa mono -fs 12 -hold -e 'echo "Enter your password" && sudo "$command"'
else
xterm -fa mono -fs 12 -hold -e 'echo "Enter root password" && su -c "$command"'
fi
else notify-send "Error:
You need to install synaptic or xterm."
fiNote: I tried synaptic-pkexec instead of pkexec /usr/sbin/synaptic and the window came up for a fraction of a second and disappeared.
Correction: It now disappears with either line for starting synaptic. If I drop the 'non-interactive' the window stays, but it doesn't show the available upgrades. (You already knew that.)
I'm stumped. Where are you finding these synaptic options?
Oh, duh! Corrected correction: It won't show available upgrades if there aren't any. And the synaptic window will go away. Looks like this is working after all. (without the non-interactive option, the synaptic window stays up if you cancel the upgrades.)
When I read that you were playing with synaptic, I thought there should be a choice of synaptic or terminal. That's a real possiblity.
Doesn't the original python script have a way to run synaptic? (Guess I'll look at that.)
Will test the new line.
Edit: It works! Nice.
My modified upgrade-yes is not working in my openbox/lxterminal. The terminal comes up empty and does nothing. Did someone else mention that this happened to them?
It does work if I use 'xterm -hold -e <command>'.
I'm having trouble getting x-terminal-emulator to run commands, even when I start it in a terminal, and this happens in openbox/lxterminal as well as xfce/xfce4-terminal.
x-terminal-emulator -e xclock works correctly in both systems.
x-terminal-emulator -e 'echo message' does not work. In ob/lx I get the blank terminal; in xfce I get nothing.
If I use the following for /usr/bin/upgrade-yes, it works with sudo nopasswd and with root. I don't have a sudo with passwd to test. I changed the command to gparted for testing, so it doesn't actually do the upgrade. Comment/uncomment the 'command=' lines as desired. One potential problem is that some terminals need the -hold or --hold option and some don't.
#!/bin/bash
#command="apt dist-upgrade"
command="gparted"
message="If user password fails, use root password"
sudo_allowed=$(sudo -n uptime 2>&1 | grep load | wc -l)
# for sudo with no password
if [[ $sudo_allowed -ne 0 ]] ; then
sudo "$command"
# for sudo with password
elif $(groups $USER | grep -qs sudo); then
x-terminal-emulator -e 'echo "$message" && sudo "$command"'
else
x-terminal-emulator -e 'echo "$message" && su -c "$command"'
fiAfter poking around a bit, I looked in /etc/cron.daily/apt-compat. That gets used for unattended upgrades and also auto-updates the cache. One of the nice things it does is check to see if you're on battery power and cancels any actions if you are.
I have another install from the first time we played with this that I set up to use the daily auto-updates. Create /etc/apt/apt.conf.d/10periodic with the following contents:
APT::Periodic::Enable "1";
# - Enable the update/upgrade script (0=disable)
APT::Periodic::Update-Package-Lists "1";
# - Do "apt-get update" automatically every n-days (0=disable)The package cache will get updated once a day.
Edit: Changed 10_periodic to 10periodic. (see /usr/lib/apt/apt.systemd.daily and don't freak out over the name.)
Ron, what DE or WM and panel are you using?
Did you verify in a terminal (or in synaptic) on that same system that there are updates? I'm pretty sure the update-sync script, which runs 'apt-get update' is not working. (You can check to see who's running that script with 'ps aux | grep update')
You are correct that network-manager has not been devuanized in beowulf, but I'm not sure if it needs to be done. Dependencies on the buster version are libsystemd0 | libelogind0, libpam-systemd | libpam-elogind, udev | eudev. Looks like we can use it with elogind.
One more. Someone noted a high number of available updates in ascii this morning, so I added a count to show-updates.
#!/usr/bin/env bash
list=$(apt-get -s dist-upgrade | awk '/^Inst/ { print $2 }')
count=$(echo "$list" | wc -l)
notify-send "$count updates available:
$list"
exit 0If you like it, I'll add this, too.
Here's an alternate version of upgrade-yes (borrowed from refractainstaller-wrapper.sh) I'll add it to the next version. I think I've tested this with no root account, but if someone else can test that, it would be good. If sudo with no password is enabled, it just runs without asking for the password.
#!/bin/bash
x-terminal-emulator -e "echo 'If user password fails, use root password.' && sudo apt dist-upgrade || su -c apt dist-upgrade"Test failed. I thought I could use yad to show the list if notify-send failed, but notify-send doesn't actually fail. It works, but without the notification-daemon, the message isn't delivered to the desktop. Oh well, the wm users might have to read a little bit. They should be used to it.
I'm wondering if we should add a list of these as Recommends or maybe Suggests or put something about it in a readme. The last would be the easiest - it's a long list, and full desktop environments have their own ways of doing it.
https://wiki.archlinux.org/index.php/De … on_servers
Thought of one other question: What happens if there's no root account? Does the user's password work? I don't think I've ever tried 'su' without a root account.
Oh, I just got another idea about the notification. Gonna do a test.
I didn't know anything about lxpanel's notifications, so I looked it up. Arch wiki pulled through again. I added notification-daemon, started it, and notify-send immediately works.
For openbox, the .desktop files in /etc/xdg/autostart don't do anything. I added the following lines to ~/.config/openbox/autostart:
/usr/share/update-notifier/update-notifier.py &
/usr/lib/notification-daemon/notification-daemon ¬ify-send isn't working for me in openbox. The updates icon shows up in lxpanel, and when I click on it, the window comes up to ask me what to do. show-updates makes the list (I tested the script alone) but notify-send doesn't display. Is this normal, or am I missing something for openbox?
You're in luck. I backported audacity-2.2.2 last year for personal use, but I haven't actually used it. It does install in ascii. Packages for audacity and audacity-data are here if you want to try them. (amd64 only)
http://distro.ibiblio.org/refracta/file … _packages/
I don't recall having any trouble backporting the package. Might be a good one to try if you wanted.
I'm testing on a laptop with 8G ram, and I'm alotting 4G to the VM. I can get to a shell and log in. (Note: it looks and acts better in virtualbox than in qemu.) Couldn't get network working.
dmesg shows that it fails around the time it's finding usb devices.
I don't know what to do with the meminfo output. I don't think I'm running out of ram. I tried giving the VM 5G and got the same result.
The only free usb stick here is 2G. I tried it before I realized it was too small.
Got the newer iso.
I removed 'quiet loglevel=0 splash' and 'silent' from the boot command. The boot info is still covered by black screen and a progress bar. It hangs at 75% then drops down to 10% and repeats, but I don't know where it is in the boot sequence. Adding 'S' to boot to single-user gives the same result. md5sum on the downloaded iso is correct.
I tried booting in both virtualbox and qemu and got the same result. The older iso boots in both of those.
uefi: Lots of people still boot legacy mode for various reasons.
ram: Not everyone has 4G ram or someone might want to test in a VM and give it less ram.
I'm using this iso:
https://sourceforge.net/projects/archiv … ia2019.iso
Questions:
- How do I re-open an app after I minimize its window? I can't find it anywhere.
- Is there a way to boot without putting the whole image into ram? I don't mind waiting a few seconds for an app to open.
Suggestions:
- Set the keyboard layout to match the language and/or put a keyboard switcher on the panel.
note: I was able to change the layout with 'dpkg-reconfigure keyboard-configuration' and it changed immediately, but only once. On subsequent boots, it did not change the layout.)
- Put the same options in the isolinux boot menu that are in the grub boot menu.
From what I can see, this is ascii with a 4.19 kernel. I checked a few packages, and they are from ascii. (libc6, util-linux). If you got to beowulf by upgrade, it looks like it was not complete.
Refracta-9.1 is built on Devuan 2.0 (ASCII). Upgrading it to Devuan 3.0 (Beowulf, still in testing) is pretty easy. Here's what I did.
Fresh install of refracta-9.1 in a VM.
Change 'ascii' to 'beowulf' in /etc/apt/sources.list. Right now, there's only beowulf and beowulf-security. No -updates or -backports yet.
apt update
apt-get dist-upgradeYou'll be asked some questions during the upgrade regarding some configs. I gave the following answers:
- WINS no (this is the default)
- /etc/init.d/networking yes (take the new version. You might need to patch it again. Ask me about boot delay when network not connected.)
- /etc/initramfs-tools/initramfs.conf yes (take the new version. You can later edit it to use xz compression.)
- /etc/cryptsetup-initramfs/conf-hook yes (take the new version. Set CRYPTSETUP=y if you want to make an iso for an encrypted live-usb)
reboot
apt-get autoremoveDone. I haven't done extensive testing, but it seems to be working ok.
It works here. I thought I'd have to type some commands when I told it Yes to upgrade, but I only had to enter the password. Nice work.
sid/ceres still has 5.14. If (when) 5.16 moves into sid/ceres, it will likely migrate down into debian bullseye and our next release after beowulf. I think backporting kde would be a difficult task.
If you upgrade to Beowulf, as it's unstable your PATH will break
also your bootloader-id will need to be set to debian. You can do this in chroot if you reboot before restarting. smile
The PATH change was deliberate. Use 'su -' instead of 'su' and you'll get root's normal path.
You can do grub-install --bootloader-id=debian OR replace grub-efi-amd64-signed with grub-efi-amd64 (and make sure secure boot is turned off.)
I've done a few upgrades from ascii to beowulf, and I haven't seen wayland. Did get a cryptic error message that mentioned wayland. Something warning me about trying to start synaptic as root, as if I wasn't supposed to do that. Didn't make any sense to me and I did finally get synaptic working the way I want.
aptitude why wayland (or whatever the main package is called) should tell you what pulled it in. I'd be interested to know, thanks.