You are not logged in.
Hello:
Maybe that's the problem?
Indeed it was. 8^°
ie: pebkac
Fixed that.
$ cat /etc/default/su
# restore the old 'su' behaviour
# no 'su-' | just use 'su' as before
# see https://files.devuan.org/devuan_beowulf/Release_notes.txt
# ALWAYS_SET_PATH yes
$
Now, with su and sudo:
[root@devuan isos]# sudo ./fatstick.sh
/dev/sdg: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31
Checking that no-one is using this disk right now ... OK
Disk /dev/sdg: 1.89 GiB, 2032664576 bytes, 3970048 sectors
Disk model: Storage Device
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: 0x23927a24
Old situation:
Device Boot Start End Sectors Size Id Type
/dev/sdg1 * 64 2333951 2333888 1.1G 17 Hidden HPFS/NTFS
/dev/sdg2: Created a new partition 2 of type 'W95 FAT32 (LBA)' and of size 798.9 MiB.
Partition #2 contains a vfat signature.
/dev/sdg3: Done.
New situation:
Disklabel type: dos
Disk identifier: 0x23927a24
Device Boot Start End Sectors Size Id Type
/dev/sdg1 * 64 2333951 2333888 1.1G 17 Hidden HPFS/NTFS
/dev/sdg2 2333952 3970047 1636096 798.9M c W95 FAT32 (LBA)
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
[root@devuan isos]#
I think it works properly.
ie: as advertised -> no small feat.
Just one thing ...
At some point towards the end of the job, I think (?) the stick is unmounted and then remounted.
Not sure of that.
The first time I tried the script it ended with a a pop-up with an error and the second partition was not formatted. (unknown)
I then ran the script again and it ended with a formatted FAT32 partition, no errors.
To check, I ran the whole process again: blanked the SD card, ran the format / image writing applications and then the script.
Although the same thing happened ie: the pop-up with an error for writing the second partition, on checking I saw that the second partiton had been formatted.
You may want to test and see if a short pause somewhere between the creation of the second partition and formatting it to FAT32 would avoid that.
Let me know if you need anything else.
Best,
A.
Hello:
"su" vs. "su -" problem?
Don't think so.
I have used su - since it changed from su.
ie: I never use su and my use of sudo is for a set of specific commands.
... likely the environment issue (root vs. user) ...
... run root programs on the user's desktop like you used to do ...
I checked.
It would seem I probably did that long ago:
$ cat /etc/default/su
# restore the old 'su' behaviour
# no 'su-' | just use 'su' as before
# see https://files.devuan.org/devuan_beowulf/Release_notes.txt
ALWAYS_SET_PATH yes
$
Maybe that's the problem?
It should be no?
... try to run a graphical app as root.
Right.
Examples:
# thunar
thunar: Failed to initialize Xfconf: Cannot autolaunch D-Bus without X11 $DISPLAY
(thunar:4055): Gtk-WARNING **: 11:42:29.809: cannot open display:
#
# jpilot
(jpilot:4525): Gtk-WARNING **: 11:51:05.663: cannot open display:
#
# synaptic
Failed to initialize GTK.
Probably you're running Synaptic on Wayland with root permission.
Please restart your session without Wayland, or run Synaptic without root permission
#
... need to make "root" have access and permissions to use "non-root"'s X display.
Yes, seems that it was what thunar was bitching about. (?)
... use pgrep -a Xorg to learn the pathname for the authority file ...
$ pgrep -a Xorg
2204 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/slim.auth vt07
$
Then run with ...
Like this? (checking first)
$ XAUTHORITY=/usr/lib/xorg/Xorg DISPLAY=:0 ./fatstick.sh
I'll return in a while ...
Best,
A.
Hello:
... the delay ...
No problem, seems you are quite busy.
... protocol:
Done.
Used a 2.0GB SD Card on a generic USB SD/Micro SD Card reader and wrote a Chimaera i386 *.iso.
No problems, was abe to boot my 1000HE both from SD Card in slot and SD Card in reader.
disks and gparted reported as expected.
Labelled the script 'fatstick', made it executable.
Ran is as root, I have specific permissions for sudo and too lazy to add another entry in sudoers.d.
$ sudo ./fatstick.sh
Sorry, user is not allowed to execute './fatstick.sh' as root on localhost.
$
But I get an error/warning:
# ./fatstick.sh
(yad:2866): Gtk-WARNING **: 09:21:27.813: cannot open display:
#
Something in the script?
Best,
A.
Hello:
... added a 32G sd card ...
Fortunately, your eee model can boot from that size card.
Much to my chagrin, my 1000HE's BIOS won't see a USB storage device larger than 8.0Gb, that's (?) the limit for booting from USB.
I asked at Asus tech support but they 'don't know'.
Ventoy solves that problem.
The system, once up and running, can see and access a 64Gb USB3.0 drive without issues and (I presume) higher capacity.
... (or my win XP install which I keep only for nostalgia).
Glad to see I'm not the only one. 8^°
Best,
A.
Hello:
... run fine on every kernel since 3.16 ...
I expect that it would be the same with my 1000HE which is ca. 2009.
... to just include all relevant new security updates ...
No idea, but I expect that it could be possible.
From what little I understand, it seems that the task would involve compiling a kernel from source but including only what you need for your netbook.
ie: tailored for your target hardware and compiled on it.
There's also the question of who is going to do it and then maintain it.
For starters, is there a large enough user base?
There used to be specific eee kernels / distributions but as the differnet models were mothballed, they lost all traction.
Interesting side note:
Asus does not have the eee series in theri tech support databases.
I have recently been able to get a very important boost for my netbook by enabling zram and generating a /dev/zram0 swap file.
... features or hardware that the asus eee pc will never know ...
The Asus eee series is not alone in this.
Absolutely every discontinued and perfectly working netbook / notebook is in the same situation.
All victims of the decades old WinTel consortium. (see what is going on with Win 11 these days)
Best,
A.
Hello:
... why is the latest i386 kernel from there 330MB ...
In one word: bloat
eg:
Devuan Chimaera netinstall *.iso: 372.00 MB - UEFI installer: 00.754 MB
Devuan Daedalus netinstall *.iso: 477.80 MB - UEFI installer: 23.00 MB
30X more code has been added to the UEFI partition on the road between Chimaera and Daedalus.
Does anyone really know exactly what all that added code does?
My 2Gb 1000HE runs on Devuan Beowulf with a backported Chimaera kernel:
$ uname -a
Linux eee-dev3 5.10.0-0.deb.10.16-686-pae #1 SMP Debian 5.10.127-2-bpo10+1 (2022-07-28) i686 GNU/Linux
$
Given the 2Gb max RAM access, I could probably do without the -pae but it is already there and for the time being I'd rather not muck around with things I don't know enough/much about.
That said, I have recently been wondering about the eventual benefits (?) of upgrading the kernel but have not been able to find sufficient reason to do so.
It has been a long time since I travelled with my 1000HE; these days it stays at home doing coffee roasting duty with no issues.
Only goes on line behind a passive Gbit desktop switch once in a blue moon if I need to test something.
I look forward to reading about how you fared with this.
Best,
A.
Hello:
... Microsoft pushing even far ...
So ...
How is that a surprise?
ie: to you or anyone else
... real problem are ...
+1
Best,
A.
Hello:
... anyone uses Mintstick ...
I don't use mintstick, last time I ran Mint was ~ 8 years ago.
It but I downloaded the cmd line version from the Devuan repository and installed it.
Drags along gir1.2-polkit-1.0 gir1.2-udisks-2.0 gir1.2-xapp-1.0 python3-gnupg python3-parted
Q: does it work better than dd?
You may recall I had a series of issues when I tried to dd an *.iso file to a 4Gb SD card/8Gb USB stick to use in my (non UEFI box) not long ago.
Had to jump through a lot of hoops to get it done. See here.
If you post instructions I can give mintstick a try then run your script and report.
ie: only a 64Gb stick available for testing.
Best,
A.
Hello:
@greenjeans
... so win/win.
Likewise.
(Shit, man ... made me blush.)
@golinux
... radical change ...
... applications like the DE
I'm quite aware of the implications re: Devuan being Debian without systemd.
[OT]
But I don't think that is a long lasting status quo.
The weave that keeps it in place is permanently being pecked at by the usual suspects.
It will eventually come loose.
When it does (no, no if) Devuan+all derivatives will need a fall back position.
[/OT]
That said, a basic Devuan installation (like a netinstall), would (by definition?) not have a DE or a WM for that matter.
So no radical change there.
Just a meta-package / script or whatever.
It would be downloaded separately and applied post-installation.
... a netinstall script, right?
Seems like it would be like that but for a Devuan netinstall.
ie: systemd less.
I really don't know how much of that script would have to be adjusted to work on a Devuan netinstall.
Thanks to all for your input.
Best,
A.
Hello:
... mistake to have posted that nonsense ...
Ain't necessarily so.
If XFCE is (like you seem to suggest) not going to the chopping block, all the more reason to find a sleek alternative for Devuan.
This because whatever sleekness XFCE may have once had is long (long) gone.
The alternative need not be incorpporated into the *.iso.
Ideally, some sort of #! Openbox meta-package to download and apply to a basic Devuan installation.
So I'd say that your cryptic comment can stay.
It has served a purpose while at the same time serendipity has proven its existence.
Once again.
Best,
A.
Hello:
... ballsy choice for Devuan ...
I think it fits Devuan just right.
In the true Linux spirit.
... could sure help with implementation ...
That would be great.
... would add a lot of complexity to the *.iso ...
You know better than I, but I was not referring to an out of the box thing, ie: incorporated in the *.iso.
What I had read about (if I undestood it correctly) was a script you could download and run on an basic Debian installation.
ie: one without a DE/WM, after the installation was finished and everything else was running as expected.
Found the post by HoaS here.
Have a look and tell us what you think.
Maybe a different thread?
Edit:
https://archive.org/details/sharpbang-b … 386.hybrid
https://archiveos.org/sharpbang/
Best,
A.
Hello:
As sometimes happens, we are veering away from the original topic. 8^°
... my vote goes to MATE.
The best (albeit not a DE) I ever came across was the one Philip Newborough set up in the original #! Waldorf.
Hands down: fast, light, nimble and absolute lack of useless bloat.
XFCE lost it, long ago.
Bloated, bugsy ...
I will not be taking it beyond the present version.
I recall seeing (at one time or another) a post (somewhere) making reference to a script than would put the #! OB WM on a basic Debian installation.
I vaguely remember that HoaS had something to do with it.
ie: the script or the reference, cannot recall.
Best,
A.
Hello:
... doesn't do squat ...
So I have discovered, thanks for the heads-up.
I had a start-up entry in xfce+Session and Startup+Application Autostart and unchecked it.
Ran through all my routines and they worked perfectly well, so I just uninstalled it.
Worst case, I'd have to re-install it.
... supposed to be securely storing the users passwords that you save when browsing ...
I would not be caught dead doing that. 8^°
... uninstalling the pkcs package ...
That I don't have.
The only gnome thing I have is the gnome-disk-utility which has given me no problems.
I have found it quite useful but it comes with a (built-in?) gnome-disk-utility notification plugin which I never set to startup.
You will find it in /usr/libxec/gsd-disk-utilty-notify.
That's that, so I'll mark this one solved.
Best,
A.
Hello:
I don't have ...
I deleted them all, no noticeable ill effects.
It would seem that they are a remnant / consquence of bad shutdowns, remaining cached because the system was unable to flush them.
See here.
But then, the next post has a bit that relates directly to gnome-keyring being the culprit:
gnome-keyring will create the control socket in ~/.cache/keyring-* when it cannot access the XDG_RUNTIME_DIR location. This happens every time on slackware, due to the pam stack configuration in the /etc/pam.d/system-auth file. Specifically the last line where "pam_gnome_keyring.so auto_start" is run (this step creates the control socket).
The problem is that here in system-auth, the gnome-keyring auto_start line is *always* called before pam_elogind.so, so it will never have the XDG_RUNTIME_DIR available and will always create a socket in ~/.cache instaed. This can then lead to stale files and whatnot as you see.
greenjeans says it is broken and this is probably (?) part of the damage.
I concurr with another poster's opinion in that thread ...
I'm allergic to residual and redundant cache and tmp files (IMHO they should be overwritten when new files are created or deleted after shutting down the program in question).
... but the solution posted does not apply to Devuan.
ie: there is no /etc/pam.d/system-auth file in my system
So maybe the solution is getting rid of gnome-keyring.
Q: how do I know if it actually being used?
Best,
A.
Hello:
... never seen anything in ~/.cache that couldn't be deleted.
That's what I think, but the fact that they are cached makes me doubt.
ie: why are they not cleared on reboot?
... zero keyring files in mine ...
... Bleachbit ...
... basically wipes everything out ...
Good to know.
... uninstalled the gnome-keyring ...
... badly broken ...
Why am I not surprised?
This is what I have installed in terms of 'keyrings':
$ apt list | grep installed | grep keyring
debian-archive-keyring/stable,stable,now 2023.3+deb12u2 all [installed]
devuan-keyring/stable,stable,now 2023.05.28 all [installed]
gnome-keyring/stable,now 42.1-1+b2 amd64 [installed]
python3-keyring/stable,stable,now 23.9.3-2 all [installed,automatic]
python3-keyrings.alt/stable,stable,now 4.2.0-1 all [installed,automatic]
$
Q: just how many keyrings do I need for my desktop?
Best,
A.
Hello:
This morning I came upon over 145 keyring-* sub-folders in my /home/user/.cache folder.
The contents of these folders fall into two categories: control and pkcs11.
What calls my attention is that they are quite dated:
2018 (1)
2019 (91)
2020 (12)
2021 (2)
2022 (1)
2023 (1)
2024 (29)
2025 (10)
As you can see, only 10 are from 2025.
I ssh into a NAS and the VM where my Pi-Hole / unbound set up runs and sometimes into my fibre router to check what evil the telco is up to.
Q1:
Why are they cached?
Q2:
Can these folders be directly deleted?
If not, how are they be cleared?
These are the backends I have in my system:
$ keyring --list-backends
keyring.backends.SecretService.Keyring (priority: 5)
keyring.backends.chainer.ChainerBackend (priority: 10)
keyrings.alt.file.PlaintextKeyring (priority: 0.5)
keyring.backends.fail.Keyring (priority: 0)
keyrings.alt.file.EncryptedKeyring (priority: 0.6)
$
Please advise.
Best,
A.
Hello:
... meant that the init script does not start ...
... enable it with update-rc.d.
Right ... 8^°
Sorry, my bad.
Yes, update-rc.d uses the INIT INFO fields and is mandatory when adding a script to /etc/init.d.
Best,
A.
Hello:
... not actually in Devuan repos ...
... not sure how to propose it.
... be enabled by you ...
No, not me. 8^D!
I'm just an interested observer.
That would be one of the admins (@golinux / @fsmithred / @Ralph.Ronnquist).
But I don't know what the process is / entails.
Best,
A.
Hello:
@Raulcla
@Kristof12
The site's search function is quite useful.
You may want to consider trying it out.
That said, have a look at these two threads:
https://dev1galaxy.org/viewtopic.php?id=2918
https://dev1galaxy.org/viewtopic.php?id=2449
TL;DR
Devuan is a systemd-less distribution.
snapd requires systemd -> because of this, snapd is a banned package.
Hence the lack of snapd or anything snap related in the Devuan repository.
Best,
A.
Hello:
... available because ...
... excalibur i386 live-isos and included xfe.
Good to know.
I have no hurry, the automount was needed for my U24 box but these days I can manage with a Ventoy *.iso, but it is a good addition to xfe.
Also have to carefully consider the convenience of upgrading the 1000HE to Daedalus / Excalibur.
Kernels suffer more and more bloat with each release
But the 1000HE's hardware is the same one as (quite obviously) nothing has changed since 2009.
Given the use it has, I'm not sure I see any advantage in upgrading.
... chance that the excal deb will install.
The one I'd want is 2.1 with the automount and all the bug fixes.
... probably have to get the upstream non-debianized source ...
I've written to the author asking what he has available.
I'll post back if/when I hear from him.
... package it or compile it ...
I thought as much. 8^°
Thanks for your input.
Best,
A.
Hello:
... ported the zramen script from Void Linux ...
... comes with a working init script for Daedulus.
Thanks for doing that for the team Dev1.
Best,
A.
Hello:
Still working on my Asus 1000HE. 8^°
My netbook runs on Devuan Chimaera and the lightest file manager ever I found (besides mc) was xfe 1.43.1-1 i386.
Worked great and never looked back.
This morning I got a notification from the author about a request I made (back in ascii days) for an automount feature which has been incorporated to lhe latest version (2.1).
**[feature-requests:#237] Automount devices in Xfe**
**Status:** open
**Group:** v1.0_(example)
**Labels:** automount
**Created:** Tue Dec 03, 2019 12:48 PM UTC
**Last Updated:** Sun Mar 14, 2021 05:28 PM UTC
**Owner:** nobodyXfe now has an (optional, Linux only) automounter. You can configure it in Xfe / Edit / Preferences / Settings.
The thing is that I don't see any i386 version in the Devuan repositories but I can find version 2.0.1-2 in the Debian repositories (Trixie) so I expect that the latest version ie: xfe 2.1 i386 will eventually (?) be available there also.
There are also i386 versions available for Buster, Bullseye and Bookworm, all of them ideal for undepowered i386 hardware such as the 1000HE.
I doubt xfe2.0.1-2 i386 would install without issues in my Devuan Chimaera netbook.
Or maybe not ...
Q: Is there a way to get that done?
Best,
A.
Hello:
... my https://github.com/eylles/zram-service script ...
Yes, I saw it.
But this is for an undepowered (Intel Atom N280/2Gb) ca. 2009 netbook for which I need a simple/easy solution.
The zramctl command can set up all the parameters I need in a jiffy in case the default ones are not suitable or I want to experiment.
Thanks for your input.
Best,
A.
Hello.
... troubleshoot this further?
No need.
In true (and time proven) Linux fashion I found a way out.
ie: by doing it in a different manner.
For those interested, the whole explanation is here.
TL;DR
For whatever reason, it seems the problem of getting the/a zram script to start in /etc/init.d has been doing the rounds for a while.
I could not find out why.
The solution is to start zram, setting the parameters and the zramswap file directly from rc.local.
And Bob's your uncle.
To test, I just dropped in the lines posted but (just to be neat) I'll write up a short script as a replacement for that.
Best,
A.
Hello:
Still working on my Asus 1000HE. 8^°
I have set up zram / zramswap with this script which I found referenced here.
Just in case, I added both the shebang (#!/bin/sh) and the usual PATH= variable as I saw it was missing.
I then named it zramswap, copied it to /etc/init.d, made it executable and did update-rc.d zramswap defaults.
The problem I have is that it does not start at boot and I can't figure out why.
But I can start it from a terminal:
$ sudo zramswap start
Setting up swapspace version 1, size = 1002.6 MiB (1051303936 bytes)
no label, UUID=05decff9-d90e-4db3-ae9d-a65484a3462c
$
$ sudo swapon -s
Filename Type Size Used Priority
/dev/sda5 partition 12595196 0 1
/dev/zram0 partition 1026664 0 20
~$
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda5 partition 12595196 0 1
/dev/zram0 partition 1026664 0 20
$
$ sudo zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 1002.6M 4K 74B 4K 2 [SWAP]
$
I can't get anything from running the script in a terminal either:
# /etc/init.d/zramswap start > /tmp/zramswap.log 2>&1
#
# cat /tmp/zramswap.log
# <- nothing to see here ...
Just in case ...
#!/bin/sh
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides: zramswap
# Required-Start: $syslog $time $remote_fs
# Required-Stop: $syslog $time $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Linux zramswap setup
# Description: Debian init script for zramswap
### END INIT INFO
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/sbin/zramswap
PIDFILE=none
_is_active() {
$DAEMON status >/dev/null 2>&1
return $?
}
do_start_prepare() {
if _is_active; then
log_warning_msg "$NAME is already active"
exit 3
fi
}
do_start_cmd_override() {
$DAEMON start
}
do_stop_prepare() {
if ! _is_active; then
log_warning_msg "$NAME is not active"
exit 3
fi
}
do_stop_cmd_override() {
$DAEMON stop
}
do_status_override() {
$DAEMON status
}
do_restart_override() {
if _is_active; then
$DAEMON restart
else
$DAEMON start
fi
}
How to troubleshoot this further?
Thanks in advance.
Best,
A.