You are not logged in.
1GB? A standard system install uses around 900MB, so I guess that can work. I have noticed that encrypted installs in qemu require 2GB RAM to boot. Is that limited, too?
Did you have to edit /etc/crypttab and /etc/fstab to get it to work?
Here are error messages when trying to run the experimental version of wicd in chimaera.
$ wicd-gtk
Traceback (most recent call last):
File "/usr/share/wicd/gtk/wicd-client.py", line 41, in <module>
import gtk
ModuleNotFoundError: No module named 'gtk'
$ wicd-cli
Please use --wireless or --wired to specify the type of connection to operate on.
No operations performed.
$ wicd-cli --wired
No operations performed.
$ wicd-cli --wireless
No operations performed.$ wicd-cursesRuns
I can connect and disconnect wired. Sometimes.
It sees the one router in the house, but doesn't see the second router, which is 2 meters away. It also sees my neighbor's router. Also, iwlist does see the router across the room.
Select my router from the list and press right-arrow to configure gives the following error message.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gi/overrides/GLib.py", line 664, in <lambda>
func_fdtransform = lambda _, cond, *data: callback(channel, cond, *data)
File "/usr/share/wicd/curses/wicd-curses.py", line 1148, in call_update_ui
self.update_ui(True)
File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper
return func(*args, **kargs)
File "/usr/share/wicd/curses/wicd-curses.py", line 1161, in update_ui
self.handle_keys(input_data)
File "/usr/share/wicd/curses/wicd-curses.py", line 1039, in handle_keys
self.diag = WirelessSettingsDialog(pos, self.frame)
File "/usr/share/wicd/curses/netentry_curses.py", line 502, in __init__
self.encrypt_types = misc.LoadEncryptionMethods()
File "/usr/lib/python3/dist-packages/wicd/misc.py", line 368, in LoadEncryptionMethods
parsed_template = _parse_enc_template(enctype.strip())
File "/usr/lib/python3/dist-packages/wicd/misc.py", line 408, in _parse_enc_template
cur_type["required"] = __parse_field_ent(parse_ent(line, "require"))
File "/usr/lib/python3/dist-packages/wicd/misc.py", line 380, in __parse_field_ent
for val, disp_val in grouper(2, fields, fillvalue=None):
File "/usr/lib/python3/dist-packages/wicd/misc.py", line 655, in grouper
return zip_longest(fillvalue=fillvalue, *args)
NameError: name 'zip_longest' is not definedCheck these first:
https://bugs.debian.org/cgi-bin/pkgrepo … age=openrc
Edit: Hm, no response on one since February and no response on the other since May 2020. I guess bug reports don't help in this case. Maybe talk to parazyd or Adam Borowski. They might have more information.
In addition to the possibility of unknown breakage, there is the possibility of security vulnerabilities that will never be fixed and probably not even reported.
I tried wicd-gtk and wicd-cli from experimental. The gtk program does not start. The cli program gives an error message. (I'd have to try it again to get the message, but I gave up after five minutes.)
HELP! Is there a python programmer in the house?
I've done single partition encrypted installs, with or without lvm, and they worked. Maybe some more details about your setup would give us a clue to what went wrong.
Welcome back.
Will it eventually just morph into the release by doing the updates?
Yes. And it's almost there. The desktop theme is still partly broken and there may still be some bugs in the installer isos. I don't think there's much else that needs to be done. Oh yeah. Write the docs.
If you answer 'yes' to that first firmware question, you are expected to provide the actual files (not packages) on removable media (usb stick).
We use a modified version of debian-installer. Debian does not provide non-free firmware in their official isos, so they have that question for people who need the wireless firmware to do the install.
We put the firmware packages in the iso, but we still have to keep that question there for people who have hardware that requires firmware that we don't include for legal reasons, like some broadcom chips.
Even if you say 'no' to that first question, non-free firmware will be installed if you need it. That's because the packages are in the iso and the installer will install what's in the iso. (Unless you choose expert and decline the later questions.)
Wicd is no longer maintained and is not in chimaera or ceres repos. However, someone in IRC yesterday mentioned that wicd did not get removed when they upgraded from beowulf to chimaera. So I decided to try it.
On my laptop running chimaera with xfce, I removed connman, added a single line for beowulf main repo, ran 'apt update' and then 'apt -t beowulf install wicd-gtk'. Below is posted a copy of my apt history.log showing what else got pulled in. (Disclaimer: I have not checked versions of any those packages to see which repo they came from.)
I tested wired and wireless connections, and wicd seems to be working normally. I commented out the beowulf line and ran 'apt update' again when I was done.
Start-Date: 2021-08-21 18:57:13
Commandline: apt -t beowulf install wicd-gtk
Install: python-gtk2:amd64 (2.24.0-5.1+b1, automatic), wicd-gtk:amd64 (1.7.4+tb2-6+devuan1.1), python-is-python2:amd64 (2.7.18-9, automatic), python2-minimal:amd64 (2.7.16-1, automatic), python2:amd64 (2.7.16-1, automatic), libglade2-0:amd64 (1:2.6.4-2+b1, automatic), libpython2-stdlib:amd64 (2.7.16-1, automatic), python-dbus:amd64 (1.2.8-3, automatic), python-pkg-resources:amd64 (40.8.0-1, automatic), python-glade2:amd64 (2.24.0-5.1+b1, automatic), python-cairo:amd64 (1.16.2-1+b1, automatic), python-numpy:amd64 (1:1.16.2-1, automatic), wicd-daemon:amd64 (1.7.4+tb2-6+devuan1.1, automatic), python-gobject-2:amd64 (2.28.6-13+b1, automatic), python-wicd:amd64 (1.7.4+tb2-6+devuan1.1, automatic)
End-Date: 2021-08-21 18:57:28Edit: OK, I checked two packages. python-gtk2 and python-dbus are from beowulf. I don't yet know if I broke anything that depends on python3.
KDE and lxqt are choices in the tasksel menu. If you have a network connection during installation, you can install them. The statement about CD and DVD only apply to off-line installs.
Ignore that first question about missing firmware. There's wireless firmware in the iso, and it will be installed if you need it. If you don't want non-free firmware, choose Expert install to get some extra questions about that.
This package is in debian and devuan:
orphan-sysvinit-scripts
apt-file list orphan-sysvinit-scripts
orphan-sysvinit-scripts: /usr/lib/orphan-sysvinit-scripts/mapping
orphan-sysvinit-scripts: /usr/lib/orphan-sysvinit-scripts/update_init_d.sh
orphan-sysvinit-scripts: /usr/share/doc/orphan-sysvinit-scripts/README.Debian
orphan-sysvinit-scripts: /usr/share/doc/orphan-sysvinit-scripts/changelog.gz
orphan-sysvinit-scripts: /usr/share/doc/orphan-sysvinit-scripts/copyright
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/dirsrv
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/dirsrv.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/dnscrypt-proxy
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/dnscrypt-proxy.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/gpsd
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/gpsd.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/iwd
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/iwd.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/network-manager
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/network-manager.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/nftables
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/nftables.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/tomcat9
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/tomcat9.md5sumNixer, big thanks for the report.
libreoffice should have been taken off the autoremove list along with other things when you installed task-xfce-desktop. You're sure it's still there and didn't get removed again behind your back?
The commands I posted for you are from the release notes of refracta gnu/linux. I wrote that part about 10 years ago, and I've used it multiple times over the years. It really is just like mounting any other data partition.
On the other hand, if you try to share system files between two different systems, you'll probably run into some interesting problems we've never seen before. But that would happen with or without lvm.
I don't know if it's related, but I had 'Debian' in my boot menu until I installed lsb-release so that the lsb_release command in /etc/default/grub worked, and I then got 'Devuan' in the boot menu.
I've booted a live-usb and mounted lvm many times. it's just like mounting any other block device, with a few extra commands. Once it's attached to the filesystem, you can read and write files as you normally would.
I've also mounted lvm from another installation on a different hard drive in the same computer. It works the same way.
A few extra commands. (Leave out the cryptsetup lines if your lvm is not encrypted.)
___ MOUNT/UNMOUNT ENCRYPTED LVM ___
sudo cryptsetup luksOpen /dev/sdxY label # then run lvdisplay to get the vg name and lv name
sudo vgchange -a y <volume_group_name>
mount /dev/mapper/<vg_name-lv_name> <mountpoint>
umount <mountpoint>
sudo vgchange -a n <volume_group_name>
sudo cryptsetup luksClose labelThe host system does not need to be lvm to mount the data lvm. You just need lvm2 to be installed, and you can open the volume and mount it with a few commands.
A howto on keeping the configs separate on a shared home would probably be useful for a lot of people.
Install to the card like it's another hard drive. Make sure the bootloader gets installed to the mbr of that drive. If you want it to be uefi compatible, you will have to do some different things.
Once the installation is done and you know you can boot into it, copy the live-iso into that system and create a grub menu entry to boot the .iso file directly. See these:
https://dev1galaxy.org/viewtopic.php?id=2334
https://dev1galaxy.org/viewtopic.php?pid=6176#p6176
Yeah, we hang out in the Devuan Derivatives section.
https://dev1galaxy.org/viewforum.php?id=9
The only reason the live isos are named 'alpha' right now is because they were the first set that I uploaded. You can consider them to be betas. I will probably make new live isos in a week or two.
I installed Debian Bullseye from a debian-live xfce iso in a qemu VM and then proceeded to migrate to Devuan Chimaera.
CAVEAT - These are NOTES. They are NOT instructions. With a few more data points (supplied by you) we can hammer out some real instructions. (Hint: the yellow-highlighted commands might end up being the instructions.)
FIRST ATTEMPT
Failed. I tried to use nixer's method for buster to beowulf migration. Briefly, that involves doing the full migration to devuan with systemd still installed and running, and then rebooting into devuan with sysvinit at the end. See https://dev1galaxy.org/viewtopic.php?id=3044
This failed because it wanted to remove systemd while it was running. I also had a problem with apt wanting to remove the running kernel (5.10.0-7) because there's a newer one. I didn't bother to upgrade the debian system before the migration, but still, this is the first time I've ever seen an upgrade try to replace the running kernel. In the past, any dist-upgrades I did were happy to keep using the older kernel, even after the reboot.
SECOND ATTEMPT
Switched back to debian sources and apt-update failed, saying that bullseye-security doesn't have an InRelease file. I didn't get that error earlier, so it was probably a network glitch. I got around it by only enabling the one main repo line for bullseye.
Ran apt -f install as advised by apt.
apt install sysvinit-core
apt install linux-image-amd64 (which got removed earlier)
rebooted to sysvinit and linux-image-5.10.0-8 (still in debian)
Re-edited sources.list to chimaera
apt update (had to run dhclient to get network back)
apt dist-upgrade (no errors!)
reboot (still had a large autoremove list, including Atril)
-----------------------------------------------------
This section should only be needed after installing from debian-live,
but you may still need to reinstall task-xfce-desktop
Got to console login on reboot. Lightdm was removed but slim was not installed.
task-desktop and task-<language>-desktop are installed, but not task-xfce-desktop.
To remove all the language packs, apt remove task-* (This is only needed after installing from debian-live.)
then
apt install task-desktop task-xfce-desktop (this brinds in slim, synaptic, network-manager)
apt autoremove
reboot
OK! No network connection and boot menu still says Debian.
-----------------------------------------------------
I messed with network-manager and /etc/network/interfaces.d/setup in every way I could think of, and I still can't get a network connection.
Rebooted a live-iso with the virtual disk attached.
In chroot:
installed lsb-release and ran update-grub. That changed the boot menu to say Devuan.
also installed dnsutils thinking that might help.
After reboot, I still couldn't ping by name or number (even as root) but I tried a web browser, and I do have network.
Here's a screenshot of the window in question.
https://transfer.sh/rg1/Screenshot_lxqt-first.png
The default window manager for lxqt is currently xfwm. Muffin is there because cinnamon was also installed. This window comes up on the first login to lxqt. I don't recall seeing it in a system that had only lxqt installed. In that case, I assume there was only one window manager installed, so there was no need to ask.
The only way "back" would be to kill the desktop that's in the middle of loading itself and restart the display manager to log into one of the other desktops. It's probably easier and safer to just press ENTER, let it load, and then log out. As it says on the screen, the choice can be changed later.
Can anyone reproduce this? I just tried and failed. I chose English, American English, and Israel for language, keyboard and timezone. On reboot, 'date' tells me that it's 17:36 IDT. By my count, it's 14:36 UTC. Looks like it works the way it's supposed to work.
It might be a mismatch between versions of meld and gtk3. That's not a surprise, because gtk3 devs are notorious for changing APIs with every minor version, repeatedly causing problems for app developers.
Searching for one of the error messages, I found this:
https://gitlab.gnome.org/GNOME/meld/-/issues/224
If meld is working, I would ignore the error messages.
BTW, I can get the same "Error creating proxy..." message running meld as root from terminal in debian with cinnamon desktop.
Try xinomilo's suggestions. There's also probably a way to do it with pkexec, but I don't know how to do that.
I think it's a gtk3 issue, not necessarily meld. See if changing the desktop theme makes a difference. Since it mentions the scrollbar, maybe try installing or uninstalling gtk3-nooverlayscrollbar or gtk3-nocsd.
LXQt was probably the last desktop to be installed
But there is no user-acknowledged notion of a "last desktop environment to be installed".
so the alternatives system set it as the default, thus replacing any previous default settings. That's normal behavior of the alternatives system.
But is this the intended Debian/Devuan policy? That is, Devuan defaults to xfce4. If one installs xfce4 + something else, should Devuan default to not-xfce4? And not just that, but have a priority order of defaults based on the order of package installation? Surely that's not right.
The user does not get to control the order of package installation during the install of the operating system. That's up to the package manager, which has to resolve dependencies of the chosen metapackages. The behavior of the alternatives system will make more sense when you read the man page for update-alternatives.
And again - even suppose it's legitimate to set LXQt as the default desktop environment. Then, surely a default window manager should be set and used, rather than the user faced with a forced selection dialog.
In fact, a default window manager was selected for you. The lxqt devs thought they should double-check with you, because you had more than one window manager installed. They presented you with a list, and on that list the pre-selected window manager was highlighted. All you had to do was press enter or click OK. If you think that behavior should change, you could file a bug report. I'm guessing that behavior comes from the lxqt authors, upstream of debian.