You are not logged in.
- Topics: Active | Unanswered
#1601 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-02 20:15:34
Hello:
... suspect of a power supply problem.
I don't think so.
In my Devuan ascii workstation ...
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64 GNU/Linux
groucho@devuan:~$ groucho@devuan:~$ lsmod | grep -i usb
usb_storage 73728 2 uas
usbserial 49152 1 pl2303
usbhid 53248 0
hid 122880 2 hid_generic,usbhid
usbcore 253952 10 usbhid,usb_storage,ehci_hcd,uhci_hcd,usbserial,xhci_pci,uas,pl2303,xhci_hcd,ehci_pci
scsi_mod 225280 11 aic7xxx,sd_mod,usb_storage,scsi_transport_sas,mptscsih,libata,scsi_transport_spi,uas,sr_mod,sg,mptsas
usb_common 16384 1 usbcore
groucho@devuan:~$ ... when I plug the drive in, I get this:
groucho@devuan:~$ sudo dmesg -C
groucho@devuan:~$ sudo dmesg
[ 497.160012] usb 4-6: new high-speed USB device number 6 using ehci-pci
[ 497.313765] usb 4-6: New USB device found, idVendor=05e3, idProduct=0702
[ 497.313769] usb 4-6: New USB device strings: Mfr=2, Product=3, SerialNumber=0
[ 497.313772] usb 4-6: Product: TS0MHDENC
[ 497.313775] usb 4-6: Manufacturer: Transcend
[ 497.314304] usb-storage 4-6:1.0: USB Mass Storage device detected
[ 497.314372] usb-storage 4-6:1.0: Quirks match for vid 05e3 pid 0702: 520
[ 497.314424] scsi host8: usb-storage 4-6:1.0
[ 498.339040] scsi 8:0:0:0: Direct-Access SAMSUNG MP0402H 0811 PQ: 0 ANSI: 0
[ 498.339464] sd 8:0:0:0: Attached scsi generic sg6 type 0
[ 498.340280] sd 8:0:0:0: [sdf] 78242976 512-byte logical blocks: (40.1 GB/37.3 GiB)
[ 498.341520] sd 8:0:0:0: [sdf] Test WP failed, assume Write Enabled
[ 498.342771] sd 8:0:0:0: [sdf] Cache data unavailable
[ 498.342776] sd 8:0:0:0: [sdf] Assuming drive cache: write through
[ 498.355294] sdf: sdf1
[ 498.359398] sd 8:0:0:0: [sdf] Attached SCSI disk
groucho@devuan:~$ ... when I attach a 2.5" disk, I see it ...
I see it as /dev/sg6:
groucho@devuan:~$ sudo sg_map -sd
/dev/sg0
/dev/sg1 /dev/sda
/dev/sg2 /dev/sdb
/dev/sg3 /dev/sdc
/dev/sg4 /dev/sdd
/dev/sg5 /dev/sde
/dev/sg6 /dev/sdf <--- here it is
groucho@devuan:~$ ... also 'sg_scan -i' ...
I also see it there:
groucho@devuan:~$ sudo sg_scan -i
/dev/sg0: scsi1 channel=0 id=0 lun=0 [em]
TSSTcorp CDDVDW SH-222AB SB00 [rmb=1 cmdq=0 pqual=0 pdev=0x5]
/dev/sg1: scsi5 channel=0 id=0 lun=0 [em]
ATA KINGSTON SV300S3 BBF0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg2: scsi7 channel=0 id=0 lun=0
IBM-ESXS VPBA073C3ETS11 N A496 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg3: scsi7 channel=0 id=1 lun=0
SEAGATE ST3300555SS T107 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg4: scsi7 channel=0 id=2 lun=0
IBM-ESXS GNA073C3ESTT0Z N BH0D [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg5: scsi7 channel=0 id=3 lun=0
ATA SEAGATE ST32500N 3AZQ [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg6: scsi8 channel=0 id=0 lun=0 [em]
SAMSUNG MP0402H 0811 [rmb=0 cmdq=0 pqual=0 pdev=0x0] <---- here it is
groucho@devuan:~$ So I think we can rule out any power supply related issues.
The Transcend TS0MHDENC controller (05e3 pid 0702: 520) has ID 05e3:0702 and uses the GL811E chip made by Genesys Logic, which is supported in the Debian kernel through the usb-storage module.
Si it would seem that the problem is that the needed module is not part of the image.
Is there a way to load it or a driver?
Thanks a lot for your input.
Cheers,
A.
#1602 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-02 12:24:45
Hello:
... insert the drives ...
... with the 5v ...
... what you get with 'dmesg' ?
I have to check again, see below.
... the module was not compiled ....
Yes, I think you're right.
Support was not compiled into the kernel.
modinfo usb-storage
It confirms that usb-storage is not in the system:
groucho@rpidevuan:~$ sudo modinfo usb-stotage
[sudo] password for groucho:
modinfo: ERROR: Module usb-stotage not found.groucho@rpidevuan:~$ find /lib/modules -name \*usb-storage\*.ko
groucho@rpidevuan:~$This si a config for sub-storage, on kernel 5.4.x:
[
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_REALTEK=m
CONFIG_REALTEK_AUTOPM=y
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m
CONFIG_USB_UAS=m... the SCSI sg driver..
It is part of sg3_utils
Just installed it.
--- snip ---
The following NEW packages will be installed:
libsgutils2-2 sg3-utils
--- snip ---Added it to /etc/modules and rebooted:
groucho@rpidevuan:~$ lsmod
Module Size Used by
ipv6 516096 24
sg 36864 0
brcmfmac 274432 0
brcmutil 16384 1 brcmfmac
sha256_generic 20480 0
cfg80211 741376 1 brcmfmac
rfkill 32768 1 cfg80211
snd_bcm2835 40960 0
snd_pcm 126976 1 snd_bcm2835
snd_timer 36864 1 snd_pcm
snd 90112 3 snd_timer,snd_bcm2835,snd_pcm
sdhci_iproc 16384 0
vchiq 352256 1 snd_bcm2835
uio_pdrv_genirq 16384 0
uio 24576 1 uio_pdrv_genirq
groucho@rpidevuan:~$ This is dmesg with the sg module loaded:
groucho@rpidevuan:~$ dmesg | grep -i "error\|warning\|fail\|segfault\|fatal"
[ 0.812942] Error: Driver 'sdhost-bcm2835' is already registered, aborting...
[ 2.421514] random: 3 urandom warning(s) missed due to ratelimiting
[ 2.846463] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 2.852017] cfg80211: failed to load regulatory.db
groucho@rpidevuan:~$groucho@rpidevuan:~$ dmesg | grep -i usb
[ 0.104319] usbcore: registered new interface driver usbfs
[ 0.104417] usbcore: registered new interface driver hub
[ 0.104568] usbcore: registered new device driver usb
[ 0.303073] usbcore: registered new interface driver lan78xx
[ 0.305142] usbcore: registered new interface driver smsc95xx
[ 0.770854] dwc_otg 3f980000.usb: DWC OTG Controller
[ 0.772811] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[ 0.774815] dwc_otg 3f980000.usb: irq 9, io mem 0x00000000
[ 0.780952] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.782967] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.784977] usb usb1: Product: DWC OTG Controller
[ 0.786941] usb usb1: Manufacturer: Linux 4.16.14-v8+ dwc_otg_hcd
[ 0.788925] usb usb1: SerialNumber: 3f980000.usb
[ 0.791621] hub 1-0:1.0: USB hub found
[ 0.796676] usbcore: registered new interface driver usb-storage
[ 0.823327] usbcore: registered new interface driver usbhid
[ 0.825439] usbhid: USB HID core driver
[ 1.203380] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 1.394850] usb 1-1: New USB device found, idVendor=0424, idProduct=2514
[ 1.397220] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.400429] hub 1-1:1.0: USB hub found
[ 1.687369] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 1.777885] usb 1-1.1: New USB device found, idVendor=0424, idProduct=2514
[ 1.780230] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.783450] hub 1-1.1:1.0: USB hub found
[ 2.663363] usb 1-1.1.1: new high-speed USB device number 4 using dwc_otg
[ 2.754116] usb 1-1.1.1: New USB device found, idVendor=0424, idProduct=7800
[ 2.756640] usb 1-1.1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2.971360] usbcore: registered new interface driver brcmfmac
groucho@rpidevuan:~$ No USB related errors and drive not detected/recognised.
ie: idVendor=05e3, idProduct=0702
Thanks in advance,
A.
#1603 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-01 18:23:25
Hello:
There are there arm64 devuan images for rpi3
Yes, I have installed the one I pointed out in my OP.
groucho@rpidevuan:~$ uname -a
Linux rpidevuan 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux
groucho@rpidevuan:~$ Till I get my cable/adaptor, I have managed to learn some SSH and am working on my RPi ascii from my Devuan ascii workstation.
Reminds me of my long gone DOS 5.0 days.
But ...
I need to have the usb-storage module loaded so as to be able to use my external usb drives with the RPi, but it seems that it's not part of the image.
groucho@rpidevuan:~$ lsmod | grep usb
groucho@rpidevuan:~$ groucho@rpidevuan:~$ lsmod
Module Size Used by
sg 36864 0
ipv6 516096 24
brcmfmac 274432 0
brcmutil 16384 1 brcmfmac
sha256_generic 20480 0
cfg80211 741376 1 brcmfmac
rfkill 32768 1 cfg80211
snd_bcm2835 40960 0
snd_pcm 126976 1 snd_bcm2835
snd_timer 36864 1 snd_pcm
snd 90112 3 snd_timer,snd_bcm2835,snd_pcm
sdhci_iproc 16384 0
vchiq 352256 1 snd_bcm2835
uio_pdrv_genirq 16384 0
uio 24576 1 uio_pdrv_genirq
groucho@rpidevuan:~$ And seems that it cannot/will not be installed.
root@rpidevuan:/home/groucho# modprobe usb-storage
root@rpidevuan:/home/groucho# lsmod | grep usb
root@rpidevuan:/home/groucho# lsmod
Module Size Used by
sg 36864 0
ipv6 516096 24
brcmfmac 274432 0
brcmutil 16384 1 brcmfmac
sha256_generic 20480 0
cfg80211 741376 1 brcmfmac
rfkill 32768 1 cfg80211
snd_bcm2835 40960 0
snd_pcm 126976 1 snd_bcm2835
snd_timer 36864 1 snd_pcm
snd 90112 3 snd_timer,snd_bcm2835,snd_pcm
sdhci_iproc 16384 0
vchiq 352256 1 snd_bcm2835
uio_pdrv_genirq 16384 0
uio 24576 1 uio_pdrv_genirq
root@rpidevuan:/home/groucho# Is there a way around this problem?
Edit:
I have been running some tests.
1.
The drives draw 700mA and work perfectly well in both my workstation and netbook running Devuan ascii but only using the provided power cable.
ie: a second USB cable to give +5.00v through an ad hoc plug. I have two of them and both exhibit the same behaviour.
2.
The drives' controller chipset is identified by lsusb as ID 05e3:0702 Genesys Logic, Inc. USB 2.0 IDE Adapter [GL811E], which is supported by the kernel using the usb-storage module. I guess it makes sense that they are not recognised as the needed module is not present. (?)
3.
My two other external HDDs (USB3.0) work without issue on the RPi3B+3 but the controllers use another chipset identified as ID 043e:70f5 LG Electronics USA, Inc. External HDD.
They are 500Gb USB3, not much sense to use them with my RPi.
Thanks in advance.
A.
#1604 Re: ARM Builds » ascii installer-ARM64 question » 2020-04-28 21:09:51
Hello:
... alpine linux has ready images for raspi3 ...
While looking around for information regarding Alpine Linux, I came across this.
Alpine Raspberry PI
This is a system install of Alpine linux for Raspberry Pi 3B, 3B+ and 4 image ready to burn to an SD card via balenaEtcher
(there's no need to gunzip image).
The image automatically setup and configures:
root user [pwd: raspberry]
pi user [pwd: raspberry]
ethernet
wifi (edit wpa_supplicant.conf in the boot partition, on first boot it will be copied)
bluetooth
avahi
swap
openssh server
root partition auto-expand on first bootI'll give it a try as it seems to be quite straightforward.
Cheers,
A.
#1605 Re: ARM Builds » ascii installer-ARM64 question » 2020-04-28 16:41:48
Hello:
... could not tell you differences in the images hosted ...
I see.
... spend a some time educating yourself ...
Indeed ...
That's what I am doing with/in Devuan, where I arrived after a few years of going through a few of the mainline Linux distributions, both *.deb and *.rpm based.
But I have to draw a line somewhere as I am not a software chap, more a hardware one.
Tech support helped me make a living when my degree in architecture would not.
Reasonably well educated (for what I needed) in *.bat files, I'm still struggling with understanding bash scripts and the language, so the idea of even attempting to tackle a sdk is remote.
... images for raspi3 and instructions to create said images with a persistent installation.
Thanks for the heads up.
I'll have a look at them.
... for systemd free ...
... alpine linux might trump devuan ...
Thanks, but I am set on staying with Devuan the same way I was set on staying with Debian till systemd reared its head.
I always say that it reminds me of the registry virus inside Windows OSs, with which I dealt for quite a long time.
Thanks a lot for your input.
Cheers,
A.
#1606 Re: ARM Builds » ascii installer-ARM64 question » 2020-04-28 12:54:11
Hello:
... should have pointed the link to the correct sdk ...
No problem.
From what I have read, it's well over my head at the moment.
... try the arm-sdk tommorow when i have some spare time up my sleeve.
Thanks.
No hurry.
The local postal service is usually quite lacking and the CV quarantine has only made things worse.
As a result, the whole of my RPi3B+ kit has been stuck for almost a week at the city's mail distribution centre.
All three packages.
This will build you a image for use on a rpi3
That would be great.
Thanks a lot.
Q: Would this one be different than the one available here?
ie:
devuan_ascii_2.0.0_arm64_raspi3.img.xz 06-Jun-2018 11:28 153MIf it is more or less the same, I would not want you to bother if that *.img works just as well.
I have been reading some posts here regarding Devuan ascii on the RPi+B+ and it seems that (save the image files) there's no other option at the moment.
We'll just have to wait and see if there's interest in generating an installer.
In the meantime we have parazyd's great work uploading the RPi images.
All Devuan/RPi users owe him a big Thank You.
My RPi3B+ will be (almost) exclusively dedicated to running a 64-bit coffee roasting application (Artisan-Scope v2.12) for which 32-bit support was ended at v1.1.
My Asus 2Gb 1000HE (Atom N280) struggles with it and although the souce is available, it would not make sense to build a v2.12 32-bit as it would probably run much slower than v1.1.
Only maintenance, networking or WiFi printing, some basic image viewer + basic OpenBox would be installed so that all the RPi's remaining resources go to running the roasting software.
I'll most probably have to use the Raspbian downloaded from raspberripi.org, put up with systemd and see how to streamline it as much as possible till someone builds an ARM64 installer.
Thanks a lot for your input.
Cheers,
A.
#1607 Re: ARM Builds » ascii installer-ARM64 question » 2020-04-28 10:26:50
Hello:
Bit of a miscommunication ...
Indeed ...
Sorry about that.
... images are devuan ascii ...
... not raspbian images.
I see.
My bad then.
I guess I let the raspi bit lead me to that.
I understood that it was Raspbian -> Devuan thing in the same way/sense that Debian -> Devuan. 8^7
... live sdk will source those files from the link in your op ...
No idea, I've never used that.
Up to now, my experience in Linux has been only with installers (*.iso files), live images (*.img) and the generation of live images with Refracta.
I understand that installing is not the same as dd'ing a live image to a drive as I have to make changes to the original installation to generate a new image file.
Which is why I was looking for a way to install and not burn an image.
... dyslexia in typing
Happens a lot to me also. =-/
I'll have a look at what the sdk says but it seems that for the time being, dd'ing an *.img file is the only path I have to putting Devuan ascii on the RPi3b+.
Thanks a lot for your input.
Cheers,
A.
#1608 Re: ARM Builds » ascii installer-ARM64 question » 2020-04-27 15:52:19
Hello:
... flashing the filesystem onto an sd card.
Yes.
That is how it is done if you want to install Devuan/Raspbian.
And there are Raspbian image files available in the downloads section at Dev1.
... found some rather old arm64 embedded images ...
Yes, they are a mirror of the above.
But as I mentioned, I would like to install Devuan ascii ARM64 (not Raspbian) in my RPi 3B+ but I don't know how to use the files I found in the link mentioned in my OP.
ie:
../
cdrom/ 08-May-2019 16:37 -
device-tree/ 08-May-2019 16:37 -
netboot/ 08-May-2019 16:37 -
MANIFEST 08-May-2019 16:37 3947
MANIFEST.udebs 08-May-2019 16:37 11424
MD5SUMS 08-May-2019 16:37 22425
SHA256SUMS 08-May-2019 16:37 30533
udeb.list 08-May-2019 16:37 3390
Thanks for your input.
Cheers,
A.
#1609 ARM Builds » ascii installer-ARM64 question » 2020-04-27 13:00:53
- Altoid
- Replies: 27
Hello:
Although not entirely convinced that there are no dumb questions ...
I'm wanting to install Devuan ascii on a Raspberry Pi 3B+ (when it gets here) but would like to use the same Devuan version I have on my workstation and not a Raspbian version if at all possible without hitting a glitch at some point.
The idea is to have a setup as familiar as possible, if that makes any sense.
My search got me here.
The thing is that I can't find the usual *.iso file, just these directories/files:
../
cdrom/ 08-May-2019 16:37 -
device-tree/ 08-May-2019 16:37 -
netboot/ 08-May-2019 16:37 -
MANIFEST 08-May-2019 16:37 3947
MANIFEST.udebs 08-May-2019 16:37 11424
MD5SUMS 08-May-2019 16:37 22425
SHA256SUMS 08-May-2019 16:37 30533
udeb.list 08-May-2019 16:37 3390As I've always used *.iso files and/or installer CDs, I'd appreciate some guidance with respect to this.
Thanks in advance.
A.
#1610 Re: Off-topic » deb.sury.org now requires systemd » 2020-04-26 13:03:45
Hello:
... my fault - to trust devuan.
To trust Devuan?
A mistake?
Surely you jest ...
Devuan is as trustworthy as any OS can possibly get, there are absolutely no trust issues with Devuan.
Why should you not trust Devuan?
What you have is an issue with a set of applications which have been/are being crippled by the growing divergence between Debian & Devuan.
Which, like the OP noted, we owe to " ... the last debian resolution whether it is interpreted by maintainers in various ways wrongly or on purpose".
To this we must add that the Debian packager for the application you use understands that the systemd issue is a purely ideological one.
And acts according to his ideology: systemd is the way to go.
ie: the only one.
This growing trend means that Devuan developers/packagers have to work more and harder.
Which I am sure you understand, takes time and resources.
Both human and monetary.
I think that are so used to it that it is possible you have lost sight of a very important fact: that you have a first class OS running your boxes free of charge.
IMHO
Cheers,
A.
#1611 Re: ARM Builds » [Solved] Devuan Raspbian images » 2020-04-23 13:12:11
Hello:
... not to be a hater, but an init freedom lover ...
This has absolutely nothing to do with hate.
Nor is there anything wrong with being an init freedom lover.
This as long as the society/ecosystem you move in and interact with (in this case, Debian and the Pottering crowd) is actually willing to accept that view.
ie: that of init freedom and (of course) in the context we are in: that of Devuan basically depending on Debian to exist.
But pray tell me ...
Just what are you going to love when init freedom ends up becoming systemd dependency?
What will you do then with all your init freedom love?
I imagine that you think this is a far fetched idea and that no, that will never happen.
How sure are you?
You probably missed this this thread.
And if you did not, you surely missed the significance of what it is reporting.
It is my opinion (YMMV) that Pottering and those who follow him in Debian are firmly set on making systemd the init standard for the distribution.
And when this happens Devuan, save a real miracle, will vanish.
... rpi folks realise the "full-fat systemd ...ness" ...
It is quite obvious that you missed the poster's sly sarcasm.
I fear that this laissez faire approach to systemd will end up being the demise of Devuan and everything based on it.
Cheers,
CIV
#1612 Re: ARM Builds » [Solved] Devuan Raspbian images » 2020-04-21 15:25:13
Hello:
there should be more reasons to go systemd-free,... rpi and other arm devices run much faster / less RAM usage, without it.
Should?
There are a great many more reasons to go systemd-free.
I confess that I was not aware of (but suspected) "... much faster / less RAM usage".
Evidently it is something the people/developers at raspberripi.org don't care about or just cannot be bothered with.
The answer I got to my post exudes the shortsighted pragmatism often seen in some forums on the web regarding systemd and I'm really at odds as to how to question it successfully.
But I cannot shake the suspicion that there could well be a dyed-in-the-wool pro systemd stance behind such pragmatism.
eg:
... It's not supported on here.
... (and any quirks it may possess) ... <--- any quirks?
Cheers,
A.
#1613 Re: ARM Builds » [Solved] Devuan Raspbian images » 2020-04-21 13:58:41
Hello:
Seems it was not a very interesting topic for anyone here.
But I am convinced that systemd must go.
So I thought it would be useful to post at the Raspberry Pi forum and see what was up.
It's not supported on here. The OS on here is Raspbian complete with the full-fat systemd wonderfulness. I'd guess that 99.999% of folks on the forum a) won't know what Devuan is, b) won't know why they'd swap from Raspbian and c) have no problems with systemd (and any quirks it may possess).
Solved.
There does not seem to be much love for systemd free OSs at raspberrypi.org, seems they deem it to be innocuous.
Cheers,
A.
#1614 ARM Builds » [Solved] Devuan Raspbian images » 2020-04-17 13:57:00
- Altoid
- Replies: 7
Hello:
I'm currently waiting for delivery of a Raspberry Pi 3B+ to use with my coffee roasting setup.
In the meanwhile (lots of it) I'm reading up on what's going on with Raspberry/Raspbian and I came across this page on the official Raspberry Pi web site.
What called my attention, knowing there are Devuan Raspbian images available, was that their availability was not listed on the page under the Third Party Operating System Images section along with Ubuntu and others.
Is there a sound reason for that or is it because of the systemd thing? (spelt it right this time ...)
Thanks in advance,
A.
#1615 Re: Hardware & System Configuration » Conky on-screen formatting/layout » 2020-04-14 11:36:25
Hello:
... hwmon inside conky ...
... check in /sys/class/hwmon for the correct outputs ...
Right.
That did it.
TEMPERATURES
-------------------------------------
${hr 2}
Core0: +${hwmon 0 temp 2}°C Core1: +${hwmon 0 temp 3}°C
Core2: +${hwmon 0 temp 4}°C Core3: +${hwmon 0 temp 5}°C... got me exactly what I was looking for.
TEMPERATURES
-------------------------------------
Core0: +46.0 Core1: +42.0
Core2: +41.0 Core3: +41.0
Thank you very much for your input.
Cheers,
A.
#1616 Re: Hardware & System Configuration » Conky on-screen formatting/layout » 2020-04-14 01:45:48
Hello:
fmt is the command you want. https://linux.die.net/man/1/fmt
Right ...
... the way you want it formatted should be below command.
Thanks a lot .. =-)
I had to tailor it a bit ...
${execpi 5 sensors | awk 'NR==3{print $1 $2 $3} NR==4{print $1 $2 $3} NR==5 {print $1 $2 $3} NR==6 {print $1 $2 $3}' | fmt -24}... gets me this:
TEMPERATURES
-------------------------------------
Core0: +52.0 Core1: +52.0 |
Core2: +52.0 Core3: +52.0 |
But I have not found a way to separate the readouts.
eg:
TEMPERATURES
-------------------------------------
Core0: +52.0 Core1: +52.0 |
Core2: +52.0 Core3: +52.0 |
It seems that spaces do not count and I don't see a tab or any other argument to use.
How do I separate them?
Thanks in advance,
A.
#1617 Hardware & System Configuration » Conky on-screen formatting/layout » 2020-04-13 21:23:31
- Altoid
- Replies: 4
Hello:
I use Conky on my desktop to show, among other things, CPU temperatures.
Invaluable when your box sits on the floor of a rather unkept home office. =^7
The /etc/conky/conky.conf lines that do it are these ...
--- snip ---
TEMPERATURES
${hr 2}
${execpi 5 sensors | grep Core | awk '{print $1 $2 $3}' | cut -c1-15}
--- snip ---... and what I get is something akin to this:a
TEMPERATURES
-------------------------------------
Core0: +52.0 |
Core1: +52.0 |
Core2: +52.0 |
Core3: +52.0 |
The output shown above in ASCII (*) is more or less to scale and aligned to the right screen margin, in turn represented by the vertically stacked Alt+179 symbols.
In order to be able to add a couple of readings without having to squint (more) and/or take up additional screen surface, I'd like to be able to format the output in this manner:
TEMPERATURES
-------------------------------------
Core0: +52.0 Core1: +52.0 |
Core2: +52.0 Core3: +52.0 |
How can I get that done?
Thanks in advance,
A.
(*) This in the absence of a quick and convenient way to upload small graphic files to wherever, directly from the post screen. (a hint?)
#1618 Re: News & Announcements » Bound to happen ... » 2020-04-06 19:00:19
Hello:
... suspect that this is the tip of the iceberg.
Which one?
HoaS's windup or systemd? 8^D!
Used to be that the "wontfix" issues were listed ...
No telling what's buried in there that will come to bite us.
The won'tfix issues is my main and probably only issue with Linux/Linux maintenance.
They are the stuff problems down the line are made of, that end up festering in dark and unvisited corners of a distribution.
Till one day everything goes titsup because things that were not fixed in time because it seemed they did not matter were not properly evaluated.
And came back to bite, hard.
And then it is either too late or a real bitch to fix and get things back on track again.
Cheers,
A.
#1619 Re: News & Announcements » Bound to happen ... » 2020-04-06 18:43:19
Hello:
It's spelled "systemd" actually.
No idea as I did not actually do any spelling ...
To avoid errors in transcription, I just did a copy/paste from the article at ElReg.
It was already spelt for me.
Are you all doing that deliberately to wind me up?
Nah!
Wouldn't dream of it ... 8^D !!!
Cheers,
A.
#1620 News & Announcements » Bound to happen ... » 2020-04-06 15:28:31
- Altoid
- Replies: 18
Hello:
Not that it matters too much to any of us here but ...
---
SystemD found to have code execution bug
A flaw in SystemD could potentially be exploited by a local attacker or malware to elevate their privileges to fully hijack a machine.
The bug, CVE-2020-1712, a heap use-after-free, was discovered and reported by Google's Tavis Ormandy, and fixed in upstream version v245-rc1. Depending on your Linux distro, you may or may not have a vulnerable version installed; check for updates. Red Hat Enterprise Linux 7 is unaffected, for example.
---
https://www.theregister.co.uk/2020/04/0 … y_roundup/
https://cve.mitre.org/cgi-bin/cvename.c … -2020-1712
https://www.openwall.com/lists/oss-secu … 20/02/05/1
Cheers,
A.
#1621 Re: Desktop and Multimedia » [SOLVED] Legacy Graphics Problem with Beowulf Upgrade » 2020-04-03 11:17:59
Hello:
If Debian had it, we would have it.
Ahh ...
That's the reason.
Learn something new every day. 8^)
... only touch files with systemd issues.
... when Debian offers it, then we will ...
Right.
So my question should have been: why do the Debian repositories have inxi and not smxi and the rest.
Maybe they are not happy with his stance on systemd, the same one I acquired once I realised what was going on albeit only after a 4/5 year tour of Debian/RH based distributions.
Thanks a lot for bearing with me.
Cheers,
A.
#1622 Re: Desktop and Multimedia » [SOLVED] Legacy Graphics Problem with Beowulf Upgrade » 2020-04-03 01:20:31
Hello:
... thanks for tracking that down.
You're welcome. =-)
... had great respect for HH and thank him for his contributions and making that script compatible with Devuan.
Yes.
That website he's set up is great.
Really neat.
I have only used inxi which I find to be excellent, so I wanted to see about smxi, which I did not know about.
... that package comes directly from Debian ...
Indeed ...
But Debian also means (in some way, methinks) systemd related.
As I always try to avoid installing anything from outside the Devuan repositories, I went to synaptic expecting to find it there, just like inxi.
I did not find it so I went looking for it at https://pkginfo.devuan.org/ and it had not been / was not there either.
This called my attention, which is why I asked.
I'll install it from HH's site but maybe (?) it could be added to the stable/backport repositories in the future?
Thanks for your input.
A.
#1623 Re: Desktop and Multimedia » [SOLVED] Legacy Graphics Problem with Beowulf Upgrade » 2020-04-02 21:21:34
Hello:
sgfxi at https://smxi.org/ will automate everything.
Being a long time user of Nvidia legacy cards/drivers under Linux, I was interested in seeing what smxi was about and saw that the author is also the author of the inxi script.
Did not know that.
Although inxi is in the Devuan repositories, I see that smxi (or the other author's scripts) is not.
Further looking in https://pkginfo.devuan.org/ revealed that it smxi has never been included in any Devuan repository.
Is there a specific reason for that?
I have read posts from mid 2015 regarding some difficulty the smxi script seemed to have ID'ing Devuan but it seems to have been fixed.
EDIT:
Fix confirmed - https://github.com/smxi/inxi/blob/master/inxi.changelog
=====================================================================================
Version: 2.2.23
Patch: 00
Date: 2015-06-08
-----------------------------------
Changes:
-----------------------------------
New version, tarball. Tiny change. Added /etc/devuan_version file to distro id to handle
the switched file name. Kudos to anyone out there fighting to create a working alternative
to the unreliable and buggy and windows emulating systemd, I wish devuan luck. Maybe between
devuan and gentoo and slackware we can save the free software core systems before it's too late.
-----------------------------------
-- Harald Hope - Mon, 08 Jun 2015 15:43:52 -0700
=====================================================================================
Thanks in advance,
A.
#1624 Re: Hardware & System Configuration » Drive letter assignments [Solved] » 2020-03-31 20:34:16
Hello:
Yes, that did it.
Spoke too soon ...
The problem was still there. =^ 7
ie: Rebooting with anything storage plugged in would screw up the conky readout.
I think/guess what using UUIDs in fstab does is link the drive's UUIDs to partitions but still that leaves eventual drive letter assignments in a dynamic state, so to speak.
ie: a UUID does not get permanently linked to a drive letter.
The solution then is to point conky to the drive's UUID.
eg:
TEMPERATURES
${hr 2}
${execpi 5 sensors | grep Core | awk '{print $1 $2 $3}' | cut -c1-15}
${hr 0.3}
/dev/sda: ${execi 60 hddtemp /dev/disk/by-uuid/d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 | cut -c 81-84}
/dev/sdb: ${execi 60 hddtemp /dev/disk/by-uuid/49d1369c-ed70-4543-b0ee-ef65327e101b | cut -c 83-86}
/dev/sdc: ${execi 60 hddtemp /dev/disk/by-uuid/bdf33361-5929-433e-ac7f-1a626aa6e844 | cut -c 78-81}
/dev/sdd: ${execi 60 hddtemp /dev/disk/by-uuid/c722f26d-5c9a-42a9-8c2b-6dbdf926d865 | cut -c 83-86}
/dev/sde: ${execi 60 hddtemp /dev/disk/by-uuid/ca8dbded-819d-4e2b-b017-0981a75ea718 | cut -c 101-104}... instead of what I was using before:
TEMPERATURES
${hr 2}
${execpi 5 sensors | grep Core | awk '{print $1 $2 $3}' | cut -c1-15}
${hr 0.3}
/dev/sda: ${execi 60 hddtemp /dev/sda | cut -c 35-55}
/dev/sdb: ${execi 60 hddtemp /dev/sdb | cut -c 37-57}
/dev/sdc: ${execi 60 hddtemp /dev/sdc | cut -c 32-55}
/dev/sdd: ${execi 60 hddtemp /dev/sdd | cut -c 37-55}
/dev/sde: ${execi 60 hddtemp /dev/sde | cut -c 55-65}Now, independently of changing my fstab to UUID (or not) now conky will run hddtemp on drives by UUID.
Cheers,
A.
#1625 Re: News & Announcements » Linux 5.6 kernel release news » 2020-03-30 21:51:23
How is it that this actually slipped by Torvalds?
Some time ago, the world+dog endlessly busted Torvald's balls because he shouted and cursed a number of dimwitt/AH coders in order to keep a tight ship.
But it does not seem that anyone is saying absolutely anything about this nonsense.
Call me what you will, but I think that if this type of thing is not stopped ASAP, the Linux kernel as we know it will end up going to the dogs.
A.
Board footer
