Download | Devuan.org | Git | Bugs | Packages

The officially official Devuan Forum!

You are not logged in.

Pages: 1

#1 Re: DIY » Update script for script hobbyists » 2024-06-25 10:00:24

tux2bsd
Apt uppdates database

A small typo fixed & banner message slightly more centrally aligned + code indenting:

#!/bin/bash
echo "________________________ Apt updates database _________________________"
apt update && apt list --upgradeable
echo "-----------> Upgrade? y/NO"
read ANSWER
if [ "$ANSWER" = "y" ] || [ "$ANSWER" = "Y" ]; then
    apt upgrade -y
else
    echo "No upgrades today!"
fi

and a bonus accept capital Y

#2 Re: DIY » init script for stubby » 2024-06-25 09:43:09

tux2bsd
#!/bin/sh

### BEGIN INIT INFO
# Provides: stubby
# Required-Start: $network $remote_fs $syslog
# Required-Stop:  $network $remote_fs $syslog
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Description: a dns resolver
### END INIT INFO

#. /lib/lsb/init-functions

case "$1" in
  start)
	test -f /run/stubby.pid || install -o stubby -g stubby -m 600 /dev/null /run/stubby.pid
	su - stubby -c "stubby &"
	;;
 stop)
	killall stubby
	rm /run/stubby.pid
        ;;
  *)
        echo "Usage: $SCRIPTNAME start" >&2
        exit 3
        ;;
esac

This should work OK.  Untested, I don't have stubby installed. Main goal is get rid of sudo for you.

If the stubby program writes to the PID fill it could be used to kill with instead.

#3 Re: Hardware & System Configuration » [SOLVED] no time service » 2024-05-26 09:00:25

tux2bsd

i got it sorted now. i only need a NTP client ... chrony installed...
added -4 flag to /etc/default/chrony and the server ip to /etc/chrony/chrony.conf
chronyc tracking shows things

Thanks grunchy, I wanted a quick ntp client without having to think, chrony installed without mucking around thanks to your pointers.  I might come back to it at some point and specify NTP servers later (country specific).  I don't actually want to be thinking about this as I'm focused on something else.

and rebooted

fyi you don't need to reboot for that, you can just do:

/etc/init.d/chrony restart

#4 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-04-20 06:10:37

tux2bsd

Dropbear package updated re-introducing the bug. 

Workaround: https://dev1galaxy.org/viewtopic.php?pid=46994#p46994

OP's post until now... 1,392 days

#5 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-01-09 05:17:27

tux2bsd

Surely a similar approach is quite common per package, given Devuan is a fork of Debian.

