The officially official Devuan Forum!

You are not logged in.

#1 Re: Hardware & System Configuration » Upgraded to chimaera; now cannot boot » 2022-03-18 20:40:54

Apologies for the late response.  It was, apparently, a hardware problem after all, although I'm not sure exactly what.  Something with the CPU or motherboard (I didn't have a spare of either that I could interchange and narrow down the problem).

#2 Re: Installation » apparmor foisted on, by default? » 2022-03-18 20:34:27

An alternate option for this particular case (apparmor) would be to create a file, e.g. /etc/apt/preferences.d/noapparmor

Package: apparmor*
Pin: release n=beowulf
Pin-Priority: -1

Change the release name if you're not using beowulf.

#3 Hardware & System Configuration » Upgraded to chimaera; now cannot boot » 2021-12-23 20:02:45

Replies: 5

I have 1 desktop that won't properly boot chimaera.  This is a machine I used once a week.
It ran beowulf fine (I may just go back to that).
I updated the apt sources to chimaera, did the upgrade and dist-upgrade successfully.  Rebooted into chimaera okay.
Some time later (the next week?) it wouldn't complete the boot -- it would go so far and then reboot itself (stuck in a reboot-loop).
I was able to boot into an older kernel, and it started up okay.
The following week, same problem.  Only the older kernel wouldn't complete its boot either.  I went to recovery mode, and was able to log in, exited and GUI started up fine.
The following week, nothing I did was successful.  Even "recovery mode" does not complete far enough to get me to login -- it reboots and reboots and reboots!  I let it continue this for over a half hour before shutting it down.

I've replaced this desktop with another one, so a fix is not something that is urgent or even necessary.  I have noticed, in attempts to get it working, that it will successfully boot jessie desktop-live USB; but will not even boot up from chimaera desktop-live USB (it does the reboot thing).
Perhaps there is some incompatible hardware ... but if that's the case I am confused why it initially worked after the dist-upgrade.  Should I just go back to beowulf?
I don't even know where to start looking for the cause ... syslog ?  kern.log ?  record a video of the boot to get the last message before it reboots ?
The chimaera desktop-live USB does work on other hardware so I don't think that it is a problem, either.

An old inxi output (showing the correct hardware at least; other info may be outdated)

  Host: fcc-audio Kernel: 5.8.0-0.bpo.2-amd64 x86_64 bits: 64 compiler: N/A 
  Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 info: xfce4-panel wm: xfwm4 
  dm: SLiM 1.3.6 Distro: Devuan GNU/Linux 3 (beowulf) 
  Type: Desktop Mobo: MSI model: FM2-A55M-E33 (MS-7721) v: 2.0 serial: N/A 
  BIOS: American Megatrends v: 11.6 date: 02/12/2015 
  Topology: Quad Core model: AMD A10-6800K APU with Radeon HD Graphics 
  bits: 64 type: MCP arch: Piledriver rev: 1 L1 cache: 192 KiB 
  L2 cache: 2048 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm 
  bogomips: 32736 
  Speed: 1993 MHz min/max: 2000/4100 MHz boost: enabled Core speeds (MHz): 
  1: 1996 2: 1996 3: 2092 4: 2044 
  Device-1: AMD Richland [Radeon HD 8670D] vendor: Micro-Star MSI 
  driver: radeon v: kernel bus ID: 00:01.0 chip ID: 1002:990c 
  Display: server: X.Org 1.20.4 driver: ati,radeon 
  unloaded: fbdev,modesetting,vesa resolution: 1024x768~60Hz 
  OpenGL: renderer: AMD ARUBA (DRM 2.50.0 / 5.8.0-0.bpo.2-amd64 LLVM 7.0.1) 
  v: 4.3 Mesa 18.3.6 compat-v: 3.1 direct render: Yes 
  Device-1: AMD Trinity HDMI Audio vendor: Micro-Star MSI 
  driver: snd_hda_intel v: kernel bus ID: 00:01.1 chip ID: 1002:9902 
  Device-2: AMD FCH Azalia vendor: Micro-Star MSI driver: snd_hda_intel 
  v: kernel bus ID: 00:14.2 chip ID: 1022:780d 
  Sound Server: ALSA v: k5.8.0-0.bpo.2-amd64 
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: Micro-Star MSI driver: r8169 v: kernel port: e000 bus ID: 01:00.0 
  chip ID: 10ec:8168 
  IF: eth0 state: down mac: xx:xx:xx:xx:xx:xx 
  Local Storage: total: 88.98 GiB used: 22.56 GiB (25.4%) 
  ID-1: /dev/sda vendor: Western Digital model: WD800JD-60LSA5 
  size: 74.53 GiB speed: 3.0 Gb/s serial: WD-XXXXXXXXXXXX rev: 1E03 
  temp: 35 C scheme: MBR 
  ID-2: /dev/sdf type: USB vendor: Toshiba model: TransMemory 
  size: 14.45 GiB serial: XXXXXXXXXXXXXXXXXXXXXXXX rev: 1.00 scheme: MBR 
  ID-1: / size: 21.88 GiB used: 8.81 GiB (40.3%) fs: ext4 dev: /dev/sda2 
  ID-2: /boot size: 938.0 MiB used: 177.7 MiB (18.9%) fs: ext2 
  dev: /dev/sda1 
  ID-3: /home size: 41.92 GiB used: 6.25 GiB (14.9%) fs: ext4 dev: /dev/sda3 
  ID-4: swap-1 size: 8.41 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda4 
  System Temperatures: cpu: 10.8 C mobo: N/A gpu: radeon temp: 0 C 
  Fan Speeds (RPM): N/A 
  Processes: 162 Uptime: 1h 48m Memory: 7.06 GiB used: 725.2 MiB (10.0%) 
  Init: SysVinit v: 2.93 runlevel: 2 default: 2 Compilers: gcc: 8.3.0 
  alt: 6/8 Shell: bash (sudo) v: 5.0.3 running in: xfce4-terminal 
  inxi: 3.0.32 

