Posts by msi

msi · Installation

https://devuan.org
https://devuan.org/os/

msi · Hardware & System Configuration

Since I have upgraded from Jessie to ASCII, I'm getting the following warning about NTP on shutdown, which is apparently somehow connected to network device configuration:

DHCPRELEASE on wlan0 to 192.168.178.1 port 67
invoke-rc.d: -----------------------------------------------------
invoke-rc.d: WARNING: 'invoke-rc.d ntp try-restart' called
invoke-rc.d: during shutdown sequence.
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: -----------------------------------------------------
done

I hadn't heard of invoke-rc.d before, so I looked it up. The manual page says it's "a generic interface to execute System V style init script /etc/init.d/name actions" and that "all access to the init scripts by Debian packages' maintainer scripts should be done through invoke-rc.d".

I had initially tried to solve the problem by editing /etc/init.d/ntp. But that doesn't seem right, so I restored the original file from backup.

How can I find out now what is calling invoke-rc.d ntp try-restart during shutdown and why?

As for this issue being connected to the network device settings, I've found the following: When I use auto wlan0 instead of allow-hotplug wlan0 in /etc/network/interfaces (where I do all my network configuration), I'll get this during boot:

DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
DHCPREQUEST of 192.168.178.21 on wlan0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.178.21 from 192.168.178.1
DHCPACK of 192.168.178.21 from 192.168.178.1
invoke-rc.d: could not determine current runlevel
bound to 192.168.178.21 -- renewal in 400249 seconds.

First, these messages are not shown when using the allow-hotplug configuration. In that case, all that is shown of the network device configuration during boot is:

Configuring network interfaces...ifup: waiting for lock on /run/network/ifstate.wlan0
ifup: interface wlan0 already configured

Second, there's an error message in there. And even though I understand what it says, I have no clue what to do about that.

The warning message displayed on shutdown is the same in both cases.

Any ideas?

msi · Installation

golinux wrote:

msi wrote:
Btw, it's a good idea to use code tags when posting config files. That makes it more readable.
Done (for the second time).

Looks like something to mention in a forum code of conduct to be.

msi · Installation

Ok, I see. First, I'd try setting sources.list back to Jessie and then run apt-get update and apt-get upgrade. If that goes well, I'd reboot and see how that goes.

Btw, it's a good idea to use code tags when posting config files. That makes it more readable.

msi · Installation

erdos wrote:

i've run into this error when i tried to upgrade from devuan jessice to ascii a couple months ago (March 24th):

root@debian:/home/erdos# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these. 
The following packages have unmet dependencies: 
initscripts : Depends: sysv-rc or file-rc but it is not installable libncurses5 
: Depends: libtinfo5 (= 5.9+20140913-1+b1) but 6.0+20161126-1+deb9u1 is installed sysvinit-core 
: Depends: sysv-rc or file-rc but it is not installable sysvinit-utils 
: Depends: init-system-helpers (>= 1.25~) but 1.24+devuan1.0 is installed E: Unmet dependencies. Try using -f.

after reboot the system, i can only log into command line, but my home directory is not mounted, wifi is not working.

With that kind of error messages occuring, apt-get should refuse to perform any dist-upgrade, which it seemingly did in your case. So, unless you did not "try using -f" or anything else in that direction and also changed back your sources.list to Jessie and ran apt-get update after that, your system should actually be fine. So, did you try any other commands to make the upgrade happen or forget to revert your apt sources to Jessie?

What does /etc/apt/sources.list look like on that system?

msi · Off-topic

In case you haven't noticed, Microsoft is going to buy GitHub.

Here are the official statements:

msi · Devuan Derivatives

Ron wrote:

I am wondering if any of the window managers that Miyo comes with (Openbox, i3, and now Awesome) allow individual folders to be set to different views.

Window managers don't have anything to do with this, file managers do.

Ron wrote:

