The officially official Devuan Forum!

You are not logged in.

#1 Re: Off-topic » What's the point to keep maintaining DEVUAN? » Yesterday 15:02:35

spartrekus.git wrote:

Hello,

I see not really a point to keep DEVUAN being maintained.[etc] Wayland, SystemD, Pulseaudio, ... is the future !   
[etc]
Another Unix BSD user.

Great trolling!

#2 Re: Installation » Downgrading Ascii back to Jessie » 2018-01-11 21:09:14

The only way to downgrade is to strip back to a bare system and run an upgrade specifying the release you want to "upgrade", gthen painstakingly go through downgrading individuals and removing problem packages.  apt will warn you that packages are to be downgraded (I've done it successfully, but that was back in the days of Debian etch, lenny and squeeze).  It's rarely worth the effort however and better to just reinstall.

#3 Re: Other Issues » ATK bridge not found [SOLVED] » 2018-01-11 20:59:39

Maybe missing dbus "plumbing"...  probably an error you can safely ignore?  (as with most of the crap gtk spits out)

https://packages.debian.org/source/jessie/at-spi2-atk

You could try installing "libatk-adaptor" (the only other relevant binary built from that source package) and see if that "silences" it...

#4 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-11 16:32:13

00:00.0 Host bridge: Intel Corporation Device 1918 (rev 07)

Apparently this is a 'skylake' chip.  Stable support was added in the 4.2 kernel.  However from a few duckduckgo searches, it's been problematic.

Blacklisting of kernel mode setting drivers is less likely to work these days.

To boot with kernel mode setting disabled append nomodeset to the kernel command line (i915.modeset=0 also works).  This can be made permanent via bootloader config.

The 3.16 kernel didn't support your hardware, so was likely loading the vesa driver.  Disabling KMS on the 4.9 kernel and NOT explicitly loading the intel driver via any xorg  configuration files, should yield the same result on the 4.9 kernel (the vesa driver being used).  But surely just using vesa is not you end objective...?

You could just build a stable or mainline kernel, boot, startx leaving auto configured (no xorg config), cross your fingers and see what happens.

But mesa/drm and especially xorg (in particular xf86-video-intel) may all benefit from an upgrade.  Simply put - the jessie release is probably too old for your hardware.  It might be best for you to install the testing distribution.  If the 4.9 kernel yields the same results there, building a newer kernel for that toolchain will be more worthwhile than building one for what you have now.

#5 Re: Devuan » Install systemd on devuan or switching to dev1 from slackware » 2018-01-11 15:23:35

The problem with that approach is that the binary is not built for the target system and dependencies have moved on, become obsolete, etc (for that particular package there are quite a few examples).  Generally with any Debian system (or system based on Debian), stable freezes and testing/unstable diverges further and further away.  So you may get away with this early on in a stable release, but it's less likely 12 months later.

You may on occasion be able to install one local package (via dpkg), with few dependencies, which are already satisfied by the installed distribution, but adding another distribution's repositories is a bad idea, as you can end up with half of that distribution installed or worse still find yourself in a situation where an "accidental" (broken) upgrade has occurred.

Even with a good knowledge of apt pinning, setting default release, disabling automatic upgrades, etc, it's still a bad idea, unless you're running a mixed testing/unstable system and know exactly what you're doing.

#6 Re: Devuan » Install systemd on devuan or switching to dev1 from slackware » 2018-01-11 08:27:02

It would be useful to know why you're switching from Slackware?  You're going to find anything Debian based very different.

To install it as a package, you would have to backport it - and no, that's not quite as simple as sbopkg (which is "automation" for building from slackbuilds), but not exactly rocket science if you're prepared to read some documentation and experiment a bit.

Alternatively you could just get the source and build it and install to /usr/local

#7 Re: Other Issues » Meltdown and Spectre » 2018-01-10 11:22:02

fungus wrote:

I can't figure out why that is.  Maybe most of what I do only requires a single core/thread and even though this i7 clocks at 3.9 and mine at 3.3 it should still be way ahead.

In terms of clock speed it's not actually that huge a difference.  Apparently that core is 3.4GHz and can overclock to 3.9GHz, which I assume you have?

Usually modern CPUs don't run full belt 100% of the time.  They use "dynamic frequency scaling" to increase clock speed on demand.  Also unless you're running tasks which make heavy use of multi-threaded programmes you're not going to see a huge difference if you're just browsing or word processing, etc.

Linux uses the procfs filesystem, you could grep /proc/cpuinfo to see what MHz you're running at?

Then put the system under load, e.g. compile something (such as a new kernel?) with a parallel build (number of jobs = 1.5x the number of cores).

grep /proc/cpuinfo again to see if the clock speed has increased.

As I recall, with modern Intel CPU's, it's all configured via the BIOS... so the frequency scaling should be turned on there (forgot the Intel "brand names" for these) and Linux cpufreq driver isn't needed.

#8 Re: Other Issues » Meltdown and Spectre » 2018-01-08 10:39:28

joril wrote:
MiyoLinux wrote:

Perhaps this will shed more information?

https://www.debian.org/security/2018/dsa-4078

Ok so according to this page, Jessie is still vulnerable... hmm Thanks!

Looks like it.  The 3.16.x longterm branch hasn't been patched upstream.  You may find out why by searching the Linux kernel Mailing List.

However, there are 35 security issues related to Linux in the jessie release: https://security-tracker.debian.org/tra … kage/linux

As you seem concerned, I suggest building a new upstream longterm 4.4 or 4.9 kernel which have the KPTI patches.

greenjeans wrote:

All AMD here for last dozen years, but I guess Spectre still applies...looks like it may be a difficult fix?

The only real 'fix' is new CPUs without these flaws...

fungus wrote:

There is no such thing as apt dist-upgrade.

Seems to be "full-upgrade" (as is the case with aptitude): https://manpages.debian.org/jessie/apt/apt.8.en.html

#9 Re: Other Issues » Meltdown and Spectre » 2018-01-06 13:26:56

# apt-get update && apt-get upgrade

?

You can always grab the source and build a new kernel.

The "spectre" "fix" isn't so simple I suggest reading at least the white papers at the sites set up for these.

#10 Re: Devuan » Considering migration from a different distribution. » 2017-12-21 14:40:39

hurricane wrote:

_ Has anybody got the unreal engine working on Devuan?

This is not really distribution dependent.  Two Unreal engines were ported several years ago: UT99 and UT2K3/UT2K4.  These were proprietary Linux ports.

Unreal Engine 4 is different matter: https://www.unrealengine.com/en-US/faq

#11 Re: Hardware & System Configuration » Frequent indexing thrashes HDD » 2017-12-20 12:35:22

It's not (usually) a file system thing, so I'd imagine you have some kind of 'indexing service' running?  Without more details, it's going to be difficult to say.  If it's something which starts with a particular desktop you're running, just disable it.

#12 Re: Off-topic » in 32bit, you, simply, can more! » 2017-12-07 17:03:01

oui wrote:

the problem is, Google did change extremely the rules:

if you visit the Google page of youtube (yes, youtube is now google, do never forget it!) concerning html5, you will see that no other browser as firefox, and only under the condition of some restrictions concerning hardware etc., under the FREE BROWSER can handle HTML5!
[...]
it is exact what Google did want pushing html5!

While I'm certainly no fan of Alphabet/Google, I'm not sure why you conclude that the W3C's EME DRM in HTML5 is solely the fault of Google?

The other 471 W3C members include, among others, some large media companies from around the world, who are certainly interested in pushing DRM to protect their revenue streams.

https://www.w3.org/Consortium/Member/List

Sadly HTML5's EME was given momentum by the "we must get rid of flash at all costs" people and others bought into the inevitability of polluting open WWW standards with a DRM provision as a necessary evil for watching streaming video.

flash was and still is a turd, but at least it was a turd you could choose to avoid.  Now unless you compile your browser from source, DRM is built in.

#13 Re: Hardware & System Configuration » Clarity regarding eth0 device name » 2017-11-29 22:05:00

udev is part of the systemd source tree - it's a systemd component.  This wasn't always the case, but since around 2012 (?) it is now.

It has zero to do with "network manager".

Device nodes are generated dynamically at boot by udev.  This is one of the much vaunted "features".

You can, or could, still just revert to a static /dev, make all your device nodes and just bin udev altogether.  Though, it's a use case thing - horses for courses, etc.  (Full blown desktops, won't like it...)

