You are not logged in.
Nothing is ever that easy
It seems to think it is a member of a raid array, is/was it? Try mount -t ext4 /dev/sdb1 /mnt to tell it the filesystem to use when mounting the device partition and the output of the fdisk -l /dev/sdb would be nice to see as well if it continues to insist it cannot mount it.
Edit: Apparently answered my raid question while posting my reply, you need all of the devices in an array present to be able to use it, I think anyways never used it in my life so cannot be certain.
The file system type is set as ext4.
Which are the vfat options that you are referring to?
It would be these the type is separate from them, anything after the defaults are options passed to the file system on mount. Oh and BTW defaults already gives you rw option the extras were screwing it up.
,nosuid,nodev,relatime,data=ordered
The arch wiki shows those used with a vfat file system, there is one ,user used in an example for ext4 all the rest have nothing but defaults..
Adding the rw option after defaults appears to have it fixed it but is that the correct way to do it?
If I had allowed the installation process to format things, how would have fstab have been configured?
The correct way would have been to allow the system to do it then correct for problems if any were encountered. With the system doing it you would have had nothing but defaults for the options with an ext4 system not the vfat options now set on it you have done. And correct file system checking enabled with the pass number being set to 2. This is the second 0 you have set now so your filesystem will never be checked for errors. That part of the line should be defaults 0 2. The mount point (LinuxDataExt-4TB) should be owned by the user to prevent file/directory creation problems. Oh and check the root line to make certain the last number is the 1 it is supposed to be.
but now beginning to think that the sound maybe too thin on Desktop aswell;
hope to get better experience with a dedicated Soundcard ; altough it seems , Creative does not (provide driver)(support)( Linux?
it should still get better soundstage?
or should i use an USB DAC?`
Mostly none of them places provide the support for linux drivers, there are exceptions where they will have someone doing it. But for the most part it is some person not associated with the company or product doing the driver support. Sound can be a problem especially the onboard I have found it to be mostly junk. I used a firewire card for a time connected to a FireWave sound device it worked flawlessly. Now I use the below to get my 5.1 sound it works great but I see the scumbags have more than doubled the price in the just over year since I bought it. If searching around for others you want a CM106 based device as that is what it reports as to the system.
My wired ethernet connection functions, but there is no NetworkManager directory, and no .conf file
Yes it will function if something like dhcpcd is installed to bring up the connection. Just that the network manager in KDE will show you nothing about the connection without it doing the management of it. For the other problems I would say the runit is more trouble to get going, the sysvinit works perfectly.
Although xbindkeys and xdotool are installed on my Daily Driver, there wasn't any .xbindkeysrc in my Home directory. sad
Is there any other directory where such a configuration file exists?
You are supposed to create it in your ~ directory though like most of these things. I would imagine the option exists to start the program specifying another location for the config file passed as option at startup. The reference file for it lives at the /usr/share/doc/xbindkeys/examples/xbindkeysrc copy that to your ~/.xbindkeysrc then edit for your changes.
alias afl='apt-file list'
root@9600k:~# afl xbindkeys
xbindkeys: /etc/xdg/autostart/xbindkeys.desktop
xbindkeys: /usr/bin/xbindkeys
xbindkeys: /usr/bin/xbindkeys_autostart
xbindkeys: /usr/bin/xbindkeys_show
xbindkeys: /usr/share/doc/xbindkeys/BUGS
xbindkeys: /usr/share/doc/xbindkeys/NEWS.Debian.gz
xbindkeys: /usr/share/doc/xbindkeys/NEWS.gz
xbindkeys: /usr/share/doc/xbindkeys/README.Debian
xbindkeys: /usr/share/doc/xbindkeys/README.gz
xbindkeys: /usr/share/doc/xbindkeys/TODO
xbindkeys: /usr/share/doc/xbindkeys/changelog.Debian.gz
xbindkeys: /usr/share/doc/xbindkeys/changelog.gz
xbindkeys: /usr/share/doc/xbindkeys/copyright
xbindkeys: /usr/share/doc/xbindkeys/examples/xbindkeysrc
xbindkeys: /usr/share/doc/xbindkeys/examples/xbindkeysrc-combo.scm
xbindkeys: /usr/share/doc/xbindkeys/examples/xbindkeysrc.scm
xbindkeys: /usr/share/doc/xbindkeys/examples/xbindkeysrc1
xbindkeys: /usr/share/doc/xbindkeys/examples/xbindkeysrc2
xbindkeys: /usr/share/man/man1/xbindkeys.1.gz
xbindkeys: /usr/share/man/man1/xbindkeys_autostart.1.gz
xbindkeys: /usr/share/man/man1/xbindkeys_show.1.gz
xbindkeys: /usr/share/menu/xbindkeys
Edit: The script I use in the KDE autostart system setting to start it up on login.
zeus@9600k:~$ cat bin/xbindkeys.sh
#!/bin/bash
# enable it on login if xbindkeys is installed.
if [ -f "/usr/bin/xbindkeys" ]; then
xbindkeys
fi
First boot pauses at “Starting network connection manager: NetworkManager.”
so my working hypothesis is that NetworkManager isn't getting loaded. While I assume that NetworkManager is still SysV, I have no idea how to solve this on a hybrid runit system.
With the networking being setup using the /etc/network/interfaces file in Devuan you need to tell
NetworkManager to manage the network using that method, it expects the systemd garbage.
From my install notes.
root@9600k:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The first card in the system added for devuan method of networking
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
zeus@9600k:~# nmcli dev status
DEVICE TYPE STATE CONNECTION
lo loopback connected (externally) lo
eth0 ethernet unmanaged --
root@9600k:~# cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
root@9600k:~# nano /etc/NetworkManager/NetworkManager.conf
root@9600k:~# cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=true
root@9600k:~# service network-manager restart
Stopping network connection manager: NetworkManager.
Starting network connection manager: NetworkManager.
root@8400:~# nmcli dev status
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected (externally) eth0
lo loopback connected (externally) lo
It doesn't install correctly in MX neither, see post #33.
Damn missed that way to early in the morning to be replying.
If Devuan created a Brightness Adjustment Applet using xrandr, that would solve the problem.
Using xrandr --output LVDS --brightness 0.5 for example reduces the brightness by half.
Perfect time to scratch your own itch as the saying goes in Linux. Create a file with these contents.
#!/bin/bash
# A script to halve the brightness of the display
xrandr --output LVDS --brightness 0.5
Make it executable.
chmod +x /path/to/brightness.sh
Put it in your home bin directory if you use one or /usr/local/bin so it will be in the PATH then
brightness.sh used in a shell will execute the command. If using xbindkeys and xdotool you should be able to map it to a key shortcut to just have it done with that shortcut. Or perhaps a .desktop file can be made to run the command via a click on its icon. Just a couple of ways of doing it and as I say scratching your own itch. I have dozens of little scripts I run all the time from my cloning/backup one that will clone or backup my running system to media conversion, file copying to other machines, the list is endless.
Would that have been done by the use of modprobe?
It is responsible for loading the module for use by the installed programs. Looks like there is some bug in the Devuan then if it installs and works fine in the MX. Both do not use the systemd garbage so have that in common but apparently not enough for the same package to work on both OSs.
Edit: Now there is thought now I think of it, does the package from Devuan install without errors on the MX or the other way around will the MX install on the Devuan. If they both use the same libraries/dependencies they should be interchangeable.
The output of the lsmod would be different with your machine as it actually has the hardware needed/used by the module. The output for the rc?.d leftovers is because the --purge option was not used when removing the package so left behind the configuration files. The package left in the archives folder is normal until the apt clean or apt autoclean commands are run to clear the cache one clears the entire cache the second leaves packages that are still available in the archives in the cache. You want to do the sudo apt autoremove to get rid of the packages not needed anymore to clean the excess junk off the system. I really have no idea if you want to try it again from the start and see if the package will actually install without error with the module loaded before starting the install. If you do at least you now know how to remove the thing if it fails once more.
Try the sudo rm /etc/init.d/fnfxd to remove the test for it being positive and allowing the removal without the update-rc.d being called to try and stop it. That package is junk there is no way it should fail trying to set the run level like it is doing here.
Couple of points you are not patching the kernel, you are passing it a boot option through grub. If you patch a kernel, a re-compile then installation of new version is necessary where you boot with the patched to see the changes. For the grub there is no need to make a new file the update-grub command run as root or normal user using sudo at the front of it will have the option used in the grub.cfg upon the next boot. And now I look at that part again you do not mention you need to reboot for that change to take place setting the option and having the grub file updated does nothing to have it used, only booting the kernel with the updated/new file has it take effect. Other than those items a reasonable effort at it.
I didn't install from a .deb file. fnfxd is in the Devuan repositories. Latest version is 0.3-18. The executable (fnfxd) in sbin has a modified date of 2023-02-14.
The fnfxd_0.3-18_i386.deb file in /var/cache/apt/archives has a Modified Date of 2023-02-15.
Given invoke-rc.d: initscript fnfxd, action "start" failed. during installation, do we need to be looking in the init area somewhere?
Does not show up here but I am running 64bit system and it is 32bit plus one version on the testing or excalibur the new stable to come in few months. The apt remove fnfxd or dpkg -r /var/cache/apt/archives/fnfxd_0.3-18_i386.deb should remove it. Using of course the sudo command in front to get root permissions if you do not have root user setup. Yes the init area is it looking carefully at the scripts that are run in the post install as this is where they likely fail. You can extract the file and start looking at them to see if you can find the spot where it fails.
Do I use apt or dpkg to remove it?
The one you used to install but either should work. You say the graphical tool says it is marked for removal you could let it do it as well. Now there is one for me to ask about where is the link to the . deb you use? I see nothing like that on the page I just linked too.
Let it remove it make certain the toshiba_acpi is loaded then try again. If it does the same thing the package is broken and will not install on a system more than 9 years after the last update of it.
After closing the Changes applied window, fnfxd is still marked with an icon indicating "Marked for complete removal".
Forget the stupid graphics tools they are useless junk for solving problems they only work when there are no problems. Open a terminal and sudo dpkg --configure -a to see if it is going to allow you to configure the broken package.
Edit did some reading on the package I downloaded here.
https://sourceforge.net/projects/fnfx/
The last update of 2015 is not a good sign but it appears it could be possible to get the required support file.
root@9600k:~# file /home/zeus/Downloads/usr/bin/fnfx
/home/zeus/Downloads/usr/bin/fnfx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.0.0, stripped
root@9600k:~# file /home/zeus/Downloads/usr/sbin/fnfxd
/home/zeus/Downloads/usr/sbin/fnfxd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.0.0, stripped
The /lib/ld-linux.so.2 by installing the having the i386 libc6 installed. I am rapidly running out of ideas on this one.
I used find -name *modprobe* | grep modprobe as apt-file was not installed.
Using sudo /sbin/modprobe toshiba_acpi produced no output.
The apt-file is never installed by default but is a wonderful little tool for finding the package containing the file needed. When using modprobe the only time it produces output is when the module is not there to load. You use the lsmod command to see if it loaded, rmmod will remove loaded module.
root@9600k:~# lsmod |grep toshiba_acpi
root@9600k:~# modprobe toshiba_acp
modprobe: FATAL: Module toshiba_acp not found in directory /lib/modules/6.12.8-amd64
root@9600k:~# modprobe toshiba_acpi
root@9600k:~# lsmod |grep toshiba_acpi
toshiba_acpi 73728 0
sparse_keymap 12288 1 toshiba_acpi
battery 28672 1 toshiba_acpi
industrialio 139264 1 toshiba_acpi
rfkill 40960 6 toshiba_acpi,bluetooth
video 81920 2 toshiba_acpi,i915
wmi 28672 4 video,toshiba_acpi,gigabyte_wmi,wmi_bmof
root@9600k:~# rmmod toshiba_acpi
root@9600k:~# lsmod |grep toshiba_acpi
Have you tried the install again with the module loaded?
Edit: while I think of it an article on making sure the module loads on boot.
$ modprobe toshiba_acpi produced the following output:
bash: modprobe: command not found
$ sudo modprobe toshiba_acpi produced nothing.
Debian and their BS breaking things changes strikes again.
root@9600k:~# apt-file search modprobe | grep bin
discover: /usr/sbin/discover-modprobe
kmod: /usr/sbin/modprobe
From my /root/.bashrc so I do not run into that BS.
# set PATH so it includes /sbin if running distro without it in the PATH like Debian Buster.
needpath=$(which fdisk)
if [ -z $needpath ] ; then
PATH="/sbin:$PATH"
fi
Use the full path sudo /usr/sbin/modprobe toshiba_acpi.
Edit: Now I noticed you may want to run apt autoremove to get rid of that extra kernel and stop ignoring apt when it tells you to do this every time there is a package(s) to remove that is not needed anymore.
The CONFIG_ACPI_TOSHIBA=m should be the one. The m means that it is module, the y it is built into the kernel no need to load it with modprobe, n means no not built at all. Use modprobe toshiba_acpi it appears to be named as.
root@9600k:~# locate toshiba
/usr/lib/modules/6.12.8-amd64/kernel/drivers/platform/x86/toshiba-wmi.ko.xz
/usr/lib/modules/6.12.8-amd64/kernel/drivers/platform/x86/toshiba_acpi.ko.xz
/usr/lib/modules/6.12.8-amd64/kernel/drivers/platform/x86/toshiba_bluetooth.ko.xz
/usr/lib/modules/6.12.8-amd64/kernel/drivers/platform/x86/toshiba_haps.ko.xz
fatal error: Could not open /proc/acpi/toshiba/keys.
Please make sure that your kernel has enabled the Toshiba option in the ACPI section.
Check your kernel to see if it indeed has that support enabled and modprobe the module before starting the install again.
zeus@9600k:~/Downloads$ grep -i toshiba /boot/config-6.12.8-amd64
CONFIG_YENTA_TOSHIBA=y
CONFIG_PATA_TOSHIBA=m
CONFIG_MMC_TOSHIBA_PCI=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_TOSHIBA_BT_RFKILL=m
CONFIG_TOSHIBA_HAPS=m
CONFIG_TOSHIBA_WMI=m
The CONFIG_ACPI_TOSHIBA=m seems the likely candidate needed. Check your running kernel config for it being enabled there.
Hooray for progress! Linux (without the GNU, because we shouldn't scare away newbies) is finally letting go of stability and embracing on-demand updates
Yes they truly have gone downhill in that regards, though it is not the first time they have dropped an arch. With mostly the same reaction seen here every time as it happens. Same with the systemd garbage they foist onto their users forgetting the one tool for every action keep it simple *nix philosophy. While it expands ever more into every god damn part of the system with each release. So the Microsoft plants in Linux can slowly gain more control over ever f'n thing done on those systems. They don't even hide the agenda anymore and Debian still goes along with it. Here in a couple of days it will be four months (according to the Ubuntu changelog for the fix) since they ship a broken KDE that will not connect to a samba share at all. Despite the fix being in Ubuntu for all of those months and all it is, is a simple re-compile of the Ubuntu packages to fix it as they are binary compatible now that will install and work on a Debian based system. Having seen it in the past I have no doubt that they will ship those packages in that same broken state with Trixie when it goes out the door..
https://www.devuan.org/os/documentation … o-daedalus
Is the link to it, the procedure is fairly simple.
i was not clear enough. i loop-mounted the iso file not the USB drive.
in an error about not being able to mount /cdrom.
my next idea is to disassemble the machine, extract the nvme drive,
Ah I was wondering if you had done the copy the iso to the install drive many do and you did not. That is same error I got when trying to use the installer. Save yourself the wasted time and effort use an installer that works a Debian one. Then convert the install to Devuan using the instructions they give for doing it that work perfectly fine when starting with that as a base to get it on the box. There are very few changes made from a stock Debian to this operating system. The main one being removing the systemd infestation from it and installing sysvinit.
i loop-mounted the iso and all the EFI bits appear to be there, so i must be doing something wrong.
to get around this problem, i copied the netinstall iso to a ventoy USB drive and booted netinstall
from there.just curious if anyone knows what is going on with UEFI boot? is it a 7700X thing?
If you loop mounted the iso from on the USB drive then you did it wrong when making the install USB with dd. There is nothing wrong with your booting UEFI as if there was the ventoy drive would have had the same problem booting when using it as UEFI selected from your boot menu.
So, in which of the Base Files should I be looking to see the difference? There was no difference in os-release.
You would download the both and compare the files. All that matters is the system thought there was a change and displayed the normal message for that change. You see it every time the . release updates go from the 12.7 to 12.8 for instance you get to see it. Now I scroll back the old version last update was in July of 2023 definitely a few version . changes in that period of time thus the reason for the message being displayed.