The officially official Devuan Forum!

You are not logged in.

#1176 Re: Installation » [SOLVED] Cleaning up installation » 2021-06-20 00:43:08

Hello:

Marjorie wrote:

... still need the current kernel headers to recompile the kernel module for NVidia if you are using NVidia's own driver.

Now that you mention it, my memory's been reactivated.  8^/

I recall that having that package installed was neecessary.
HevyDevy figured out how to install the proprietary drivers some time ago when I was having some problems (persistance package IIRC) and part of the sequence was installing the headers if they were not there.

I am on Beowulf but with a backported kernel so I don't know what applies.
In any case, if I ever have to install the Nvidia stuff again, I'll probably find out.

Thanks for the heads up.

Best,

A.

#1177 Re: Installation » [SOLVED] Cleaning up installation » 2021-06-19 19:08:06

Hello:

chris2be8 wrote:

I'd try apt-get --simulate autoremove ...

That didn't show anything

Head_on_a_Stick wrote:

Yes ...
... kernel does not have the headers listed as a dependency.
... only needed for building custom kernel modules so most users don't need them.

Good to know.
Thanks for the heads up.  8^)

I can now continue with the housekeeping.

Best,

A.

#1178 Installation » [SOLVED] Cleaning up installation » 2021-06-19 15:34:41

Altoid
Replies: 6

Hello:

After a good while of using a newer kernel in Beowulf and with no evident issues, I've decided to clean up old stuff.

[root@devuan groucho]# uname -a
Linux devuan 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux
[root@devuan groucho]# 

So I first had a look at what was there:

groucho@devuan:~$ apt list | grep linux-headers | grep installed

linux-headers-4.19.0-17-amd64/stable,now 4.19.194-1 amd64 [installed,automatic]
linux-headers-4.19.0-17-common/stable,stable,now 4.19.194-1 all [installed,automatic]
linux-headers-5.10.0-0.bpo.3-amd64/stable-backports,now 5.10.13-1~bpo10+1 amd64 [installed]
linux-headers-5.10.0-0.bpo.3-common/stable-backports,stable-backports,now 5.10.13-1~bpo10+1 all [installed,automatic]
linux-headers-amd64/stable,now 4.19+105+deb10u12 amd64 [installed]
groucho@devuan:~$ 

Seeing that 4.19.0-17 was the target for removal, I opened a terminal:

[root@devuan groucho]# apt purge linux-headers-4.19.0-17-amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-headers-4.19.0-17-common linux-kbuild-4.19
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  linux-headers-4.19.0-17-amd64* linux-headers-amd64*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 5268 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
[root@devuan groucho]#

Is this right?
ie: linux-headers-amd64  -> Linux devuan 5.10.0-0.bpo.3-amd64 does not need it?

Thanks in advance.

A.

#1179 Re: Desktop and Multimedia » keyboard behavior changed - why and how to fix it » 2021-06-14 18:08:47

Hello:

golinux wrote:

Thanks ...

You're welcome.

golinux wrote:

... BIOS issue is never good news.

Quite so.

But check the installed version anyhow.
You may already have the latest one available for that board.

golinux wrote:

... terror of having to flash a board ...

I don't like it either.

The usual lack of properly written BIOSs aside, gigabyte is a reputed brand and their hardware can be considered trustworthy.
They may also have BIOS recovery tools in case something goes wrong.
Unless the board is very old, it is quite straightforward to flash a BIOS.

golinux wrote:

... going to live with it on the old board.

You may have seen that I run a Sun MS U24 workstation, very expensive when it hit the market in 2007.
My present full monty configuration would have cost me well over $4.000 at the time.
Obviously, I got my box second hand.

Well ...
The BIOS on this box was a real POS from day one.

As it is not a laptop, does not need to run on solar panels or be up 24/7, I have disabled all the power management settings I could disable.
Processor throttling is taken care of by cpuidle but the rest is off or disabled.
Curiously enough, attempting to disable S states in BIOS put the box in an unusable state, requiring a BIOS wipe and reflash. (!)

In any case, you may want to consider if having any S states enabled (ie: standby/sleep/hibernate) is really necessary for you.

Best,

A.

#1180 Re: Desktop and Multimedia » keyboard behavior changed - why and how to fix it » 2021-06-13 21:54:47

Hello:

golinux wrote:

... ascii 2.1 i386 on my other machine an older gigabyte board ...

One of the things I have learnt with Linux is that a properly written BIOS is crucial to getting ACPI things to work properly.

All the 'S''states that relate to power control settings such as suspend, sleep, etc. depend on properly written BIOS/ACPI tables.
ie: a BIOS that is written correctly observing published ACPI guidelines.

