The officially official Devuan Forum!

You are not logged in.

#1 Re: Installation » pkgmaster is repository hell (continued) » 2018-02-05 02:47:24

What's the output from:

$ tor-resolve devuanfwojg73k6r.onion

I believe that should tell you what the onion address resolves to. Then compare with output from:

$ host

#2 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-27 12:20:23

Great. I think. The command prompt may well be post-pivot, which would mean that you actually have booted Devuan, but that there is an issue with the graphics. A few things to inspect:

# blkid
# dmesg | tail
# tail /var/log/syslog
# ls -l /dev/sd*

Though, I'd say fsmithred has more experience about getting it back into shape from this state, so maybe you should now ignore me smile

#3 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-26 23:22:10

Did you try changing the grub line? Into

linux /boot/vmlinuz-3.16.0-4-amd64 root=UUID=f73498af-846e-447a-87d7-4f0b0b01818d

so as to completely avoid referring to /dev/sdd1

#4 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-26 19:42:14

Ok. I don't know why the initrd building worries about the device node, since it should just take what is given at boot time, and not at building time. There might be a number of gremlins under that stone, but maybe you get away with just rolling back and mounting devtmpfs onto /dev before another update-initramfs.

# mount -t devtmpfs none /dev

By idle guesswork, I think the initrd building really would want to find a file /var/lib/initramfs-tools/3.16.0-4-amd64 with content:

fd47cef5-ce5e-4090-8bfa-aef277a49e3e /boot/initrd.img-3.16.0-4-amd64

as its "database entry" of where that initrd is supposed to reside. But it burns my synapses trying to fathom an underlying logic for it.

Anyhow, maybe it'll be happy enough with having devtmpfs mounted.

#5 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-26 10:54:04

Hmm, there you see the disadvantage of me not actually testing the commands. It needs the -u as well as -k all.
(again edited the original; only a few commands to go smile)

#6 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-26 10:17:23

Sorry again; I'm too sloppy. It should have been

# mount -t devpts  none /dev/pts