Looks like Amprolla exists for that but it is apparent that rolling a package for a 2 line fix in a shell script is too heavy (yes, I'm aware I suggested a package earlier).

For each user to have to fix a known problem by hand is also poor form.  Part of a Distribution's role is to to mitigate that.

There is a need to distribute reasonable bug fixes to that don't rely on Debian's bug fix process, especially when bugs only surface in Devuan and not stock Debian.  I have no interest making a non-stock Debian with sysvinit to then make it fail just so I can fob off a Devuan bug to Debian's team, that's gaming the system.

If there was a stock Debian bug fix found that can go to Debian in parallel, we all know it takes a while for those to eventuate.  There's benefit there too, earlier tracked fixes in Devuan.  When those fixes do arrive via Debian (after some years) they no longer need to be distributed.

I'm well aware the bug in this thread does not affect many people, though that that shouldn't matter.

OP's post until now...  1289 days

#6 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-01-07 22:44:24

tux2bsd

Surely a similar approach is quite common per package, given Devuan is a fork of Debian.

if patch for Debian package then patch file with Devuan specific fix to become Devuan's package
(e.g. cryptsetup-initramfs : /usr/share/cryptsetup/initramfs/bin/cryptroot-unlock Debian's file matches sha256 then patch )
else figure out what changed and make a new patch for Devuan's package containing this file

#7 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-01-07 22:20:39

tux2bsd

OP's post until now...  1288 days

#8 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-01-07 22:07:10

tux2bsd

It is already known that it is not forked (see #10 above).

How does your proposed report to Debian go?
"this thing that works in Debian doesn't work in Devuan"
or do you suggest I lie?
"when I used Debian with sysvinit this doesn't work"
  I'm not doing that:
    a - I don't lie
    b - The fix exists for Devuan, for the problem that surfaces when the package is used in Devuan

#9 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-01-07 20:48:00

tux2bsd

https://bugs.devuan.org/cgi/bugreport.cgi?bug=829

https://git.devuan.org/devuan/cryptsetu … s/issues/4

Hopefully someone with the right access can add the fix so future package updates don't cause regressions (to the current manual fix).

#10 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-01-07 19:51:47

tux2bsd

https://bugs.devuan.org/cgi/pkgreport.c … -initramfs

There is no maintainer for cryptsetup-initramfs... ...Please do not report new bugs against this package.

Not ideal.

#11 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-01-07 10:34:31

tux2bsd

Taking what Danielsan posted but making the error message meaningful.

diff /usr/share/cryptsetup/initramfs/bin/cryptroot-unlock.bug /usr/share/cryptsetup/initramfs/bin/cryptroot-unlock
33c33
< if [ ! -f "$TABFILE" ] || [ "$TABFILE" -ot "/proc/1" ]; then
---
> if [ ! -f "$TABFILE" ] ; then
35c35
<       echo "Try again later" >&2
---
>       echo "Error: $TABFILE missing." >&2

Also, remember to re-run 

update-initramfs -u -k all

#12 Re: Hardware & System Configuration » Dropbear-initramfs: cryptroot-unlock says "Try again later" forever » 2024-01-07 10:28:47

tux2bsd

Commenting exit 1 did not solve the issue, unless I misunderstood the fix!

Danielsan you needed to re-run 

update-initramfs -u -k all

I see you subsequently posted the work around in another thread  (linked from #7), it would have been better to have it in this thread to keep the history together.

#13 Re: Hardware & System Configuration » Dropbear-initramfs: criptroot-unlock: another workaround » 2024-01-07 10:20:59

tux2bsd

https://dev1galaxy.org/viewtopic.php?pid=46093#p46093

#14 Re: Other Issues » [SOLVED] DRBD 9.x userland vs kernel module being drbd 8.x » 2023-12-29 10:39:27

tux2bsd
tux2bsd wrote:

This bug is also inherited:
https://www.mail-archive.com/debian-bug … 92274.html

Very relevant to Devuan.

I fixed that bug and provided the fix upstream, given time it'll make it into Debian and Devuan.

https://bugs.debian.org/cgi-bin/bugrepo … 1030118#20

#15 Re: Other Issues » [SOLVED] DRBD 9.x userland vs kernel module being drbd 8.x » 2023-12-15 21:29:51

tux2bsd

Marking as solved as I have things working and don't need help.  There should be example-8.x , example-9.x .

#16 Re: Other Issues » [SOLVED] DRBD 9.x userland vs kernel module being drbd 8.x » 2023-12-15 21:26:48

tux2bsd

the drbd man pages do say 8.x...

root@devuan:~# drbdadm --version
DRBDADM_BUILDTAG=GIT-hash:\ 409097fe02187f83790b88ac3e0d94f3c167adab\ reproducible\ build\,\ 2023-01-09\ 14:51:18
DRBDADM_API_VERSION=1
DRBD_KERNEL_VERSION_CODE=0x08040b
DRBDADM_VERSION_CODE=0x091600
DRBDADM_VERSION=9.22.0

root@devuan:~# man drbdadm | tail
       or FITNESS FOR A PARTICULAR PURPOSE.

SEE ALSO
       drbd.conf(5), drbd(8), drbddisk(8), drbdsetup(8), drbdmeta(8) and the DRBD project web site[1]

NOTES
        1. DRBD project web site
           http://www.drbd.org/

DRBD 8.4.0                                      6 May 2011                                      DRBDADM(8)

I said earlier:

drbd-utils provides /usr/share/doc/drbd-utils/examples
  and those examples are for 9.x which don't work with the loaded kernel module (8.x).

Just doesn't make sense but this is inherited inconsistent example from, I asume, Debian.

tldr: ignore the example in /usr/share/doc/drbd-utils/

#17 Re: Other Issues » [SOLVED] DRBD 9.x userland vs kernel module being drbd 8.x » 2023-12-15 20:03:47

tux2bsd

I've got a working DRBD with these instructions: https://ubuntu.com/server/docs/ubuntu-ha-drbd
  The syntax (config format) there is 8.x , so it works with the loaded kernel module

That's "hello world" working, not well tuned.

#18 Re: Other Issues » [SOLVED] DRBD 9.x userland vs kernel module being drbd 8.x » 2023-12-15 20:01:18

tux2bsd

This bug is also inherited:
https://www.mail-archive.com/debian-bug … 92274.html

Very relevant to Devuan.

#19 Other Issues » [SOLVED] DRBD 9.x userland vs kernel module being drbd 8.x » 2023-12-15 19:45:39

tux2bsd
Replies: 5

From IRC last night:

tux2bsd    Latest stable Devuan kernel has drbd 8.x.   Userland drbd-utils 9.x.   Meaning if you attempt to configure via drbd (9) howtos the configs won't parse.   
tux2bsd    got the clue about what was wrong from here: https://serverfault.com/questions/10854 … connection
tux2bsd    I guess I configure for drbd8.x and hope the userland utils are backwards compatible

IRC END, continuing here:

drbd-utils provides /usr/share/doc/drbd-utils/examples
  and those examples are for 9.x which don't work with the loaded kernel module (8.x).

This isn't a new problem and it's inherited from upstream.

Any Devuan DRBD users out there that can point out what the right thing to do is?

Pages: 1

Board footer

Forum Software