Hello:

We may be drifting off topic here ...

But jo make my position clear: I'm not nocking Linux or Devuan, quite the contrary.

It is just that (IMO) what XFCE does by forcing the installation of (unneeded) Orage and on top of that, making it impossible to uninstall without also uninstalling XFCE altogether is contrary to the basic philosophy behind Linux:

------------------- > Do one thing and do it well. 

There are other programs/maintainers that do this same sort of thing.
Must have all learnt how to do it at the Redmond Academy.  8-D!!!

Well ...
It's the same type of different opinion than generated the need for Devuan.
systemd is also a different opinion on how to do things and also contrary to the basic philosophy behind Linux. 

Just what I am doing: openbox and tint2 work quite well for the time being.

It is of the utmost importance, not only to both of us but for how Linux will continue to develop.

Thanks a lot for your input.

Best,

A.

Hello:

I managed to fix the problem but have no idea why it happened or how to avoid it happening.

To fix it, with the USB installation in place, I booted with a Devuan ASCII 2.0.0_i386_DVD-1 installer DVD, went to Rescue Mode and reinstalled GRUB to the USB stick (/dev/sdb).

And that was it.

The drive booted into GRUB and upon logging in I installed XFCE4 which, after a reboot, started without any issues (for the time being).

rant
It's a pity that installing a desktop drags so much stuff in with it ...
eg: I did not ask for an Orage Calendar or Orage Globaltime.
But there it is.

And uninstalling it also uninstalls XFCE4 (and only XFCE4).
Reminds me of some similar MS practises we have all suffered at some time or another ...
/rant

But the problem is fixed.

Thanks for your input.

A.

Hello:

It refused to do it.
ie: failed at that point in the installation.

Retried a number of times but the only way I was able to continue and write GRUB to the USB stick was to uncheck that.
But it will not boot.

I just get a  j (lowercase) followed by a blinking underscore.

ie:  j_ 

I'm having a very hard time with this installation, no idea what's going on.
The .iso file I downloaded checked out perfectly well and the installer verified the "CD-ROM" so that's not it.

This is what I have:

groucho@devuan:~$ sudo fdisk -l /dev/sdf
[sudo] password for groucho: 
Disk /dev/sdf: 7.2 GiB, 7757398016 bytes, 15151168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000312cd

Device     Boot    Start      End Sectors  Size Id Type
/dev/sdf1  *        4096  9220095 9216000  4.4G 83 Linux
/dev/sdf2        9222142 15151103 5928962  2.8G  5 Extended
/dev/sdf5        9222144 12294143 3072000  1.5G 82 Linux swap / Solaris
/dev/sdf6       12296192 15151103 2854912  1.4G 83 Linux
groucho@devuan:~$ 

Any ideas?

Thanks in advance.

A.

Hello:

OK, one down.  =-)

I thought as much once I realised I could split / from the rest of the installation and boot my main rig from a SSD. 
Have not done it yet.

I really like Linux's ability to put things in their own place.
I recall that in another life/another OS, I put both the /swap and a /programs directory on separate partitions.
I did not trust the MS 'program files' arrangement.

Not to much use besides keeping things tidy as a lot of stuff still ended up in /program files.   
Eventually I put the swap file in the same partition as /programs as all that took a toll speedwise.

Of course, thanks for the heads up.

OK.

What worries me a bit is the actual process, eg:

1. boot Devuan ASCII (to ram?) from image dd'd to a USB stick.
2. install to the second partition (ext4) on HDD, where the first partition (NTFS) holds the XP installation.
3. make sure /, boot record and GRUB are installed to the SC Card in the slot.

Q1.: How do I make that last part of the process failsafe?

Q2.: Am I correct in assuming that installing ASCII in this manner will allow for updating?
It is something I have found booting from an *.iso with persistance will not and mess it all up.

Thanks for your input.

A.

Hello:

It would seem that acpitool is just an application that writes to /proc/acpi/wakeup, just like you would do by using echo. 

Found a helping hand at Stack Overflow and put this script to execute at boot (in rc.local)

#!/bin/sh
# set /proc/acpi/wakeup to disabled with acpitool

PATH=/sbin:/bin:/usr/sbin:/usr/bin:

for i in $(seq 1 9)
do
    /usr/bin/acpitool -W $i
done
groucho@devuan:~$ 