('ve editied the original as well)

#7 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-26 08:23:06

Ah, my fault. It should be

# mount -t proc none /proc

sorry about that.

(I've corrected the post above)

#8 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-26 05:43:55

Yes, I also expected it to go into a shell prompt; a busybox shell prompt. And it should have a number of useful commands available, plus some more in /bin and /sbin.

But maybe you should park that line of study for the moment, and first address those module complaints. They all concern USB, and perhaps it's important to get them into your initrd.

1. Thus, first restore the grub line to be

linux root=/dev/sdd1

2. Then, boot up your Mint, and mount the partition like before, chroot into it, and set up the kernel's virtual file systems:

# mount /dev/sdd1 /mnt/devuan
# chroot /mnt/devuan
# mount -t proc none /proc
# mount -t sysfs none /sys
# mount -t devpts none /dev/pts

In passing, note that the chroot command starts a /bin/bash from within the Devuan file system, and all commands are from within the Devuan file system. The running kernel however is the Mint kernel.

3. Now, edit the file /etc/initramfs-tools/modules, to add the modules you saw mentioned:


(note I assume it said ehci-orion with a final n, and not ehci-orio. In any case, the actual module has that final n)

4. Then rebuild the initrd with the following

# update-initramfs -u -k all

That command will look for all kernels in /boot of the chroot-ed file system (Devuan), and prepare an initrd for each, into /boot. It does not change the links /vmlinuz and /initrd.img, which thus remain pointing out the kernel to use and its associated, and now updated, initrd.

5. Then, have a peek at /etc/fstab in the chroot-ed file system, and make sure it's fully agreeable.

6. Exit the chroot, and reboot into Devuan ... without problems ... (as if:))

If it doesn't work, you might want to try the UUID variation for the grub line, i.e.

linux root=UUID=fd47cef5-ce5e-4090-8bfa-aef277a49e3e

Doing so would avoid any possible problems with USB device enumeration during boot. As fsmithred noted, it's possible that the Devuan boot-up sees a different device enumeration than the Mint boot-up (for reasons too complicated to worry about), and, say, that the Devuan partition gets enumrated as the first disk (/dev/sda1) or something. By referring to the UUID, it ignores the enumeration, and it picks the matching partition with that UUID.
It's again important that /etc/fstab of the Devuan partition agrees.

#9 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-25 21:25:11

target file system doesn't have requested /sbin/init
mounting on /root/dev failed. no such file or directory
no init found. try passing init=bootarg.
/bin/sh: cant' access tty: job control turned off.
switched to clocksource tsc

That output would be issued by the initrd init script(s), being unhappy with /dev/sdd1 as the root file system. It thus would seem the right kernel, (hd3,msdos1)/vmlinuz, is loaded with its initrd, (hd3,msdos1)/initrd.img, but there is then a problem with the mounting of /dev/sdd1 as root file system.

Perhaps there is an /etc/fstab that disagrees? (In the Devuan partition)

This kind of pivot issues are challenging to debug, but the initrd init scripts (of Devuan) might include the ability to break the initialization procedure, and enter an interactive at a certain point. For example, you could add


to the "linux" line in the grub stanza, to gain a command shell at the "mount" point, which is just before the target root file system is mounted.

It will let you investigate things while in the pre-pivot stage. At that stage, the initrd is root file system, so don't confuse yourself about that smile. The goal would be to find out why, at that point, /dev/sdd1 is not the right file system to pivot to.

#10 Re: Other Issues » Vanilla KDE Jessie Devuan system prompts for USB pen drives. » 2018-01-25 09:35:25

You seem to have put yourself in a muddle as you first mount /dev/sdd1 onto /mnt/devuan, and then cd into /sbin rather than /mnt/devuan/sbin.

So the rest shows that your root file system (presumably your Mint) has systemd.

Perhaps you should try # chroot /mnt/devuan instead, in order to investigate the /dev/sdd1 partition as if it was the root file system.

#11 Re: Other Issues » compiling GQRX without pulseaudio » 2018-01-25 08:19:50

Yes, apparently it's missing a dependency on a libboost* package; not sure which. ASCII offers libboost1.62-dev with the missing include file.

I suppose the feature involved has a home page at

#12 Re: Installation » Cannot switch to text console on a freshly installed Devuan system » 2018-01-22 20:19:33

Maybe it has something to do with the -novtswitch argument to X:

[+1158.27s] DEBUG: Launching process 3692: /usr/bin/X ... -novtswitch

#14 Re: Hardware & System Configuration » [Solved] USBView problem » 2018-01-07 13:01:16

It seems far-fetched that an end user application would require debugfs, but you'll just need to mount it (see e.g. wikipedia)

Or, maybe an lsusb -t would give the same information.

#15 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-06 06:09:13

The more I read in on this, the more wrong I think I am, and the problem is in fact that the intel module gets unloaded, which seems to be because it can't detect the chipset. The underlying reason for that is one of many possibilities, but maybe an explicit chipset declaration in xorg.conf would make a difference. I.e., a device section including a chipset declaration.

For example, that you create an xorg.conf with the working kernel, and then use that with the new kernel, adding a chipset "i915" declaration for device "intel" .

However there may well be an "external" (to X) reason why probing fails, and why no screens are detected; even some kind of permission problem between the program (X) and the device (kernel).

#16 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-06 02:41:24

Note: I just learned that the "pinning" of ascii seems to require a "pinning" of testing as well, so I've updated my post above (#6) for that. It doesn't really make a difference tor the topic here; it's just if someone tries that tidbit on some other quest.

So, the problem relates to the nouveau module, rather. The 3.6 kernel appears to have these modules compiled into the kernel, so comparisons of kernels don't say much.

I then see some 3 lines of inquiry, including that of declaring mode lines (and backgrounding @Geoff's point). The other two are to look into the solutions around "optimus/bumblebee", and/or using an nvidia module instead of nouveau.

There may be more of course, and I don't know which approach is most likely to succeed (if any).

Declaring mode lines might be the "least intrusive", but perhaps also the least likely to succeed. The steps for this would be:

  • Use cvt 1024 768 to get a mode line to use

  • Use X -configure to generate a xorg.conf file, where you

    • remove everything except the Monitor section,

    • add the mode line twice, with the first renamed to be "0x0",

    • before installing it as /etc/X11/xorg.conf

That should be it, I think. Run startx and capture the log, unless it works of course. The renamed mode line is as an attempt to pick up on the defaulted one as per the log; though that one is likely to, if it makes anything happier, still result in rendering a 0x0 screen, which isn't too useful. You also have a couple of test variations where you exclude the one or the other of the mode lines.

Ah, you need to undo my useless suggestions about i915.

#17 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-05 12:51:47

btw, what you want to use I would guess is the PCI device 01:00.0 rather. Maybe you can check that with lspci -vvv -s 01:00 for the two kernels.

#18 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-05 12:41:48

Ah, there should be a newline; though I'm not sure that makes a difference by itself. Perhaps you should add the following line as well (with newline):

install i915 /bin/false

and probably rename the file to /etc/modprobe.d/blacklist.conf
The install line supposedly fools the kernel to run the /bin/false program as way of trying to install the module, with the desired effect of not installing it. Apparently, with "just" a blacklist line, the module might be loaded anyhow due to a dependency from another module, whereas the added install line should counteract that load path as well.

... and add it into the initramfs of course.

#19 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-05 10:56:39

Apparently the module i915 doesn't recognize the chipset. Could you please run $ lspci -vvv -s 2 with both kernels, to give us some more things to look at. Especially it should tell which module is used for your 3.6 kernel (or maybe not).

One end result that I could see in your Xorg.0.log is that it uses mode "0x0", which is a rather small display. But from that I'm guessing there might also be a way out by declaring a mode line, which would be through an /etc/X11/ with a Monitor section. This path of resurrection is windy and chilly...

Before that, you should maybe try just blackilisting i915, by making/editing the file /etc/modprobe.d/blacklist, to include:

blacklist i915

and then also make sure that it propagates into your initramfs, by

# update-initramfs -u

The wanted result from that is that i915 is not loaded, but that something else and better is loaded instead. smile

Remember to keep tab of what you do, so you can unwind if it doesn't work.

#20 Re: Off-topic » The Joke Thread » 2018-01-05 08:45:47

Indeed. Lucky the bar isn't too high, though.

#21 Re: Off-topic » The Joke Thread » 2018-01-05 06:30:02

There are two rules for success in life:

Rule 1: Don't tell people everything you know.

#22 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-04 12:34:54

No, xserver-xorg-legacy is in ASCII.

If @fsmithred meant for you bring it in from ASCII, you should make sure to "pin" ASCII as well, e.g. by a file /etc/apt/preferences.d/reluctant-ascii with the following content:

Package: *
Pin: release a=ascii
Pin-Priority: 10

Package: *
Pin: release a=testing
Pin-Priority: 10

Then you can (temporarily) add a lline to your sources.list:

deb ascii main

And install xserver-xorg-legacy using the special command

# apt-get install -t ascii --no-install-recommends xserver-xorg-legacy

However if that threatens to bring in a lot and/or remove a lot, you should probably abort, rather.

#23 Re: Off-topic » The Joke Thread » 2018-01-03 10:50:13

This post is intentionally left blank.

#24 Re: Off-topic » [Solved] Bash: Behavior of `test -x` » 2018-01-03 00:06:22

The explanation is in how the bash expands commands, and how "-x" works.

Without quotes, a phrase like

[ -x $(type -p gedit)]

gets "expanded" into the following phrase when "gedit' is missing (aka "type" returns nothing):

[-x  ]

i.e., "-x" without argument, and that succeeds. Whereas with quotes around it, the expansion is

[ -x "" ]

i.e. "-x" with an empty string as argument, and that fails.

Perhaps your statement should have been like

if type -p $program > /dev/null ; then echo UGH ; else echo NÖF; fi

That would be using the return code of "type" as condition, with 0 meaning success and non-0 meaning fail.

Board footer

Forum Software