Of all the S states, S3 (the sleep/suspend stuff) is the most difficult to get right because it involves different hardware from different OEMs doing the same thing at the same time, not just the motherboard.

Now, one would think that any and all OEMs would follow ACPI guidelines to the letter, but unfortunately that is not the case.
From the very start, OEMs have followed ACPI guidelines in the way Microsoft interprets them (not the same thing) and this is because ...

But I digress.

You may want to (first) try to get the latest BIOS version for your gigabyte board and see if the issue gets worked out.
There may also be a BIOS setting you need to change.
eg: advanced power management settings -> what 'S' state 'Sleep Mode' is set to.

Bear in mind that as kernel development has advanced, at the same time it has also revealed previously undetected BIOS problems in older hardware.

Best,

A.

#1181 Re: Desktop and Multimedia » [SOLVED] Package: tuned, not working » 2021-06-11 13:13:02

Hello:

DevuanUser345 wrote:

... he would prefer not to ship it in debian was he is not able to debug things as he does not have sysvinit machines around.

This is where it all starts.
It's a sign of Things To Come©.    ---> 8^/

A.

#1182 Installation » Reasons to stay with Devuan » 2021-06-11 07:13:49

Altoid
Replies: 14

Hello:

In a blog post on Thursday, GitHub security researcher Kevin Backhouse recounted how he found the bug (CVE-2021-3560) in a service called polkit that is used in systemd, a common Linux system and service manager component.

Backhouse says the flaw is surprisingly easy to exploit, requiring only a few commands using standard terminal tools like bash, kill, and dbus-send.

See:
Seven-year-old make-me-root bug in Linux kernel patched. https://www.theregister.com/2021/06/11/ … olkit_bug/

So ...
Still want to know if there's a reason to stay with Devuan?

Best,

A.

#1183 Re: Desktop and Multimedia » [SOLVED] Package: tuned, not working » 2021-06-10 14:16:08

Hello:

DevuanUser345 wrote:

As there is a desktop mode ...

Well ...
The Linux kernel has quite a few things enabled by default which (imho) are not needed, save in a server setup.
eg: apparmor, etc.

DevuanUser345 wrote:

... not sure if it should be in the repo or not ...
... not skilled enough ...

Nonsense ...
You were skilled enough to write a script to make it work, the first time around.  8^D

That's certainly not my case.
I would not have been able to use a package installed from the Devuan repository due to its (apparently) missing a vital part.

So ...
Does it make sense that it be in the repository if it is (apparently) incomplete?

DevuanUser345 wrote:

... all packages (buster, bullseye, sid) do not have a sysvinit script.

Then it is a very good thing that you discovered this, wrote and shared the necessary script.
Like I said earlier, maybe it is a slip-up on behalf of the packagers.

Best,

A.

#1184 Re: Desktop and Multimedia » [SOLVED] Package: tuned, not working » 2021-06-10 13:11:52

Hello:

DevuanUser345 wrote:

... "tuned" is directly from redhat they are banning init.d scripts ...
... so "tuned" does not provide any.
... daemon didnt start ...
... the tuned-adm daemon control tool didnt work.

This is (I suppose) mainly for a portable system, so I don't have any use for it it.
But if this is so and there isn't a good reason for this (ie: Devuan package for tuned without the proper scripts) maybe it should not be in the repository.

DevuanUser345 wrote:

... wrote the init.d script on my own.
... first init.d script i have written so far.

Good going! 8^D !
You may want to consider reporting this to those taking care of the packaging at Devuan HQ.
Maybe it was just a slip-up on their behalf, they do have a lot o their hands.

Thanks a lot for your effort.

Best,

A.

#1185 Re: Installation » UUID and drive letter assignments » 2021-06-10 00:35:54

Hello:

GlennW wrote:

... for me it's monitoring disk space.

I monitor disk space like this:

 DISKS
 ${hr 2}
 / $alignc ${fs_used /} / ${fs_size /} $alignr ${fs_used_perc /}%
 ${fs_bar /}
 /home $alignc ${fs_used /home} / ${fs_size /home} $alignr ${fs_used_perc /home}%
 ${fs_bar /home}
 /media/backups $alignc ${fs_used /media/backups} / ${fs_size /media/backups} $alignr ${fs_used_perc /media/backups}%
 ${fs_bar /media/backups}
 /var/log $alignc ${fs_used /var/log} / ${fs_size /var/log} $alignr ${fs_used_perc /var/log}%
 ${fs_bar /var/log}

Not my doing but cannot recall the source.
Thanks for your input.

Best,