Here's what I mean: I prefer most of my folders to be set at compact view, except all of my folders that contain videos and pictures. I prefer these folders to be set at icon view. Mate allows this, and this is one of the reasons I started using Mate shortly after I moved away from Windows to Linux. I had tried Xfce before Mate, but it didn't allow individual folders to have different views; the folder view setting was system-wide (unless I just couldn't figure it out).

This can indeed be done in PCManFM. I just tested it. When you are inside a folder, you can change the view and then tell PCManFM to remember the view configuration you've set for that folder. SpaceFM apprently doesn't have that feature. You could, however, put a feature request on the issue tracker at https://github.com/IgnorantGuru/spacefm. (I hereby encourage you to do that.)

On a side note, if the folder view configuration you set up in your file manager is applied system-wide, something's wrong. These customizations are intentionally user-specific as you will surely come to see when you create another user account, log in, open the file manager and find that none of them apply.

msi · Hardware & System Configuration

Caluser2000 wrote:

After further digging found the solution at https://www.pclinuxos.com/forum/index.p … c=106099.0
Copied "/dev/fd0 /media/floppy auto umask=0,users,iocharset=utf8,noauto,flush,exec 0 0" to the fstab and it works as it should. An floppy icon even shows up on my desktop when mounted.

I'd be careful with simply copying such a configuration onto my system. If you haven't done it already, you best have a look at the manual pages of fstab and mount to really understand what that line does. For example, you probably want to put user instead of users, because, as the manual page of mount explains:

Only the user that mounted a filesystem can unmount it again.  If any user
should be able to unmount it, then use 'users' instead of 'user' in the fstab line.
The 'owner' option is similar to the 'user' option, with the restriction that the
user must be the owner of the special file.  This may be useful e.g. for
/dev/fd if a login script makes the console user owner of this device.  The
'group' option is similar, with the restriction that the user must be member of
the group of the special file.

msi · Devuan

MiyoLinux wrote:

...and the winner is?

Thanks for that!

Btw, it's simply MSI, just like you'd pronounce BSD.

msi · Hardware & System Configuration

Caluser2000 wrote:

I've tried numerous times to change permissions/ownership but no go.

How exactly did you try to do that and what does the floppy drive entry in your /etc/fstab look like?

msi · Installation

oui wrote:

msi wrote:
On a general note, if a package is in Debian and doesn't depend on systemd, that same package will be in Devuan
does the reverse be true that if a package is not at the Devuan depository, then it depends on systemD and will not be available in binary? can it be compiled or is too difficult for a novice

As far as possible, packages that have systemd dependencies in Debian will be rebuilt without those dependencies by the Devuan developers. That's essentially what constitutes Devuan, technically. So, there should be no need for you to rebuild any of those packages.

oui wrote:

(choosewm does not seem to be at the jessie depot)

Why do you think that? Have you tried running the apt-cache command from my first post?

msi · Other Issues

gnufan wrote:

So I have two questions, firstly how do I reset my user password ?

Just run passwd – without sudo and a username. See man passwd for additional information.

gnufan wrote:

Secondly, how do I revert the following commands "mount -o remount,rw /" and then "chmod 640 /etc/shadow" so my system can return back to its original state ?

1. As far as I can see, running chmod 640 on /etc/shadow doesn't change anything because the file already has those permission settings by default. Btw, fiddling with the permission settings of system files belonging to root is risky and should only be done if you know what you're doing.

2. As for the mount command, a reboot should set you back to normal, since that command doesn't change anything in /etc/fstab.

gnufan wrote:

Thanks for working on this great distro, I have just changed from Ubuntu and I think it is great. :-)

Welcome to Devuan!

msi · Installation

Running

apt-cache search choosewm

will give you the answer.

On a general note, if a package is in Debian and doesn't depend on systemd, that same package will be in Devuan, because, for the most part, Devuan tracks Debian's package repositories. In short: Devuan is Debian without systemd.

msi · Devuan

mlsmith wrote:

It's interesting that your top bar and neofetch calculated slightly different uptime. Must be a rounding thing.

I think that's simply due to the delay between running neofetch and taking the screenshot.

msi · Devuan

Ok, that was hard. I had just fiddled with neofetch for about half an hour to get the configuration right when I switched to another TTY and my monitor turned black and the system completely froze, requiring a hard reboot (maybe because I forgot to delete ~/.bash_logout). But, finally, here's my desktop:

https://transfer.sh/EjlHl/msi-desktop-s … 180528.png

The image will be kept for 14 days and then vanish into oblivion. As far as the T-shirt goes, you can count me out (nice idea though). Thanks!

msi · Hardware & System Configuration

stroudmw wrote:

Clearly the desktop option installs some dependencies that are missing from the Openbox installation.

Just for the record: Those dependencies are not missing in the case of Openbox. Openbox is very much nothing but a window manager. It is not a desktop environment. So there is no need for it to depend on anything required to handle removable media as a non-privileged user.

msi · DIY

I usually don't use suspend, so I can't say. But I'd like to have a look at the source of your utility if you don't mind. Can you put it up on GitHub? I suppose it's either written in Bash or Python. I'm working on something similar (in Bash, currently).

msi · Installation

1. At which stage of the installation procedure exactly does it freeze? If I understand your description right, this happens after tasksel (the thing where you select software (not) to install, e.g., a desktop environment).

2. What do you mean by "freezing up"? Can you still abort the installation through the installer?

3. Are you using the i386 or the amd64 version?

4. What is your wireless hardware?

msi · DIY

After some more thinking, tinkering and reading around, I found a solution to this problem that's pretty workable. Let me get there step by step.

The idea was to somehow have the window manager's exit command invoked as independent from the currently running script but also put it on hold as long as that script is running. First, this implies that the hold action and the exit action need to be implemented as one command. Second, to run that command as independent from the current script, it has to be put in the background on invocation, which is done by appending an ampersand to the end of the line.

A very primitive and generally unreliable way to achieve this is using the sleep command and the && operator:

#!/bin/bash
#
# procman1