Alternatives to udev, you'd probably have to port over and build from source yourself.

#14 Re: Hardware & System Configuration » Which AMD/ATI radeon firmware is being used....? RV710/M92 » 2017-11-29 21:50:48

The firmware is non executable code which runs on the device itself.  It's not a Linux binary (or even a Windows binary).  For some devices, the firmware is loaded onto the device rather than already residing on the device (e.g. hard disk controllers, system BIOS, most ethernet adapters, etc).

For those devices requiring userspace loading of the firmware (very commonly USB devices), the firmware has to be available or the device simply will not start and will be unusable.

x86/amd64 hardware (and some ARM evaluation boards such as Raspberry Pi) is already a mess of firmware (the biggest messes being UEFI and Intel and AMD microcode to name just a few) so just focusing on these bits of proprietary firmware and claiming a particular OS or Linux distribution is "free" because it omits them is what amounts to snake oil salesmanship.

firmware-linux-nonfree package contains an assortment of this for various hardware, including firmware for the various AMD GPUs.  Without the firmware you certainly won't get hardware accelerated direct rendering and probably not any form of power management either.

The package xserver-xorg-video-radeon (-ati) is the xorg driver.  It is the kernel mode setting driver (part of the kernel) which usually initiates the loading of the device firmware.

The short version is that if you want to use your hardware, you'll need to keep the firmware installed.