A.

#1186 Re: Installation » UUID and drive letter assignments » 2021-06-10 00:32:23

Hello:

Dutch_Master wrote:

... should be able to assign letters to specific UUID's using (e)udev rules.

I think it may be easier to just assign labels instead of saying /dev/sdx.

eg:

SATA1: +${execi 60 hddtemp /dev/disk/by-uuid/d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 | cut -c 81-86} 

Thanks for your input.

Best,

A.

#1187 Installation » UUID and drive letter assignments » 2021-06-09 19:39:34

Altoid
Replies: 5

Hello:

My Devuan box has four SAS drive slots, an on-board USB socket and room to comfortably install an additional two or three 2.5" drives.

I use UUID to keep the installation behaving properly (so to speak) but although this works, drive letters move around between UUIDs if I add a drive.

This affects my conky output by mean of which I monitor drive temperatures.

/dev/sda: +${execi 60 hddtemp /dev/disk/by-uuid/d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 | cut -c 81-84}
/dev/sdb: +${execi 60 hddtemp /dev/disk/by-uuid/49d1369c-ed70-4543-b0ee-ef65327e101b | cut -c 83-86}
/dev/sdc: +${execi 60 hddtemp /dev/disk/by-uuid/bdf33361-5929-433e-ac7f-1a626aa6e844 | cut -c 78-81}
/dev/sdd: +${execi 60 hddtemp /dev/disk/by-uuid/7a33fda5-abda-451b-b6ef-c17553c78810 | cut -c 83-86}
/dev/sde: +${execi 60 hddtemp /dev/disk/by-uuid/ca8dbded-819d-4e2b-b017-0981a75ea718 | cut -c 101-104}

           

When I added an old SATA drive for testing purposes, drive letters got shuffled down, the new drive became /dev/sda and the one that was /dev/sda became /dev/sdb.
So, while I am still monitoring a specific drive's temperature, I sort of lost as to which drive it is.

It's just a labelling but it is what I use to ID the drives and their temperatures via conky.

Maybe I should skip the /dev/sdx system and just go with something like Drive N?

Comments welcome.

Thanks in advance,

A.

#1188 Re: Off-topic » What will happen to Windows? » 2021-06-06 13:06:34

Hello:

golinux wrote:

Censorship is a slippery slope.

Quite so ...
Very.
Not my intent.

golinux wrote:

... post may be stupid and irrelevant ...

Not stupid.
In another context/forum it would actually be a fitting subject.

In my opinion, I'd say it is (if anything) irrelevant.

golinux wrote:

Devuan is better ...

That was my idea.

Thanks.

Best,

A.

#1189 Re: Installation » Nvidia persistence? » 2021-06-06 00:44:09

Hello:

Spaceman Spiff wrote:

... installed the proprietary nvidia driver ...
... keep getting this message when I install a new package ...

Did you check out the thread I suggested?  ->  https://dev1galaxy.org/viewtopic.php?id=3820

See post #23, it has a step by step rendition of how I followed Hevy Devy's instructions and solved my problem.

Don't skip any steps.

Best,

A.

#1190 Re: Off-topic » What will happen to Windows? » 2021-06-05 21:54:47

golinux wrote:

Freedom is a double edged sword so actions should be chosen with care.

Indeed ...

I really fail to grasp how/why What will happen to Windows can actually be a topic, even here at the Off-topic forum.

Ah, yes ...
Forgot my pill.  8^/

A.

#1191 Re: Devuan Derivatives » Support for DevuanDog! » 2021-06-02 17:05:47

Hello:

brday wrote:

BusterDog is still available and active?

Hmm ...
No idea.
Not my dog.
Sadly, I haven't had a dog since I was 16.

brday wrote:

What is your link to download your Live iso?

I don't have a Live iso, hence I have no link to anything you can download.

brday wrote:

Since July 2020 there is no activity on your forum.

Makes sense ...
I don't have a forum.
Never had one.

brday wrote:

I don't understand how a nice system like DevuanDog has been discontinued.

Hmm ...

Ask the author?
Or carefully read what he posted here --> https://oldforum.puppylinux.com/viewtop … c#p1040932

ie:

fredx181 wrote:

Reason is that I've found a self-supporting way, which I prefer, to avoid systemd, BusterDog is based on Debian Buster with a few alterations to make possible running without systemd.

brday wrote:

Sorry ...

It's quite all right.
Every one has a bad day at some time or another.
I have one every week.
Usually on tuesdays, occasionally fridays.

brday wrote:

...  in what flavor of Devuan do you have software updated to date with firefox which is about version 89?