cmd_name=${0##*/}  # Get basename of the entered command
cmd_pid=$$         # Get PID of this script

sleep 5 && openbox --exit &  # Create a process in the background that will wait
                             # for 5 seconds and then exit Openbox.

printf "${cmd_name}($cmd_pid): I've given order to kill Openbox. This will \
happen shortly after I'm done.\n"

exit

(On a side note: I found that making the wait-and-exit routine a compound command by enclosing it in {} is not necessary because && already ties both commands together.)

Running this script and asking the shell for its exit status after it has finished shows that it is able to exit cleanly before the window manager is closed down:

$ ./devel/shell/procman/procman1 && echo $?
procman1(4742): I've given order to kill Openbox. This will happen shortly after I'm done.
0

The problem here is that allowing the current script to finish is achieved simply by waiting 5 seconds before shutting down Openbox. And while there's a very good chance this script is never going to take longer than 5 seconds to complete, scheduling a command execution based on the estimated execution time of another – instead of actually checking if that process is still alive – is fundamentally risky and should not be done.

The wait-and-exit routine should rather stay awake and explicitly wait for the script to finish. Now, waiting for processes to complete before executing anything else can be achieved by issuing the wait command. But that has its limitations: It can only handle child processes of the current shell. If sleep is simply replaced by wait (plus PID of the running script), the shell will complain about that.

#!/bin/bash
#
# procman2

cmd_name=${0##*/}  # Get basename of the entered command
cmd_pid=$$         # Get PID of this script

wait $cmd_pid && openbox --exit &  # Create a process in the background that
                                   # will wait for this script to finish and
                                   # then exit Openbox.

printf "${cmd_name}($cmd_pid): I've given order to kill Openbox. This will \
happen shortly after I'm done.\n"

exit

Running the script results in an error message from wait:

$ ./devel/shell/procman/procman2 && echo $?
procman2(5529): I've given order to kill Openbox. This will happen shortly after I'm done.
./devel/shell/procman/procman2: line 8: wait: pid 5529 is not a child of this shell
0

I'm still unsure why this really happens. I assume that #!/bin/bash at the beginning of a script creates a subshell in which the script is then executed. However, this is not reflected by the output of ps, as far as I can see.

Anyway, the question is: How is it possible to wait for any process to complete before executing a particular command? My solution has been inspired by some answers to this question on Stackoverflow. And it goes like this:

#!/bin/bash
#
# procman3

cmd_name=${0##*/}  # Get basename of the entered command
cmd_pid=$$         # Get PID of this script

function f_wait_exit {

  while ps -p $cmd_pid > /dev/null  # Check if this script is still running, but
                                    # redirect stdout of the ps command to
                                    # /dev/null
  do
    printf "Waiting for $cmd_pid to finish...\n"
    sleep 1  # Don't go crazy on CPU usage
  done

  sleep 3  # A bit of time to read the exit code of this script after it's done
  openbox --exit
}

f_wait_exit &  # Execute the wait-and-exit routine in the background

printf "${cmd_name}($cmd_pid): I've given order to kill Openbox. This will \
happen shortly after I'm done.\n"

sleep 3  # Keep this script alive for 3 seconds for demonstration purposes

exit

Running this script will give the following results:

$ ./devel/shell/procman/procman3 && echo $?
procman3(4805): I've given order to kill Openbox. This will happen shortly after I'm done.
Waiting for 4805 to finish...
Waiting for 4805 to finish...
Waiting for 4805 to finish...
0

So, problem solved? I guess so, apart from the fact that using sleep in the while loop creates a race condition. But, when the script is not kept alive for demonstration, the sleep time could be brought down to half a second or less there to reduce the risk of any new process taking $cmd_pid in the meantime.

msi · Devuan Derivatives

Fernando Negro wrote:

I recently found out that, instead of just modifying the original references to Debian and its repositories in the original Debian installer, the developers of Devuan decided to "heavily modify" the installer, and add proprietary firmware to it.
With the result of this being that, the installer is reportedly buggy, and (as I said) installs proprietary firmware on your computer.
(https://dev1galaxy.org/viewtopic.php?pid=8292#p8292)

Please stop spreading FUD about Devuan. If you want to criticize something, by all means, do so. But, please, make an attempt to get the facts together instead of constantly mingling legitimate concerns with suggestive statements and allegations towards the Devuan project. The kind of suspicion-driven speculation you've been rolling out in this forum right from your first post is taking everyone's time away for no good reason (including yours).

msi · News & Announcements

@boycottsystemd: You may want to repost your problem in Hardware & System Configuration.

msi · DIY

Another problem I've been facing with that script is that executing it involves killing its parent process. When running the script directly (meaning not from a terminal window), the process tree will look like this:

 PID  PPID COMMAND
2379     1   login
3678  2379     bash
3687  3678       startx
3709  3687         xinit
3710  3709           Xorg
3715  3709           openbox
4000  3715             wex
4015  4000               xmessage

Now, when Openbox is shut down by wex, wex will be killed immediately in return, meaning the end of the script will not be reached. To prevent this, I would probably have to do two things:

have the exit command for the window manager executed as a process independent of the running script
have the system wait for wex to finish before doing that

Btw, one thing that I don't understand about the process tree above is that, apparently, no new instance of bash is being created when wex is run, which is a bit strange given that it's a bash script.

msi · Devuan

To clear this up even further: The Devuan installation images use a heavily modified version of the Debian Installer. I've just talked to KatolaZ, who is currently the main person working on that. He confirmed that non-free being added by default is considered a genuine bug, which means that it's up for fixing.

msi · Installation

msi wrote:

devuan_dk_fan wrote:
sxhkd was not in /usr/bin. Something is obviously wrong with the package.
Did you have a look into /usr/local/bin as well?

Thinking about it again, being installed to /usr/local/bin wouldn't cause be a problem, afaik. But it could also have been installed to /opt/<package>/bin, in which case you would have to add that to your PATH to work.

msi · Devuan

To clear this up, here's a copy of the message about these issues that I've sent to the devuan-dev mailing list in early March. Unfortunately, it is not accessible through the mailinglist's web archive, so I'm reposting it here:

Hello,
two days ago, I installed Devuan Jessie on a laptop, using the i386 ~~netinst~~ CD image. After the installation was finished and I had booted into the new system, I noticed something strange about /etc/apt/sources.list. While the main package repository, "jessie", only had the "main" section activated, "jessie-security" and "jessie-updates" came with "main" and "non-free":
/etc/apt/sources.list on Devuan 1.0.0/jessie:

  #

  # deb cdrom:[Debian GNU/Linux 1.0-final _Jessie_ - Official i386 CD
Binary-1 20170522-03:52]/ jessie main non-free

  #deb cdrom:[Debian GNU/Linux 1.0-final _Jessie_ - Official i386 CD
Binary-1 20170522-03:52]/ jessie main non-free

  deb http://de.mirror.devuan.org/merged/ jessie main
  deb-src http://de.mirror.devuan.org/merged/ jessie main

  # jessie-security, previously known as 'volatile'
  deb http://de.mirror.devuan.org/merged/ jessie-security main non-free
  deb-src http://de.mirror.devuan.org/merged/ jessie-security main non-free

  # jessie-updates, previously known as 'volatile'
  deb http://de.mirror.devuan.org/merged/ jessie-updates main non-free
  deb-src http://de.mirror.devuan.org/merged/ jessie-updates main non-free
When I asked about this on IRC, Irrwahn pointed me to a bug report he had recently filed about what seems to be the same issue in ASCII. That report also shows that if you select to have the backports repo during the expert installation, that one will come with "non-free" in place as well. See: https://bugs.devuan.org/db/19/190.html
Now, it was unclear if the problem is specific to Devuan. So I checked that. I installed both Debian Jessie and Stretch (using i386 netinst) and had a look at their sources.list files. As can be seen below, neither one had "non-free" activated for "security" and "updtaes" by default (Didn't check backports.).
/etc/apt/sources.list on Debian 8.10.0/jessie:

  #

  # deb cdrom:[Debian GNU/Linux 8.10.0 _Jessie_ - Official i386 NETINST
Binary-1 20171209-21:10]/ jessie main

  #deb cdrom:[Debian GNU/Linux 8.10.0 _Jessie_ - Official i386 NETINST
Binary-1 20171209-21:10]/ jessie main

  deb http://ftp.de.debian.org/debian/ jessie main
  deb-src http://ftp.de.debian.org/debian/ jessie main

  deb http://security.debian.org/ jessie/updates main
  deb-src http://security.debian.org/ jessie/updates main

  # jessie-updates, previously known as 'volatile'
  deb http://ftp.de.debian.org/debian/ jessie-updates main
  deb-src http://ftp.de.debian.org/debian/ jessie-updates main
/etc/apt/sources.list on Debian 9.3.0/stretch:

  #

  # deb cdrom:[Debian GNU/Linux 9.3.0 _Stretch_ - Official i386 NETINST
20171209-13:03]/ stretch main

  #deb cdrom:[Debian GNU/Linux 9.3.0 _Stretch_ - Official i386 NETINST