#4 Re: Installation » [SOLVED] Installing amd64 devuan beowulf 3.1 on an old imac ... » 2021-05-04 17:41:10

Adding to this thread, in case someone finds this useful, or needs the info at some later point.  To get the wifi (b43) working on this imac, I followed the steps at … ivers/b43/ under "Other distributions" to build the driver manually.
In case that page goes down, basically it came down to this:

tar xjf b43-fwcutter-018.tar.bz2
cd b43-fwcutter-018
sudo make install
cd ..
tar xjf broadcom-wl-5.100.138.tar.bz2
sudo b43-fwcutter -w /lib/firmware broadcom-wl-5.100.138/linux/wl_apsta.o

a reboot or modprobe b43 should get the device driver loaded, and wifi available.  I also had to set the wireless interface to "wlan0" in wicd preferences., but this might be done automatically if you reboot rather than use the modprobe command.

#5 Re: Installation » [SOLVED] Installing amd64 devuan beowulf 3.1 on an old imac ... » 2021-05-03 01:38:49

It actually *did* boot the amd64 live desktop dvd.  :-)   Installation went pretty smoothly from there.

This machine doesn't look like the one pictured on your link, snork.  The EFI situation could be similar though, I don't really know.  It does seem to be from the same era, though.  This is an all-in-one thing (basically the hardware is all mounted behind/under the screen.  no tower, more difficult to replace individual parts).

inxi reports this as:

System:    Host: imac Kernel: 4.19.0-14-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 
           info: xfce4-panel wm: xfwm4 dm: SLiM 1.3.6 Distro: Devuan GNU/Linux 3 (beowulf)
Machine:   Type: Desktop System: Apple product: iMac6,1 v: 1.0 serial: <> Chassis: type: 13 v: Mac-F4218FC8 
           serial: <> 
           Mobo: Apple model: Mac-F4218FC8 v: DVT serial: <> UEFI: Apple v: IM61.88Z.0093.B07.0706281250 
           date: 06/28/07 
CPU:       Topology: Dual Core model: Intel Core2 T7400 bits: 64 type: MCP arch: Core Merom rev: 6 L2 cache: 4096 KiB 
           flags: lm nx pae sse sse2 sse3 ssse3 vmx bogomips: 8645 
           Speed: 1589 MHz min/max: 1000/2167 MHz Core speeds (MHz): 1: 1101 2: 1049

#6 Re: Installation » [SOLVED] Installing amd64 devuan beowulf 3.1 on an old imac ... » 2021-05-02 23:39:01

Thank you both for the replies.

Unfortunately, I am not able to boot the amd64 debian buster netinstall cd, either.  The prompt that comes up trying to boot any amd64 disc (so far) is:
Select CD-ROM Boot Type :
(and all keyboard input is ignored at this point)

Also, thanks for the hint on using the desktop *live* installer disc.  I'll try that next, I think I should be able to get that to work.  Even if I can't boot it directly, I should be able to mount it and run the installer from it.

#7 Installation » [SOLVED] Installing amd64 devuan beowulf 3.1 on an old imac ... » 2021-05-02 19:35:44

Replies: 7

I was recently given an old imac computer.  It was running a very old mac os 10.6 and would not install a newer version.  So I've decided to put devuan on it.
The CPU (an Intel Core 2 Duo) is indeed 64-bit capable.  However, the computer refuses to boot devuan amd64 dvds.  I've tried both ascii and beowulf, full desktop and netinstall; tried from both the internal drive and an external drive.  It will not boot from these discs.  What I have been able to do so far, is install from the i686 disc, then install an amd64 kernel and boot from it.  I've been unable, at this point, to change all of the system packages over to amd64.  I can mount and read the amd64 desktop installer dvd, but can't seem to start the installer from there without booting from it (?)   I mainly want to use amd64 since it's required for most modern web browsers (most seemed to stop updating 32-bit versions several years ago).  Any advice?   I've read a few different "cross-grading" articles, but so far I've only managed to break apt/dpkg.