Sorry to dissapoint you.
I don't have any flavours of Devuan.
Just the plain Devuan Beowulf I got here.

But my all time favourite ice cream flavour is bitter chocolate with dark chocolate chips mixed in.
Yes, redundancy is a real thing for me.

Cheers,   8^P

A.

#1192 Re: Devuan Derivatives » Support for DevuanDog! » 2021-06-02 12:36:12

Hello:

brday wrote:

Why did devuandog stay in 2019? ...

It was discontinued/terminated.

See: https://oldforum.puppylinux.com/viewtop … 2#p1040932

fredx181 wrote:

Reason is that I've found a self-supporting way, which I prefer, to avoid systemd, BusterDog is based on Debian Buster with a few alterations to make possible running without systemd.

A.

#1193 Re: Other Issues » Tape drives » 2021-05-23 21:11:33

Hello:

alphalpha wrote:

that might be it
sadly ftape and zftape are not in the kernel anymore

Indeed ...

The problem was that this hardware (my opinion) was not really something solid like all the SCSI tape drives out there at the time.
The advantage was that it was much less expensive to get a QIC/Travan etc. and run it from a parallel port or IDE adaptor card.
But for most, not the real thing.

In my day, I had a QIC and a Travan under Windows but found them to be slow and unreliable.

Here's a link to old Ubuntu releases:

http://old-releases.ubuntu.com/releases/

Try Ubuntu 5.10 (Breezy Badger) or Ubuntu 6.06.2 LTS (Dapper Drake), both have 64bit DVD Live editions:

http://old-releases.ubuntu.com/releases … -amd64.iso
http://old-releases.ubuntu.com/releases … -amd64.iso

alphalpha wrote:

... any practical usecase for that tape drive ...

Quite so.

With relatively inexpensive fast HDDs to make a multiple Tb NAS with very little investment, tape ends up being cumbersome.
And no, I will not store anything in any cloud.

A cloud is just water vapour: one moment it's there, the next it's gone.

I had my last DAT DD2 drive sitting atop my box for the longest while and finally decided to move it out of the way last week.
A beautiful Sun Microsystems external box hosting a Seagate Scorpion 8000 which saw very little use.
Maybe the box, PS and SCSI board will be of use for something.

alphalpha wrote:

... still curious what might be sitting on that tape

Ahh ...
So that's it.  8^D !

alphalpha wrote:

... put it back into that old 486 where i ripped it out ...

You'll still need the application used to make the tape or download it raw and pick out the bits.

Once you find out what you can do by booting the Ubuntu DVD, you may want to make a VM see if you can access it from there.
Much better than trying anything with the 486.

Cheers,

A.

#1194 Re: Other Issues » Tape drives » 2021-05-22 17:16:32

Hello:

It seems that what is needed is to load the proper driver modules.

ie: modprobe zftape -> depends ftape

This will load zftape and ftape, creating all needed devices under /dev, so there's no MAKEDEV to run.

But this was when you could actually find ftape and zftape for your kernel.

zftape and ftape went awol quite a few years ago, so they were taken out of the kernel from 2.x something on.
I have read in one post that maybe some old Ubuntu may have it, so booting that from a CD may be a solution.

https://retrocomputing.stackexchange.co … with-ftape

Check out these posts:

http://thewunders.org/SxS/storage/ftape.html

https://tldp.org/HOWTO/Ftape-HOWTO-6.html#ss6.1

https://github.com/Godzil/ftape

https://dmitrybrant.com/2020/11/01/how- … -qic-tapes

Good luck ...  8^)

Best,

A.

#1195 Re: Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-17 18:30:18

Hello:

Camtaf wrote:

Everything not needed to run a system should remain optional ...
... don't foist these things onto ordinary desktop users ...

Evidently that's not the vision of those who are in a position to run the Debian show and decide the hows, why's and whens.

Camtaf wrote:

... a good working distro to do my daily tasks ..

I'm glad to see we're more than one.

But I'm afraid the dice have already been rolled.
And the result was not in our favour.

Hence the very existence of Devuan.

Best,

A.

#1196 Re: Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-17 15:51:26

Hello:

dice wrote:

... this sort of config should be opt in even at the kernel level.

Exactly my point.

Altoid wrote:

If and when I want/need to install a Mandatory Access Control scheme for my rig's security, I'll just apt install the required modules and configure.

Altoid wrote:

Makes no sense to call it a security feature ...

I could not care less about what it is called.

It is being made part of the kernel just because some DH decided it should be.
Why? On the basis of what?

Next thing you know you'll have to set it up/configure if you want the kernel to work.
eg: no apparmor/tomoyo/SELinux? No WAN/LAN.