If you object to the firmware, because it's proprietary, then you probably need to abandon x86 and look at the (few and expensive) open hardware alternatives.

#15 Re: Hardware & System Configuration » Clarity regarding eth0 device name » 2017-11-29 21:34:47

If you pass 'net.ifnames=0' to the kernel command line it will disable the "predictable" network interface device node naming. i.e it will return to the old eth0, eth1... naming.

It will not solve the OP's problem of persistent naming.  That used to be resolved by clearing /etc/udev/rules.d/70-persistent-net.rules (in this case it would need to be run on every shutdown).

Combining the two approaches should give the desired result ("eth0" as the sole network interface).

however this is actually systemd we're talking about, so it's a moving target.  What works now, may no longer work in 6 months' time.

It's probably more advisable to switch away from systemd/udev and invest time in learning the alternatives...

#16 Re: Hardware & System Configuration » Clarity regarding eth0 device name » 2017-11-29 13:16:50

tlathm wrote:

What I was referring to specifically, as we ran into on CentOS 6, is when udev records an identifier for for a specific NIC card in /etc/udev/rules.d/70-persistent-net.rules. If the same VM boots in a different VM environment, it will end up with eth1 rather than eth0 unless that file has been removed, so we remove it at shutdown.

Yes as far as I know you will always have to remove that file at shutdown otherwise udev will try to enumerate interfaces with unique device nodes, lead to a build up of eth0, eth1, eth2, etc...

tlathm wrote:

The other issue, which I recall from way back with my Gentoo machines, was that switch to the entirely different naming scheme that replaces the eth0 naming. Under Gentoo that was prevented by simply adding a dummy file at /etc/udev/rules.d/80-net-name-slot.rules. I'm assuming we didn't run into that in CentOS 6 as that uses udev 147.

This is the problem covered by ralph.ronnquist's reply.

tlathm wrote:

As a matter of fact I've also replaced that grub 2 nightmare with syslinux...I wasn't not much happier with that than any of this udev stuff.

As a boot loader / boot manager, grub is doing far more than it should be.  It's a really pity lilo and elilo development stopped.

#18 Re: Off-topic » Firefox Quantum » 2017-11-28 12:40:48

It still seems to be in use in Gentoo: https://github.com/gentoo/gentoo/commit … 00924d6eb7

Do you have a link which shows those options are now removed in 57?