20171209-13:03]/ stretch main

  deb http://debian.inf.tu-dresden.de/debian/ stretch main
  deb-src http://debian.inf.tu-dresden.de/debian/ stretch main

  deb http://security.debian.org/debian-security stretch/updates main
  deb-src http://security.debian.org/debian-security stretch/updates main

  # stretch-updates, previously known as 'volatile'
  deb http://debian.inf.tu-dresden.de/debian/ stretch-updates main
  deb-src http://debian.inf.tu-dresden.de/debian/ stretch-updates main
Looking at the Devuan sources list again, you will notice that the deactivated CD source already has "non-free" in it (also in Irrwahn's bug report) while the Debian versions don't. That's probably the reason why "non-free" ends up being activated for "security" and "updates" after installation. (Btw, why is the CD source in there twice in both the Devuan and Debian versions?)
The question is: Should it be there in the first place? I'm pretty certain it shouldn't. golinux has told me that "non-free" won't be there, if you install using the desktop-live image.
And while we're at it, there's another issue with sources.list that has been there in Jessie and, as Irrwahn's bug report shows, is still present in the ASCII beta: Only "updates" were "previously known as 'volatile'". See: https://bugs.devuan.org/db/15/158.html
So, I guess, this will have to be transformed into some bug reports, supposedly one for Jessie about "non-free" being activated by default and another one for ASCII about "ascii-security" still being labelled "previously known as 'volatile'". I just wanted to post the whole story here before.
Best,
msi

Fernando Negro wrote:

I'm not talking about any kind of "bug".

Looks like you are.

The officially official Devuan Forum!

#51 Re: Installation » [SOLVED] equivalent for Debian SID available? yes there are, read #3 » 2018-06-06 08:34:56

#52 Hardware & System Configuration » Problems with NTP and network config after upgrade » 2018-06-04 20:08:08

#53 Re: Installation » Ascii upgrade messed up the devuan jessie » 2018-06-04 18:51:53

#54 Re: Installation » Ascii upgrade messed up the devuan jessie » 2018-06-04 18:43:30

#55 Re: Installation » Ascii upgrade messed up the devuan jessie » 2018-06-04 18:21:39

#56 Off-topic » Microsoft acquiring GitHub » 2018-06-04 15:12:39

#57 Re: Devuan Derivatives » [Miyo] Question about Miyo's window managers' folder view setting » 2018-06-04 14:35:58

#58 Re: Hardware & System Configuration » [SOLVED]Floppy disk drive issues. » 2018-06-02 20:58:56

#59 Re: Devuan » Desktop Screenshot Contest! » 2018-06-02 16:54:28

#60 Re: Hardware & System Configuration » [SOLVED]Floppy disk drive issues. » 2018-06-02 15:02:24

#61 Re: Installation » [CLOSED] choosewm » 2018-05-30 13:11:22

#62 Re: Other Issues » 2 problems,revert system change and change password for user » 2018-05-29 09:39:46

#63 Re: Installation » [CLOSED] choosewm » 2018-05-28 22:17:04

#64 Re: Devuan » Desktop Screenshot Contest! » 2018-05-28 22:04:28

#65 Re: Devuan » Desktop Screenshot Contest! » 2018-05-28 14:41:44

#66 Re: Hardware & System Configuration » can't mount external device » 2018-05-28 12:26:51

#67 Re: DIY » Input requested regarding Suspend » 2018-05-13 23:15:47

#68 Re: Installation » Net install » 2018-04-26 13:59:22

#69 Re: DIY » Warn on exit script for Openbox, JWM etc. » 2018-04-20 20:42:41

#70 Re: Devuan Derivatives » Any Devuan-based distros that use Debian's original installer? » 2018-04-16 18:43:16

#71 Re: News & Announcements » Devuan 2.0 ASCII Beta is here! » 2018-04-11 12:32:35

#72 Re: DIY » Warn on exit script for Openbox, JWM etc. » 2018-04-11 12:21:09

#73 Re: Devuan » contrib and non-free repositories should be disabled by default » 2018-04-10 08:41:57

#74 Re: Installation » Minimal bspwm Devuan install problems. » 2018-04-09 12:23:46

#75 Re: Devuan » contrib and non-free repositories should be disabled by default » 2018-04-09 12:00:42

Board footer