This has all the colourings of one of Poettering's diktats.
Like this other one:

https://dev1galaxy.org/viewtopic.php?id=4136

Bad, bad, bad ...

A.

#1197 Re: Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-16 22:46:29

Hello:

You were quite right, I stand corrected.

In spite of what wiki.archlinux says, adding security=none disables tomoyo as there are no entries for it in dmesg, kern.log or syslog.

Edit: security=none not only disables tomoyo, it also makes apparmor=0 unneccesary. 8^D

Thanks for the heads up.  8^)
Best,

A.

#1198 Re: Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-16 22:30:18

Hello:

ralph.ronnquist wrote:

... Way Too Many.

Indeed ...

ralph.ronnquist wrote:

tomoyo-tools ...
... why that is enabled in debian's standard linux-image is unkown to me ...

Hmm ...
Maybe it's yet another one of Poettering's brillant ideas?

ralph.ronnquist wrote:

Apparently adding security=none to the boot command should disable this one.

I was wondering about that.
A bit for disabling apparmor but none for disabling tomoyo?

I think not:
https://wiki.archlinux.org/title/TOMOYO_Linux#

wiki.archlinux wrote:

TOMOYO Linux 2.x is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This chart compares the differences between each branch.

wiki.archlinux wrote:

Disabling
For kernels 5.1 and above remove tomoyo from the lsm= kernel parameter or remove lsm= entirely.  <- | x |
For kernels 3.2 to 5.0 change the kernel parameter security=tomoyo to security=none.

I'll try it out and report.

-------> I_don't_like_this.  8^|

If and when I want/need to install a Mandatory Access Control scheme for my rig's security, I'll just apt install the required modules and configure.
Why do I have to have the kernel looking to run something that is not there?

Thanks for your input.

Best,

A.

#1199 Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-16 19:29:46

Altoid
Replies: 8

Hello:

My 4.19 Devuan Beowulf, unlike ascii which had it disabled by default, set up apparmor as if I had actually asked for it.

I let it stay on and after reading around a bit, decided that it was not worth keeping around.
So I uninstalled it and added apparmor=0 to my kernel command line so it would not be asking for it.

Fast forward to my upgrading the installation to the 5.10 kernel:

groucho@devuan:~$ uname -a
Linux devuan 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux
groucho@devuan:~$ 

The 5.10 kernel also recommends apparmor:

groucho@devuan:~$ aptitude why apparmor
i   linux-image-5.10.0-0.bpo.3-amd64 Recommends apparmor
groucho@devuan:~$ 

So it does as the upgrade from ascii to Beowulf did and installs apparmor.

Now ...
Seeing that my kernel command line had the apparmor=0 bit, you'd think that it would leave it alone and skip installing apparmor.
After all, it left the rest of the command line stanzas as they were.

But no ...
Not only did it install apparmor but it also removed the apparmor=0 bit from the kernel command line.

No big deal: I just uninstalled it and returned the kernel command line to what I had set it.

Then while looking for clues as to what goes on in my system when I get a bad shutdown, I found this in dmesg:

In dmesg ie: at boot

[   21.906451] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist.

Also at shutdown:

In kern.log and syslog:

May 16 13:57:16 devuan kernel: [14429.313238] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist.

I had to look it up as I had no idea as to what tomoyo was, let alone of its existence.

What is all this about?
Is it just me or am I seeing far too many (unrequired) Mandatory Access Control instances in the Linux kernel?

Cheers,

A.

#1200 Re: Other Issues » Tape drives » 2021-05-15 15:49:31

Hello.

alphalpha wrote:

... iomega tape 250 drive along with this 3gb ditto tape ...

Nice find.  8^)

alphalpha wrote:

... how do i get it to work?

The key to this may be here:

Wiki wrote:

Technical aspects

Ditto internal drives were connected through the floppy drive channel and used MFM encoding to store data (the same method as on older floppy drives). An ISA accelerator card called the Ditto Dash, providing higher speed than a stock floppy controller, was also available.
--- snip ---

Check that the USB Floppy adapter is correctly inserted.
It should (?) have a key (like the IDE cables did) or some indication in the adapter's manual/instruction sheet.

See:

https://en.wikipedia.org/wiki/Ditto_(drive)
https://www.manualslib.com/products/Iom … 35190.html   <---- | x |
https://johnvidler.co.uk/linux-journal/LJ/022/1215.html
http://pong.tamu.edu/~baum/linux/LDP/HO … TO-28.html

Edit:
https://tldp.org/HOWTO/pdf/ZIP-Drive.pdf

Best,

A.

Board footer

Forum Software