You are not logged in.
I don't have any actual *knowledge* to offer, but perhaps I could fling some comments at the wall?
Do both the pendrives give that "Input/output error while closing the filesystem" ? Such a message could lead a suspicious person to suspect that the drive is failing. Admittedly it seems unlikely that 2 drives would fail at the same time, but perhaps if they were from the same batch, e.g. bought in the same blister pack? Then again....2 months apart is not exactly "the same time"
I tend to take the idea of a hardware failure as a personal insult, especially if it is something I paid my own actual money for. But it does happen sometimes. You might save yourself a lot of pain if you can accept the loss and beg/buy/borrow/steal another drive?
Is there a chance you could try with another kernel, perhaps an older one?
Another desperate clutching at straw: could it be a power issue, with something power-hungry using the usb bus? do you have a powered usb hub available for experimentation?
Could the usb socket be experiencing mechanical stress, perhaps with the laptop on a nonlevel surface (such as, to pick a random example, a lap) and the flashdrive sticking out of the side, brushing against couch cushions or blankets? Or perhaps you have the "bulky devices in slots that are too close together" problem? Perhaps you have another computer available for experimentation.
OK, getting more desperate....how is your environment for static electricity?
Good luck.
G'day and Good Year.
I have encountered the idea that there might be security benefits from keeping my adventurous Internet browsing and my Internet commercial transactions (e.g. shopping, banking) on separate machines. I wondered if these separate machines could be VMs.
I also read that while it is convenient to access these VMs using VNC, VNC's access is less secure than it might be, and can be improved by a mysterious magic called "SSH tunneling". This would offer some protection against others on my network (guests, neighbours, wardrivers in the street outside, miscreants infiltrating my media player(s) or IoT lightbulbs, etc) possibly reading the unencrypted VNC traffic.
This hypothesis was stated on the Internet, so it must be true. I mean, all Internet statements are true, not so?
So...trying the VM route, I have at my disposal
1) A Linux computer I refer to as my "PC" (it's a bit feeble to be a VM Host)
2) A Linux computer I refer to as my "VM Host" (Powerful, noisy, clumsy to work with)
3) A number (1 is a number, OK?) of "VM"s which can be run on the "VM Host"
Currently, to set the scene: I sit at my PC, and connect to my VM Host with an SSH tunnel via the incantation:
ssh -L 5901:localhost:5901 -l <VM Host userid> <VM Host IP>
This gives me a terminal on the VM Host, where I spin up a live VM thusly:
qemu-system-x86_64 <..so..many..parameters..> -vnc :1
To access the desktop (and therefore the browser) on this VM, I fire up remmina on the PC, select VNC connection method, and point this at
localhost:5901
This opens up the VM's desktop in the PC's VNC client window and I can browse OR transact. With multiple VMs, I could keep these activities separate.
My question is:
1) Am I benefitting from the magical protection of "SSH tunneling" in my interactions all the way between my PC VNC client and the VM desktop?
or
2) Does this protection only extend to the connection between the PC VNC client and the VM Host, leaving communication between the VM Host and the VM itself protected only by VNC security? Perhaps I need to create another SSH tunnel on the VM host?
My interpretation is that it is the first option. That is: SSH tunneling covers the comms between remmina i.e. the VNC client on my PC, to qemu-system on the VM Host, and that is everything I need, because the VM exists only in qemu-system. There is no unsecured comms between qemu-system and the VM, because the VM does not exist outside qemu-system.
I understand that a lot of other threats are being ignored, but my interest, for now, is in the extent of the SSH tunnel's protection.
I hope I've explained it clearly enough to receive some feedback that I can actually understand, though my powers of understanding are quite feeble.
When in "dependency-hell" I usually re-install all the removed packages if I can copy and paste the list of packages that were/are scheduled to be removed.
That way I can at least then I can begin the cull (of un-wanted packages) again.
This is where the "--no-suggests" may be handy with the apt command. (edited for clarity, GW)
Sounds like this might be workable, but I was really reluctant to try working from an install usb/CDROM repo once "network-manager" was purged. And the
apt install lightdm slim-
tip worked very nicely indeed.
So, thanks to all the tipsters
Thanks Camtaf, HoaS MiyoLinux
After a brief skim, some comments escape me:
So Many Words, some of which I definitely recognise:
--> "there's a fair bit of reading I've got to get through"
--> "aptitude is awesome,"
That thread is from 2013 - Can I just replace "aptitude" with "apt" in the suggestions? I have not used apt-get much, and it has been a few years since "aptitude" was prised from my reluctant fingers.
Could I, in theory. purge "slim", let the uninstalls decimate my packagerie, then install lightdm and most of the packages would return, bringing in some new ones? ("theoretically", because one of those packages is "network-manager")
OK, swooping felly:
sudo apt install lightdm slim-
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
libck-connector0
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
gnome-accessibility-themes gnome-themes-extra gnome-themes-extra-data gtk2-engines-pixbuf
liblightdm-gobject-1-0 lightdm-gtk-greeter
Suggested packages:
accountsservice xserver-xephyr
The following packages will be REMOVED:
slim
The following NEW packages will be installed:
gnome-accessibility-themes gnome-themes-extra gnome-themes-extra-data gtk2-engines-pixbuf
liblightdm-gobject-1-0 lightdm lightdm-gtk-greeter
0 upgraded, 7 newly installed, 1 to remove and 0 not upgraded.
Need to get 4,392 kB of archives.
After this operation, 9,588 kB of additional disk space will be used.
Do you want to continue? [Y/n]
OK, this bit looks interesting:
dpkg: slim: dependency problems, but removing anyway as you requested:
task-xfce-desktop depends on slim | lightdm; however:
Package slim is to be removed.
Package lightdm is not configured yet.
I am hopeful - will find out after the reboot.
Hi all
I recently installed Chimaera with runit & XFCE using "devuan_chimaera_4.0.0_amd64_desktop.iso" , dated 2021-10-12. It seems to be working OK.
I wanted to be able to switch users, so tried to purge Slim and install Lightdm.
The attempt to purge slim seems to want to remove quite a lot of the system
$ sudo apt -s purge slim
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5 coinor-libcoinutils3v5
coinor-libosi1v5 cups-pk-helper dnsmasq-base exfalso fonts-font-awesome fonts-lato
fonts-opensymbol gimp-data gir1.2-atspi-2.0 gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0
gir1.2-gtksource-3.0 gir1.2-javascriptcoregtk-4.0 gir1.2-keybinder-3.0 gir1.2-notify-0.7
gir1.2-packagekitglib-1.0 gir1.2-polkit-1.0 gir1.2-secret-1 gir1.2-soup-2.4 gir1.2-webkit2-4.0
gir1.2-wnck-3.0 gnome-keyring gnome-keyring-pkcs11 gstreamer1.0-gtk3 gstreamer1.0-pulseaudio
hyphen-en-us iptables javascript-common libabw-0.1-1 libamd2 libao-common libao4 libappstream4
libatk-adaptor libaudio2 libayatana-appindicator3-1 libayatana-ido3-0.4-0
libayatana-indicator3-7 libbabl-0.1-0 libbluetooth3 libboost-filesystem1.74.0
libboost-iostreams1.74.0 libboost-locale1.74.0 libboost-thread1.74.0 libbrlapi0.8 libcamd2
libccolamd2 libcdr-0.1-1 libcholmod3 libck-connector0 libclucene-contribs1v5 libclucene-core1v5
libcmis-0.5-5v5 libcolamd2 libdotconf0 libe-book-0.1-1 libeot0 libepubgen-0.1-1 libetonyek-0.1-1
libexiv2-27 libexttextcat-2.0-0 libexttextcat-data libfreehand-0.1-1 libgegl-0.4-0
libgegl-common libgexiv2-2 libgimp2.0 libglib2.0-bin libgpgmepp6 libip4tc2 libip6tc2 libjim0.79
libjs-jquery libjs-sphinxdoc libjs-underscore libjuh-java libjurt-java liblangtag-common
liblangtag1 libldb2 liblibreoffice-java libmbim-glib4 libmbim-proxy libmetis5 libmhash2
libmm-glib0 libmspub-0.1-1 libmwaw-0.3-3 libmythes-1.2-0 libndp0 libneon27-gnutls
libnetfilter-conntrack3 libnfnetlink0 libnm0 libnma-common libnma0 libnumbertext-1.0-0
libnumbertext-data libodfgen-0.1-1 liborcus-0.16-0 liborcus-parser-0.16-0 libpackagekit-glib2-18
libpagemaker-0.0-0 libpam-gnome-keyring libqmi-glib5 libqmi-proxy libqrcodegencpp1 libqxp-0.0-0
libraptor2-0 librasqal3 libraw20 librdf0 libreoffice-base-core libreoffice-calc
libreoffice-common libreoffice-core libreoffice-draw libreoffice-gtk3 libreoffice-help-common
libreoffice-help-en-us libreoffice-impress libreoffice-math libreoffice-style-colibre
libreoffice-writer librevenge-0.0-0 libridl-java libsmbclient libspeechd2 libstaroffice-0.0-0
libstemmer0d libsuitesparseconfig5 libtalloc2 libteamdctl0 libtevent0 libumfpack5 libuno-cppu3
libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3
libunoloader-java libvisio-0.1-1 libwbclient0 libwpd-0.10-10 libwpg-0.3-3 libwps-0.4-4
libxmlsec1 libxmlsec1-nss libyajl2 libyaml-0-2 libzmf-0.0-0 lp-solve
mobile-broadband-provider-info modemmanager mythes-en-us network-manager network-manager-gnome
node-normalize.css orca p11-kit p11-kit-modules packagekit packagekit-tools perl-tk
python3-brlapi python3-cairo python3-cups python3-cupshelpers python3-dbus python3-feedparser
python3-gi-cairo python3-ldb python3-louis python3-musicbrainzngs python3-mutagen
python3-pyatspi python3-pyinotify python3-smbc python3-speechd python3-talloc python3-uno
python3-xdg quodlibet samba-libs sound-icons speech-dispatcher speech-dispatcher-audio-plugins
speech-dispatcher-espeak-ng sphinx-rtd-theme-common system-config-printer
system-config-printer-common system-config-printer-udev uno-libs-private ure usb-modeswitch
usb-modeswitch-data xbrlapi xkbset xsane xsane-common
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
slim* task-xfce-desktop*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Purg task-xfce-desktop [3.68+devuan4u1]
Purg slim [1.3.6-5.2+devuan1]
As an aside, this is probably the first time I noticed the "Purg" miss-spelling.
Anyway, are there spells and incantations to stop apt removing most of the desktop if I purge slim?
If it helps (do my sources look OK? I had to edit it after the install left it looking to the "cdrom"):
$ sudo apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://deb.devuan.org/merged chimaera-security/non-free amd64 Packages
release v=4.0,o=Devuan,a=stable-security,n=chimaera-security,l=Devuan-Security,c=non-free,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged chimaera-security/main amd64 Packages
release v=4.0,o=Devuan,a=stable-security,n=chimaera-security,l=Devuan-Security,c=main,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged chimaera-updates/main amd64 Packages
release v=4.0.0,o=Devuan,a=stable-updates,n=chimaera-updates,l=Devuan,c=main,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged chimaera/contrib amd64 Packages
release v=4.0,o=Devuan,a=stable,n=chimaera,l=Devuan,c=contrib,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged chimaera/non-free amd64 Packages
release v=4.0,o=Devuan,a=stable,n=chimaera,l=Devuan,c=non-free,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged chimaera/main amd64 Packages
release v=4.0,o=Devuan,a=stable,n=chimaera,l=Devuan,c=main,b=amd64
origin deb.devuan.org
Pinned packages:
There are no pinned packages.
Perhaps I could just disable slim and install lightdm, but that seems a little less than elegant?
Hope you can help - Thanks in anticipation.
findmnt
Slightly off-topic, but: Wow...How did I go so many years without knowing about this cool tool? Thanks.
Very simple: firefox-esr is not a genuine Devuan package, it is a Debian inheritance.
I am not sure how the Debianness of the inheritance gets in the way of Devuan informing its users that the default browser is no longer supported, so they can make alternate, suitably informed plans?
In my limited and dimly-recalled experience of informing users of problems and issues, the task is a LOT easier if there is someone else (Firefox? Debian?) to blame. (Of course, that's probably not something I would have said out loud at the time )
Come to think of it - is this an issue with Chromium as well?
Plead your case to Debian. Not going to happen at Devuan.
I should plead with Debian to post an alert on the Devuan forum, so Devuan users know that the default Devuan browser is no longer supported, and they need to make alternative plans if they want to use a supported browser?
I wonder if we could have some input from Devuan's Powers That Be on this subject? It seems Debian and therefore Devuan can no longer supply a supported Firefox, and users who wish to keep up-to-date must make their own plans? This might well be the sort of thing the "News and Announcements" section of the forum was designed for.
I have encountered a rumour https://endoflife.date/firefox that the Firefox (firefox-esr: 78.15.0esr-1~deb11u1) installed in my Chimaera rig (Actually installed from a beta "amd64 - desktop 20210906" iso) is no longer supported. Is this true? Does Firefox have an End Of Life page to keep users informed?
It does seem to be mentioned in release notes for subsequent versions, which is probably useful if you read release notes for versions that you don't use.
If it is true, will I automagically get an updated version with an apt full-upgrade "real soon now" or do I have to do some (shudder) work to make it happen? Is there somewhere that I can go to read up about developments, options, etc ?
I can't see an official announcement on this forum, so I hope I can use puma's thread to offer congratulations and thanks to the team.
OK, thanks for the tips.
I checked my arping's friendly man page again (from which the above code snippet was taken), it definitely mentions the -d parm. The command accepts the -d without complaint. Of course, I have no idea if it does anything with it. I hope I have not messed up my sources.list.
cat /etc/issue;sudo apt show arping
Devuan GNU/Linux 4 \n \l
Package: arping
Version: 2.21-2
Priority: optional
Section: net
Maintainer: Salvatore Bonaccorso <carnil@debian.org>
Installed-Size: 78.8 kB
Depends: libc6 (>= 2.25), libnet1 (>= 1.1.2.1), libpcap0.8 (>= 1.5.1)
Conflicts: iputils-arping
Homepage: http://www.habets.pp.se/synscan/programs.php?prog=arping
Tag: admin::monitoring, implemented-in::c, interface::commandline,
network::scanner, protocol::ip, role::program, scope::utility
Download-Size: 31.6 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.devuan.org/merged chimaera/main amd64 Packages
Description: sends IP and/or ARP pings (to the MAC address)
The arping utility sends ARP and/or ICMP requests to the specified host
and displays the replies. The host may be specified by its hostname,
its IP address, or its MAC address.
ip a ip r
Would I have to enter these commands on every machine in the network, including the ones I have forgotten about, and the ones without shells?
I admit, it would be effective if I remembered them all, but somewhat inconvenient.
How about "arping -c 10 -d <ipaddress>" ? I just read about it now and the man says:
-d Find duplicate replies. Exit with 1 if there are answers from
two different MAC addresses.
That looks very promising - is it solid and reliable?
How about sudo nmap -sn <network> ?
Maybe I will test these if I need to continue my investigating. I could put the phone back, and see if they sniff it out.
Of course, due to PEBKAC I only thought of dupips when I noticed the (forgotten by me) persistent address on my phone. I mean, what kind of sick, twisted mind gives a phone a static IP?
Thanks for the r8168 tip, I hope I will not have to investigate it further, but it's "good to know"
So...might have found something. My cellphone (which has Kodi installed and sometimes does media server/player duties) had a static IP which is the same as the the static IP I chose for my PC !
The cellphone has been moved to a new address. Now, on my PC, I am trying to use static that has been set up with NetworkManager. Results are promising, but it's an intermittent error, so it's quite difficult to confirm its absence. (Maybe the phone sleeps a lot, and causes fewer problems while asleep? A bit like me, really)
Last month, during the course of my investigation of this intermittent issue, I moved my network from a non-RFC1918-approved network prefix to an RFC1918-approved one. At the same time, I moved my main PC from a static ip that I have used for over a year, to one which conflicted with the phone. The has now been rectified, but I still have no explanation for the same issue which existed with the old address, with which there was no conflict. Maybe I can blame NetworkManager for fighting with the /etc/network/interfaces configuration?
I this works out, I will have to apologise to a lot of old freebie&junkshop cables and hubs/routers.
Is there a simple network diagnostic tool which can easily sniff out ip address duplication? Ping seems to offer a hint, but it's not very good at explaining the problem.
I realise I did not include the actual "error" rmessage, for when I forget about this in a few months time:
.......ping statistics ---
100 packets transmitted, 67 received, 33% packet loss, time 160343ms
rtt min/avg/max/mdev = 170.934/172.424/180.124/1.268 ms
Perhaps of interest: If I remove eth0 from /etc/network/interfaces, give it to NetworkManager to manage via DHCP, and assign a static IP by reserving it in the router - that *seems* to work fine. That's a rather embarrassing admission of failure, though. And easily forgotten as I cycle through my collection of junkshop routers as old age, lightning strikes and power surges cause them to shuffle off this mortal coil. And inconvenient if I have to reconfigure BOINC, ssh, hosts.allow and shares.
I hope it won't come to that?
Greetings, Dev-Ones
I installed Chimaera 64 bit with runit and SLiM, and added a static IP address for eth0 to /etc/network/interfaces. SliM was later swapped out in favour of lightdm. Eth0 seems to be a "Realtek RTL8111/8168/8411" device with driver "r8169"
My /etc/apt/sources.list starts with
# deb cdrom:[Devuan GNU/Linux 4.0 chimaera amd64 - desktop 20210906]/ chimaera contrib main non-free
so I assume that's the vintage of the beta that was installed.
I noticed occasional errors while webbrowsing "Hmm. We’re having trouble finding that site....We can’t connect to the server" etc
I tried a few pings, and noticed the occasional dropped packet. But pings are like salted snacks, you can't have just one.
To remove the uncertainty associated with pinging unreliable, fly-by-night organisations on the Web (e.g. Facebook) I ping my ADSL router/gateway/DHCP server device by IP number.
Eventually, I noticed that if I use DHCP to assign an address, the percentage of dropped packets is usually 0, never over 1. However, with a static
IP assigned in /etc/network/interfaces, the dropped packets percentage is very often between 5 and 50.
I then removed the static eth0 address from /etc/network/interfaces, and tried to assign the static IP using NetworkManager. The dropping of packets continued.
The issue seems to be that something about static IP (OK, my setup of static IP) makes networking unreliable (not broken, just 5-50% unreliable). This seems consistent whether eth0 is managed by NetworkManager or /etc/network/interfaces
Has anyone else noticed anything like this? In particular...has anyone solved this with one simple trick? It will have to be simple.
Maybe someone can point me to a foolproof, painstakingly detailed and yet laughably simple guide for assigning static IP via NetworkManager?
Maybe I'm just holding it wrong.
Hi devadmin
I always feel personally insulted and "victim-blamed" by this question, but now I find myself asking it:
1) Can you confirm that the image you wrote to your flashdrive, passes the checksum test?
2) Can you perhaps try another flashdrive? Maybe you were just unlucky.
These checks usually have little cost (unless, for example, you have to buy another flashdrive) , and they *could* save quite a bit of pain.
I have the idea that the install beta isos have been getting refreshed early in the week for a few weeks now....so there might be a "20210927" edition soon?
It might also be useful to know more about the computer? Perhaps it just hates Chimaera.
A question for Devuan helpers: Is there a system "discovery" tool like inxi on the install or live media?
Good luck!
OK, thanks for the responses. I do believe my question is answered. Will try to replace SLiM with lightdm.
I think you may be right that it changes desktops. I'm a little hazy lately and should stop trying to answer questions as I'm batting zero today.
Thanks for your attention, anyway. I hope the "Get Well Soon" option is selectable for you.
On the slim panel there is a note to Press F1 to select sessions. Did that not work?
When I press F1 at the slim panel, the words "Session: Xfce Session" appears on the slim panel. This does not seem to do anything in my case. I have the idea from several years ago that this was meant to switch between different desktops, if one had them installed (Xfce, ICEWM, etc), but the memory is hazy.
Furthermore, I have the idea that I would only see the slim panel if I was logged out? I know I can switch users by logging out, and then logging back in as the other user, but I would prefer to avoid logging the original user out (in case it is doing something that I would prefer to not interrupt)
Advice and suggestions are welcome, so thanks for that. I am also looking for information, so that I (and perhaps future generations) can make an informed decision. Is the "Switch Users" option simply unavailable to SLiM users?
I imagine it's one of those features which are 'bloat' to some, and very useful to others.
Regarding the result from the search, in what way is it misleading? It *seems* to be telling me that, if I want dm-tools, I need to install lightdm. So, it appears to agree with your suggestion.
Hi All
Chimaera (64-bit,runit) seems to be working out quite nicely, despite beta status, but there are one or 2 niggles - perhaps I am missing something?
I notice the Switch Users option seems to be greyed out (or grayed out) in the Action Buttons area of my panel. I read somewhere on the Internet (so it must be true) that SLiM does not actually offer User Switching. I would really like to be able to easily switch between graphical desktops as my partner and I use the same PC with different usernames. What options are there?
It seems I can use CTRL+ALT+Fx to get to another tty, logon there as a different user, and invoke "startx". This brings up the desktop of the newly-logged-in user. It feels a bit hacky, but that's not too abysmal. Are there any possible pitfalls to using this method in day-to-day sharing-is-caring computer operations?
In a previous life with another distro, and presumably another display manager, I was able to access both a "Switch Users" button, and also to use the "Action Buttons" / "Lock Screen" function which gave me a "New Login" button. This would then allow the other user to enter their credentials. However, in my current dispensation, this gives me the disappointing message
xscreensaver: <time> could not execute "dm-tool": no such file or directory
I assume this below is apt telling me that dm-tool is part of lightdm? (If so, that's a nice feature of apt.)
apt search dm-tool
Sorting... Done
Full Text Search... Done
lightdm/testing 1.26.0-7+devuan3 amd64
simple display manager
Is there an equivalent available for SLiM?
I am not sure if this is relevant, especially in your case, but:
In the old days, it was suggested to me that, if one intended to use the "hibernate" a.k.a. "suspend-to-disk" function, one needed a slightly more swap than RAM. In your case, that would imply at least 16Gb of swap.
However, https://wiki.archlinux.org/title/Power_ … /file_size in the section "About_swap_partition/file_size" seems to say:
"Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully
.
.
You may either decrease the value of /sys/power/image_size to make the suspend image as small as possible (for small swap partitions)"
Thanks to all who replied.
It seems that what I was specifically interested, i.e. sharing a logical volume between linux instances in a multi-boot arrangement in exactly the same way as a normal partition, hopping between instances as the mood or need dictates, is something that our community here has no experience of.
@fsmithred and @rolfie, you seem to be describing doing it once or twice and getting away with it, without catastrophe.
That is encouraging, so thanks for that. However, I would also have been interested to hear from people who do it regularly, as part of their standard operating procedure, but it seems that we don't do that sort of thing here.
It could be that the idea is so ridiculous that it is not discussed, or is so commonplace that it is quite unremarkable.
If I ever get around to the experiment, I should probably start off with data I to which I am not too attached.
Well, thanks for the feedback so far. However, I am not really hearing anyone saying that they have actually done this sharing with a logical volume. Nor am I hearing people assuring me that "It's at least as safe as sharing a normal partition, everybody does it, without a second thought" or "We do it a lot, never had any problems"
Can anyone help with that?