#8 Re: Hardware & System Configuration » System Specifications Of Users Systems? » 2018-07-21 16:37:37

I use devuan ascii daily on my desktop, 3rd gen core i5 with 32gb ram, nvidia gtx650, dual monitor, 2tb + 250gb hdd
also on a raspberry pi 3b+  16gb microsd

devuan jessie I use twice a week on laptop, it's got some amd cpu from around 2010-2012, 8gb ram and a 250gb hdd
also devuan jessie once a week on a very old desktop (actually planning to replace it with a newer desktop soon), pentium 4 with 512mb ram and a 40gb hdd

also considering to replace debian 8 with devuan ascii on a remote server (or two) that I manage for work

#9 Re: Installation » mini HowTo install ascii on a RaspBerry pi 3 B+ » 2018-07-20 17:32:16

I think this is missing a part.

While parted does show the new size:

(parted) print                                                            
Model: SD SC16G (sd/mmc)
Disk /dev/mmcblk0: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  135MB   134MB   primary  fat16        lba
 2      135MB   15.9GB  15.8GB  primary  ext4

# lsblk
mmcblk0     179:0    0 14.9G  0 disk 
|-mmcblk0p1 179:1    0  128M  0 part /boot
`-mmcblk0p2 179:2    0 14.7G  0 part /

however ... the filesystem doesn't seem quite right:

# df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root        1743136 777240    859300  48% /
devtmpfs          438328      0    438328   0% /dev
tmpfs              88764   1200     87564   2% /run
tmpfs               5120      4      5116   1% /run/lock
tmpfs             177520      0    177520   0% /run/shm
/dev/mmcblk0p1    130798  35754     95044  28% /boot

/dev/root size should be much larger, it is only reporting 1,743,136 KB (~1.7 GB).

#10 Re: Other Issues » Devuan Ascii - Suspend change? » 2018-07-02 03:05:22

To reply to my self (or is it preferred to edit the original post):
Apparently this didn't begin with the Ascii upgrade (which I did 2 weeks ago) -- /var/log/pm-suspend.log has a date of Fri Jun 29 (morning wakeup time).  There's no record of Fri Jun 29 (night sleep time) or Sat Jun 30, Sun Jul 1 in /var/log/pm-suspend.log at all.  This is likely when the suspend/resume hooks stopped running.  This seems strange to me.  I have rebooted in the meantime, which did not correct the issue.  On Jun 29 I did remove mono and a bunch of things along with it... I'll see if any of that is related.  So at this point it seems less likely a bug and more likely something I've done to my own system.

[Mon Jul 2 AM edit]
So last night I directly ran /usr/sbin/pm-suspend instead of /usr/bin/xfce4-session-logout --suspend
The result was the hooks were called on suspend/resume, /var/log/pm-suspend.log was updated, screen was not locked on resume (of course).
I suppose I could change my suspend routine to call /usr/bin/xflock4 then run /usr/sbin/pm-suspend, after granting my user account the ability to run /usr/sbin/pm-suspend .  Still unclear as to what changed with xfce4-session-logout .

#11 Other Issues » Devuan Ascii - Suspend change? » 2018-07-01 19:44:57

Replies: 1

In Jessie this worked:
/usr/bin/xfce4-session-logout --suspend

before suspending, the system would call
which I have unmount certain things...

Now in Ascii, the /etc/pm.d/sleep/50_unmount is no longer called when suspending.
In fact, none of the files in /etc/pm.d/sleep are called when resuming from suspend, either.
Is this a bug or intentional change, or do I have something else misconfigured?

I can work around this, but just wondering what has changed or if /etc/pm.d/sleep/* has been abandoned for some other way of calling scripts on suspend/hibernate/thaw/resume.

#12 Installation » my jessie -> ascii dist-upgrade experience » 2018-06-12 01:12:34

Replies: 1

First ran on a (backed-up) virtual machine.  The only "major" problem was with wicd, a missing file /etc/dbus-1/system.conf -- I copied from my host system and resumed the upgrade... it finished, rebooted, all seems to be okay.

Then backed up my "baremetal" system.  Some other errors (depencencies?) partway through, had to run a "apt-get --fix-broken install" then resume the dist-upgrade.  Same issue with wicd, copied system.conf from most recent backup and resumed upgrade.  Rebooted, no gui.  Reinstalled nvidia driver, rebooted, all seems okay.  Remmina was uninstalled.  Opened synaptic to some error, had to run "dpkg --configure -a", now synaptic works.  Had to force specific remmina version (something about backports?), now it is okay.  Had to redo some other minor tweaks, but overall a rather painless experience.  Just kind of curious about that wicd thing, it seems the system.conf is deleted too early in the upgrade process?

I know this is supposed to work, in theory, but is it recommended to try debian 8 -> devuan ascii upgrade on a remote (ssh) machine?  Will I lose ssh connectivity during the upgrade process, what other things should I be aware of before attempting it?

Again, thanks to the developers for their work in this project, and the people who provide forum support / other chat.

Board footer

Forum Software