As far as I know, asla-lib support is still usable but no longer actively developed.

#19 Re: Off-topic » Firefox Quantum » 2017-11-27 14:37:17

Pulseaudio support is just the "default", it's still possible to build without it.  You could try pulling down the Debianised source and changing the 'mozconfig' options (build flags):

# Uncomment the following option if you have not installed PulseAudio
#ac_add_options --disable-pulseaudio
# and uncomment this if you installed alsa-lib instead of PulseAudio
#ac_add_options --enable-alsa

(source: http://linuxfromscratch.org/blfs/view/s … efox.html)

Then remove pulseaudio dependencies from the control file and rebuild the package.  Obviously not tried it myself, but I can't see why it wouldn't work...

#20 Re: Other Issues » [SOLVED] <Ascii> xfce4-terminal; No Scroll bar » 2017-11-21 21:59:23

Right click in the terminal window and select "show menu bar" if it's not already enabled.  Then from the menu bar select 'edit', 'preferences'.  You can then configure it to your liking...

Or find the related dotfile in ~/.config/xfce4/terminal/terminalrc

Three possible states for the scroll bar:

1.

ScrollingBar=TERMINAL_SCROLLBAR_LEFT

2.

ScrollingBar=TERMINAL_SCROLLBAR_NONE

3.
Unspecified (default position on the right)

And if you mess it up, just rm ~/.config/xfce4/terminal/terminalrc and start afresh.

Self explanatory?

#21 Re: Other Issues » [SOLVED] <Ascii> xfce4-terminal; No Scroll bar » 2017-11-20 16:34:41

It's years since I've used it, but it's highly configurable from the menu.  e.g. you can enable the scrollbar change the colours, fonts and set it up as a login shell, etc.

You can also scroll any terminal emulator in the same way as a VT (usually by SHIFT+PgUp/PgDn).

Finally, for commands which spit out many lines, you may not have a large enough scroll back buffer, so either increase it or just pipe your command output to a pager such as less, e.g:

$ ls -al|less

#22 Re: Other Issues » Firefox goes to be just title bar with a thin grey line just below » 2017-11-20 14:31:11

It sounds like the window could be getting accidentally "shaded" via a mouse action.

As I recall, double left clicking or scrolling the scroll wheel on the window title bar causes the window to roll/up down.  You could also temporarily switch to window decorations which support the shade button for a while and see how it goes.

#23 Re: Hardware & System Configuration » Kept back packages when updating » 2017-11-16 15:29:26

kernels usually don't get removed due to no packages actually depending on them.

With other packages, particularly in unstable, some major ABI change can result in apt-get wanting to remove half the system when you issue a dist-upgrade.  Not running a dist-upgrade regularly on an unstable system usually results in the system getting further and further behind, until it's no longer easily upgradeable.

#24 Re: Hardware & System Configuration » Kept back packages when updating » 2017-11-16 11:41:10

That's not quite how it works.

Despite it's name, "dist-upgrade" won't upgrade the system to a newer release.

Normal 'upgrade' upgrades packages without removing anything. (it will "hold back" on upgrading packages which could result in removals)

dist-upgrade will aggressively remove packages to ensure it fully upgrades all other packages to the latest version in the repositories.  This is why dist-upgrade is used for the "second phase" oldstable to stable upgrade.  Every upgrade in unstable is pretty much a major upgrade, hence why dist-upgrade is the preferred method.

Refer to apt-get(8)

dist-upgrade
In addition to performing the function of upgrade, this option also intelligently handles changing dependencies with new versions of packages; apt-get has a "smart" conflict resolution system, and it will attempt to upgrade the most important packages at the expense of less important ones, if necessary.

The next step is when everything breaks...

#25 Re: Hardware & System Configuration » Kept back packages when updating » 2017-11-16 09:53:11

TwistedFate wrote:

I am using Devuan Ceres if it matters

It does.  Running the unstable distribution assumes that you know what you're doing.  If you don't know the basics, it's best to run the stable distribution.

If you run a dist-upgrade instead of an upgrade, that will be the next step, but not necessarily the end of your problems.

Board footer

Forum Software