This is the result, sleep to all input devices seen by acpitool set to disabled:

$ acpitool -w
   Device	S-state	  Status   Sysfs node
  ---------------------------------------
  1. USB0	  S4	*disabled  pci:0000:00:1d.0
  2. USB1	  S4	*disabled  pci:0000:00:1d.1
  3. USB2	  S4	*disabled  pci:0000:00:1d.2
  4. USB5	  S4	*disabled
  5. EUSB	  S4	*disabled  pci:0000:00:1d.7
  6. USB3	  S4	*disabled  pci:0000:00:1a.0
  7. USB4	  S4	*disabled  pci:0000:00:1a.1
  8. USB6	  S4	*disabled  pci:0000:00:1a.2
  9. USBE	  S4	*disabled  pci:0000:00:1a.7
  10. P0P1	  S4	*disabled  pci:0000:00:01.0
  11. P0P2	  S4	*disabled  pci:0000:00:06.0
  12. P0P3	  S4	*disabled  pci:0000:00:1c.0
  13. BR11	  S4	*disabled
  14. BR12	  S4	*disabled
  15. BR13	  S4	*disabled
  16. P0P4	  S4	*disabled  pci:0000:00:1c.4
  17. BR15	  S4	*disabled
  18. P0P5	  S4	*disabled  pci:0000:00:1e.0
  19. GBE	  S4	*disabled  pci:0000:00:19.0
  20. SLPB	  S4	*disabled
$ 

Cheers,

A.

Hello:

There's a post here https://unix.stackexchange.com/question … 417_417965 that may indicate that you are right ...

... but it's over my pay grade, no idea how that works. =-/

Yes, the script is a solution and the one I'm using works but it's awfull.

If I cannot find a way for the command acpitool -W to address multiple entries in /proc/acpi/wakeup at once, I need a more complex script ie: with a minimum of elegance to do it with.

Any idea where I can get a sample script to modify from?

Thanks in advance.

A.

Hello:

You're welcome.

One would tend to, at first sight, agree.
But I have come to think that, to quote George and Ira Gershwin in Porgy and Bess, "It ain't necessarily so."
I have the notion that what is needed is something else and manpower may not be the problem.

A bit OT, but just a few lines:

It seems that it's not possible (and probably won't ever be) to harness the creative work of the countless thousands of programmers, developers and contributors dedicated to this fantastic project started by Linus Torvalds in a way that that they just work together and come up with just 'one' 100% functional and scalable 'distro' instead of generating gadzillionz different flavours, forks of whatever is available out there.

One of the (few) negatives of open source and free licensing is that forking projects just for the sake of having their own project - "look Ma! I rolled my own distro!!!!" - has almost become the norm.

It is highly counter-productive and there is no logical reason for it.

If you do, I'll gradly do the testing.

Cheers,

A.

Muito obrigado.
Mas eu já tenho tudo isso (custom actions) habilitado em Thunar.
O que o plug-in do nautilus-terminal faz no Nautilus aparentemente não é possível fazer em Thunar.

Thank you.
But I already have all that (custom actions) enabled in Thunar.
What the nautilus-terminal does in Nautilus apparently in not possible in Thunar.

AQ.

Hello:

AppArmor is disabled in ASCII.

groucho@devuan:~$ sudo dmesg | grep -i apparmor
[    0.010652] AppArmor: AppArmor disabled by boot time parameter
groucho@devuan:~$ 

I do not have a boot time parameter disabling apparmor (ie: not my doing), so it is probably disabled at a lower level in ASCII and it's not even in the repository.
I'm guessing that there may have been good motive for all that.

When I tried my hand at the newer post-ASCII kernel, AppArmor was installed along with it.

The newer kernel ended up complicating things in my rig so I gave up.
But on uninstalling it, AppArmor was left behind and on reboot threw a few errors in the logs.

AppArmor is a service and as such you could disable it to see what happens with haveged and eventually remove it if it gives you too much trouble.
On the other hand, I guess AppArmor could be configured not to mess with haveged.

I for one am rather weary of AppArmor (or SELinux for that matter) and it's eventual usefulness in a single user installation, where you make every possible effort to run a tight ship. I see it as being more an administrator's tool in a multi-user environment but then, what do I know?

I may well be mistaken and prove to be a god-send instead of a headache.

Cheers,

A.