You are not logged in.
apt and apt-get are mostly the same. I ran it as user instead of root, so there's a little more message than usual.
Here's an example of what I was describing:
$ apt -s remove gvfs-daemons
NOTE: This is only a simulation!
apt needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
gvfs-common gvfs-libs libavahi-glib1
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
gvfs gvfs-backends gvfs-daemons
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
Remv gvfs-backends [1.38.1-5]
Remv gvfs [1.38.1-5]
Remv gvfs-daemons [1.38.1-5]Ron, it sounds like you ran into the eudev bug. https://dev1galaxy.org/viewtopic.php?id=3520
Booting to ram is one way to avoid it. Other way is to put the image on usb instead of dvd, but that still might fail if it's a slow usb.
Unplug and replug mouse and/or keyboard, then they'll work.
You might still have some problems after that, like no sound or no wireless, both due to kernel modules not getting loaded. All the problems go away if you stop and start eudev. (stop it and start it. restart won't fix it.)
A patched version of eudev is expected to show up in beowulf-proposed-updates some time in the not-too-distant future.
Almost forgot to say this: The problems generally don't show up in an installed system. (I know of one case, but it's not a normal setup.) And if you do have this problem with the installed system, it's easy to fix it. (one word and one number)
To which of the developers, would you suggest, that I send a PM so that I can receive their feedback on my original post?
Thanks!!, MTB.
I don't know. You already heard from the only one who uses synaptic
I can tell you that apt and apt-get will not automatically remove packages that were automatically installed with the packages you are removing. In a terminal, you would be told to run 'apt autoremove' to remove them.
On the other hand, aptititude will remove them automatically. The only way I know to get them off the removal list is to install them manually, and then they get marked as 'manually installed.'
It's probably safe for you to do it in synaptic and then you can tell us whether it autoremoves what is no longer needed or makes you do it manually. It's especially safe since you already have that list of packages.
I did find a relatively untouched desktop-live install in a VM. Here's 'ps_mem.py' and 'free -m' outputs. I don't have a netinstall desktop right now.
Private + Shared = RAM used Program
156.0 KiB + 37.0 KiB = 193.0 KiB uuidd
188.0 KiB + 33.0 KiB = 221.0 KiB acpid
204.0 KiB + 30.5 KiB = 234.5 KiB sh
268.0 KiB + 61.0 KiB = 329.0 KiB rtkit-daemon
280.0 KiB + 53.5 KiB = 333.5 KiB init
312.0 KiB + 75.0 KiB = 387.0 KiB cron
360.0 KiB + 89.5 KiB = 449.5 KiB dbus-launch
436.0 KiB + 27.0 KiB = 463.0 KiB mdadm
488.0 KiB + 44.0 KiB = 532.0 KiB rpc.idmapd
692.0 KiB + 39.0 KiB = 731.0 KiB ssh-agent
508.0 KiB + 225.0 KiB = 733.0 KiB rpcbind
628.0 KiB + 126.0 KiB = 754.0 KiB gpg-agent
668.0 KiB + 177.5 KiB = 845.5 KiB xfconfd
380.0 KiB + 510.5 KiB = 890.5 KiB avahi-daemon (2)
692.0 KiB + 263.5 KiB = 955.5 KiB gvfsd-metadata
544.0 KiB + 448.0 KiB = 992.0 KiB su
276.0 KiB + 744.0 KiB = 1.0 MiB saned (2)
876.0 KiB + 197.0 KiB = 1.0 MiB rpc.statd
844.0 KiB + 291.5 KiB = 1.1 MiB at-spi2-registryd
740.0 KiB + 422.0 KiB = 1.1 MiB getty (6)
1.0 MiB + 403.0 KiB = 1.4 MiB at-spi-bus-launcher
936.0 KiB + 575.5 KiB = 1.5 MiB gvfsd
1.4 MiB + 167.5 KiB = 1.5 MiB ntpd
1.3 MiB + 274.5 KiB = 1.6 MiB xscreensaver
1.6 MiB + 115.5 KiB = 1.7 MiB exim4
1.7 MiB + 83.0 KiB = 1.8 MiB elogind-daemon
1.6 MiB + 309.5 KiB = 1.9 MiB bluetoothd
1.9 MiB + 121.0 KiB = 2.0 MiB rsyslogd
1.4 MiB + 809.5 KiB = 2.1 MiB gvfsd-trash
1.6 MiB + 641.5 KiB = 2.2 MiB upowerd
1.8 MiB + 525.5 KiB = 2.3 MiB dbus-daemon (3)
1.6 MiB + 761.0 KiB = 2.3 MiB cupsd
2.4 MiB + 352.5 KiB = 2.8 MiB dhclient
1.7 MiB + 1.1 MiB = 2.8 MiB cups-browsed
2.3 MiB + 469.5 KiB = 2.8 MiB polkitd
2.6 MiB + 260.0 KiB = 2.9 MiB udevd
1.8 MiB + 1.2 MiB = 3.0 MiB bash (2)
2.1 MiB + 1.2 MiB = 3.2 MiB gvfs-udisks2-volume-monitor
1.9 MiB + 1.3 MiB = 3.3 MiB panel-6-systray
2.2 MiB + 1.2 MiB = 3.4 MiB xfce4-session
2.2 MiB + 1.7 MiB = 4.0 MiB panel-2-actions
3.3 MiB + 1.4 MiB = 4.7 MiB xfsettingsd
4.3 MiB + 1.7 MiB = 6.1 MiB xfce4-notifyd
4.3 MiB + 2.0 MiB = 6.3 MiB xfwm4
6.3 MiB + 1.3 MiB = 7.6 MiB udisksd
5.6 MiB + 2.3 MiB = 7.9 MiB xfce4-panel
7.2 MiB + 1.4 MiB = 8.6 MiB wicd-monitor
9.2 MiB + 870.5 KiB = 10.1 MiB wicd
9.2 MiB + 978.5 KiB = 10.2 MiB slim
10.2 MiB + 1.6 MiB = 11.8 MiB tumblerd
12.0 MiB + 1.5 MiB = 13.6 MiB pulseaudio
8.3 MiB + 6.7 MiB = 15.0 MiB polkit-gnome-authentication-agent-1
12.1 MiB + 5.6 MiB = 17.7 MiB xfce4-terminal
15.2 MiB + 4.0 MiB = 19.3 MiB xfdesktop
13.1 MiB + 6.2 MiB = 19.3 MiB xfce4-power-manager
12.7 MiB + 6.9 MiB = 19.6 MiB Thunar
17.8 MiB + 3.0 MiB = 20.8 MiB wicd-client
20.0 MiB + 1.5 MiB = 21.6 MiB applet.py
43.4 MiB + 6.7 MiB = 50.2 MiB Xorg
---------------------------------
333.6 MiB
=================================
total used free shared buff/cache available
Mem: 1990 286 1456 3 247 1563
Swap: 255 0 255HevyDevy, thanks for checking that. If you have ps_mem.py, I'd like to see the output.
Edit: interesting tidbit Jessie brought up in regards to the difference in the live installation and the install media, apparently the live installer which is refracta-installer gains 20% percent more resource usage over the devuan/debian installer?
I saw that, and I don't know what's causing it. The live does have some extra packages and some of those have scripts in /etc/init.d, but I don't see anything running in 'ps ax' such as live-boot or haveged. Maybe the difference is due to the desktop-live having gvfs-backends installed. I don't have two clean installs to compare right now, and I'm kinda burned out on installing. Will have to remember to look at this later.
The iso image contain pae kernel headers instead of non-pae. I reported this in the post above. (
Thanks for clarifying. I misunderstood. I filed a bug report so it can get fixed in the point-release.
https://bugs.devuan.org/cgi/bugreport.cgi?bug=487
fsmithred wrote:The non-pae kernel is default for those with old machines. The linux-headers package is in the iso, but it does not get installed by default. That's standard for debian and consequently for devuan.
.I'm upset that the bug was not fixed in the final version of the disk Devuan GNU/Linux 3.0 (beowulf) i386 - desktop 20200526
I'm confused. What did you want to happen? What are you calling a bug?
Pulseaudio is still around in beowulf. The difference is that if you're using systemd, you should not let pulseaudio autospawn itself, because systemd will do that for you. Since this is devuan and there is no systemd to handle everything, pulseaudio has to autospawn itself.
PA is removable if you prefer to be without it.
Encrypted root partition with unencrypted /boot, bios boot, installed from desktop-live does not boot.
It seems that grub-pc package no longer runs a configure dialog when you install it with 'dpkg -i' which is what the desktop-live wants to do for a bios install. This doesn't seem to be a problem with unencrypted root partition and a single hard drive (virtual). In that case, grub gets installed to the MBR of /dev/sda without asking you. I don't think it's a problem with full-disk encryption, but it's been at least a couple months since I've done one of those.
There are two possible solutions:
1. Use the cli installer instead of the graphical. Run 'refractainstaller' from a root terminal (or with sudo).
or
2. If you really want to use the graphical installer, edit /usr/bin/refractainstaller-yad to uncomment line 1762 to enable the choose_grub function after the grub-pc package gets installed.
I think someone may have reported this when we were testing the betas, but I don't feel like looking for it right now. I did file a bug report: https://bugs.devuan.org/cgi/bugreport.cgi?bug=485
There's a bug report for the same issue, not a live-iso, but it's the same problem.
Put the sleep after start-stop-daemon and right before 'udevadm trigger --action=add'.
https://bugs.devuan.org/cgi/bugreport.cgi?bug=483
Thanks. For some reason, security updates on pkgmaster are going to *-proposed-updates. We're not yet sure why. Until then you can add ascii-proposed-updates or beowulf-proposed-updtates, whichever is appropriate.
e.g.
deb http://deb.devuan.org/merged ascii-proposed-updates main contrib non-freeHaven't done it, but I have some thoughts. I normally do an encrypted persistent volume for live-usb systems. The squashfs is not encrypted, but it is read-only, so it's pretty safe.
It might be possible to encrypt the partition that holds the squashfs and use grub as the bootloader. You'd have to edit the grub.cfg to add the same stuff that gets added when you do full-disk encryption. Set the usb up like a multi-boot live usb, except make the first partition a luks-encrypted volume with ext4 filesystem.
Works here on my beowulf. I didn't feel like installing wmctrl, so I changed that line to
printf $titles "wm:" ; basename $(cat /etc/X11/default-display-manager)I still don't get "If you're booting UEFI mode, you will also need to remove grub-efi-amd64-signed and just use grub-efi-amd64.", though. Any explanation what to do or what is meant appreciated.
Are you using secure boot?
Are you unable to boot your os?
If your answer to the second question is 'yes' then you will need to do something. We will help you figure that out. Otherwise, you can ignore it.
In previous testing, the bootloader had to be named 'debian' if you used the signed grub package. Otherwise, it could not find the bootloader, because $prefix was hard-coded as EFI/debian. I don't know if that's still true in beowulf.
Refractainstaller has only been used on x86 architectures. I don't know what changes you'd need to make for arm.
If you wanted to use an existing fluxuan iso with the pi-imager, I think you would unpack the iso, then unpack filesystem.squashfs and use that in place of the debootstrapped system. Then make whatever changes you need to make to it.
Edit: Of course, that won't work. Packages are for the wrong arch.
lsb-base and lsb-release in ascii are devuanized packages. You can tell because 'devuan' is in the version. In beowulf, chimaera and ceres, we're using the unchanged debian versions.
The code you're looking for might be here: https://salsa.debian.org/debian/lsb
Changing the 'ID=' line in /etc/os-release will also change the name of the bootloader created by 'grub-install'.
Correction:
With ID=mydevuan, grub-install creates a bootloader at /boot/efi/EFI/mydevuan
With ID=devuan, it does not. It just went back to using /boot/efi/EFI/debian.
So, like I said before, I probably can't explain it.
Could someone please explain what exactly needs to be done?
Probably not, but I'll try. I think the behavior of grub has changed since that was tested for the release notes. To change it in the boot menu, you can either change it in /etc/default/grub or /etc/os-release and re-run update-grub.
Like this works:
GRUB_DISTRIBUTOR=DevuanChanging the 'ID=' line in /etc/os-release will also change the name of the bootloader created by 'grub-install'. I don't think /etc/default/grub will do that. Correct me if you find otherwise.
Changing it in /etc/lsb-release works, too, but you won't have that file unless you created it. Or maybe I created it for you, if you're running Refracta.
If you have secure boot enabled, I don't know what will happen. Some time ago, the bootloader directory on the efi partition needed to be named 'debian' if you were using the signed version of grub-efi-amd64, even without secure boot enabled. That appears to have changed in chimaera. Either that or my motherboard is lying to me about secure boot. That's a distinct possibility, since manufacturers can seem to agree on uefi implementations.
cp /usr/lib/refractainstaller/inittab.debian /etc/inittabThat's the easiest way.
Welcome to Devuan.
You've been around linux long enough to see that every release gets bigger and more hungry for resources. Part of the reason we left the graphical installer out of the installer isos was to leave more room for applications that might be needed when installing without a network connection.
If you've used graphical installers on other distros, you might be disappointed with the debian-installer's rendition. The ncurses variety that you saw is actually easier to use - it requires less motion.
You can see for yourself. There's a graphical installer in the mini.iso on this page.
https://pkgmaster.devuan.org/devuan/dis … tboot/gtk/
The mini.isos get made when the installer gets rebuilt. They're mainly for testing, and they require a wired network connection to get even the most minimal working system.
The live isos use a different installer that just copies the system from the media to the hard drive. It takes about 10 minutes, but you don't get to choose the software.
.
Thanks. I just finished a dist-upgrade from beowulf to chimaera on a laptop. Had some trouble with conflicts and had to remove libpolkit-backend-1-0 manually (it no longer exists) and upgrade one of the libpolkit packages manually. Also used a combination of apt and aptitude to get through it. I didn't take notes, so I don't have instructions for anyone.
This was with xfce. I think it was a refracta-ascii that I upgraded to beowulf a year ago. Now it's chimaera and seems to be working ok.
A condensed version with the essentials is always good, especially when I don't have to do it. Thanks. ![]()
The copy of cryptdisks-functions that I linked has two patches applied to it. One for lvm and one for plain luks-encrypted partitions.
For jessie and ascii, the file is cryptdisks.functions, not cryptidisks-functions. The files are very different, but the same changes work. I'm sure it's documented in several threads on this forum, probably including this one.
We did not fork cryptsetup, so you'll get the shutdown delay no matter how you install the system.
Stopping remaining crypt disks...root_fs (busy)...root_fs (busy).....root_fs (busy).....root_fs (busy).....root_fs (busy).....root_fs (busy)......
Replace /lib/cryptsetup/cryptdisks-functions with the patched copy I linked above.