Re: Debian Linux keyboard mapping files ...
It occurred to me that my use of the term "mapping" may have been a little confusing. I used it in general and as part of my corpora research I am moving away from UTF-8. That is all I am doing. lbrtchx
Re: How to verify newly burned disc
Hi, On Fri, 02 Jul 2021 21:22:00 +0200 "Thomas Schmitt" wrote: > Hi, > > i wrote: > > ... > You would need a filter program which takes care not to read > > more ... > than ~ 20 MB/s. > > Michael Lange wrote: > > I tried that, but as it seems without any effect on the drive's speed. > > Maybe my efforts were not sufficient :) > > Did you test it with a superfast input like /dev/zero ? > > time dd if=/dev/zero bs=1M count=1024 | your_filter >/dev/null > > Does it curb that stream and need the due time ? I did now, and it does (it took about 1 min. to read approx. 300 MB; without "pulling the brakes" it took about 1 sec.). Since I am no good with shell scripting I did not use dd though, but a simple Python function that I think does basically the same; the way I used to slow it down is quite primitive however (basically it just waits until 10 MB have been read and then sleeps for 2 sec.), which may be too simple to stop the drive from happily spinning on. > > > It looks like when reading a DVD-RW it takes about 1.2 seconds > > to read 10 MB of data; when I insert the Asus-CD, the drive spins > > audibly faster, but surprisingly takes about 3 seconds to read 10 MB. > > A rough estimation yields a linear density increase from CD to DVD by > a factor of 2.5 (= sqrt(4480MB/700MB)). Multiplied by 1.2 this yields > roughly 3, but does not explain the extra noise. > You would need to read larger parts of the media to get an estimation > of noise/speed ratio. I see, so CDs are generally slower than DVDs, and (no surprise) the DVD-RW is a bit slower here than a "real" (bought) DVD. > > > > > Does yours pull in the tray automatically after 200 seconds of > > > standing out ? > > > Yes, it actually does. > > At least it is not a random feature of individual drives. > > > > > I made a little poll here about this behavior, 1.5 years ago: > > > I remember that :) > > Actually I thought I had participated, but that appears to be a false > > memory. > > It's my memory which goes dim. I have you on the result list with > > Reporter Drive Since MediaPulls > ... > Michael Lange Plextor PX-810SA 2007 DVDno > Michael Lange TSSTcorp SH-224DB 2013 DVDno > ... > > I now added you with a 2021 ASUS DRW-24D5MT which pulls. > > > > > I wonder whether this is related to this obscure description > > > "E-Green technology auto-closes drive application when not in use, > > >saving over 50% power consumption for users" > > > I thought they just mean that it spins down after a few minutes, but > > who knows? > > The drives themselves have internal power management with timers for > partially shutting down the drive. The states are named "Active", > "Idle", and "Standby". The timer thresholds can be set by the computer. > Further the states can be ordered immediately by the computer. > > > > On the disc that came with the drive there is a "ASUS > > E-Green.exe", so maybe we would need to install this first to fully > > enjoy the Wonders of "E-Green"? :) > > https://www.techwalla.com/articles/what-is-the-asus-e-green-utility > could mean that the .exe agressively strives for "Standby" by setting > low timer thresholds. It seems also to be capable to count the time in > that state and to brag with its power savings. > > If my /dev/sr0 is annoyingly excited after Linux block i/o i run > > xorriso -outdev /dev/sr0 > > which ends by a drive calming START/STOP UNIT command. Nice! This work here, too. :-) > > -- > > Another thing which makes me wonder about ASUS' description of the drive > is where they expect us to still find M-Disc DVD+R media. Last time i > looked i found only M-Disc BD-R (and some "currenlty unavailable" DVD > offers). Well, looks like this is not so hard. The first hit at ebay.de when searching for "m-disc dvd" shows an offer for 10 4.7 GB discs at 85.11 € + 7.31 € for shipping from Japan :-) They're Verbatim discs though, might be they break in the process :D There is also an offer from Australia, 5 discs for "~" 21.74 € + ~ 42.97 shipping (also Verbatim :) and a little bit further down the "killer" bargain: 10 Verbatims for ~ 46.11 € + free shipping! Buy now!! :-) Best regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7
Re: How to verify newly burned disc
Hi, Greg Wooledge wrote: > Audio CDs do not have a file system. There's nothing to mount. There > are no ".wav files". Correct. Further the CD-DA sectors are not readable by the usual Linux block i/o. dd(1) and write(2) will throw error. Reading is done by special programs which use the SCSI command READ CD. The kernel offers this as ioctl(CDROMREADAUDIO). > To the best of my knowledge, there is no way to verify every bit of > audio on an audio CD. They're simply not structured in a way that makes > it possible to retrieve a stream of digital audio data. It's not that bad, although CD-DA is not well suitable for storing data. CDs have a structure named Table-Of-Content which records the start sectors of the tracks and of gaps between tracks. CD-DA sectors contain 2352 bytes of payload and some error correction. The main problem with reading a flawlessly recorded data stream is that the sectors do not contain a field which tells their sector number. So random addressing depends on the Q sub-channel bits which are few. This makes it somewhat tricky for the drive firmware to find exactly the sector with the given number. Nevertheless i expect a good drive with good medium to reproduce the same payload data as have been written. But the reader programs have to invent new WAVE headers for the extracted data. The original input files usually had such headers which did not get recorded on the CD. So these headers can differ. It is not totally trivial to find out the size of the WAVE/RIFF headers and the position of the audio payload data. > Programs that > "rip" CD audio to files use heuristics and multiple tries and fancy > stuff like that, trying to get a good approximation of the original data > back from the disc. There are two aspects here: Read error mitigation and acoustic improvement. The former is meaningful for verifying the burn success. The latter is not. A burn should be regarded as failed or questionable if it is necessary to read sectors more than once. Richmond wrote: > Using Caja file manager I have put in the localtion bar (or rather it put > in) > cdda://sr0/ > [...] > It could be some clever stuff that caja is doing though. Possibly a gvfs feature. https://codesearch.debian.net/search?q=package%3Acaja+cdda https://codesearch.debian.net/search?q=package%3Agvfs+cdda%3A=0 Possibly based on libcdio-cdda2 and libcdio-paranoia2 as actual CD-DA reader. https://packages.debian.org/unstable/gvfs-backends Have a nice day :) Thomas
Re: Creation of empty files [was: Useful use of dd]
On 7/2/21 2:30 PM, David Christensen wrote: I expected sparse files, but du(1) does not indicate such (?). Comments? RTFM ls(1) and the '-s' and '--block-size' options. David
Re: Useful use of dd
On 7/2/21 4:25 AM, Teemu Likonen wrote: * 2021-07-02 12:52:53+0200, Thomas Schmitt wrote: Teemu Likonen wrote: For this new subject I will add another use: quickly create empty file of specific size, for example 5 * 1024 bytes: $ dd of=empty obs=1024 seek=5 count=0 Not to forget creation of sparse files with few disk consumption. My example above already does that. $ dd of=empty obs=100G seek=1 count=0 $ ls -gGlhs empty 0 -rw-r--r-- 1 100G 2021-07-02 14:21:18 empty Zero blocks actually allocated, so far. Thanks for the clue regarding viewing sparse files: 2021-07-02 14:39:52 dpchrist@dipsy ~/sandbox/dd $ dd if=/dev/zero of=zero bs=1M count=5 5+0 records in 5+0 records out 5242880 bytes (5.2 MB, 5.0 MiB) copied, 0.0125097 s, 419 MB/s 2021-07-02 14:41:57 dpchrist@dipsy ~/sandbox/dd $ dd if=/dev/urandom of=urandom bs=1M count=5 5+0 records in 5+0 records out 5242880 bytes (5.2 MB, 5.0 MiB) copied, 0.026771 s, 196 MB/s 2021-07-02 14:44:11 dpchrist@dipsy ~/sandbox/dd $ ls -gGls --block-size=1 [a-z]* 0 -rw-r--r-- 1 5242880 Jul 2 14:21 dd-sparse 0 -rw-r--r-- 1 5242880 Jul 2 14:24 truncate-sparse 5242880 -rw-r--r-- 1 5242880 Jul 2 14:42 urandom 5242880 -rw-r--r-- 1 5242880 Jul 2 14:40 zero David
Re: How to verify newly burned disc [Was: Fatal error while burning CD]
On Fri, Jul 02, 2021 at 10:04:04PM +0100, Richmond wrote: > Greg Wooledge writes: > > Audio CDs do not have a file system. There's nothing to mount. There > > are no ".wav files". > Using Caja file manager I have put in the localtion bar (or rather it put in) > > cdda://sr0/ > > This shows me each of the wave files on the disk as track1.wav, > track2.wav etc. The disk is a pre-recorded one I bought in a shop. It > could be some clever stuff that caja is doing though. It is. If you select one of those and try to open it, a ripper program will be launched which will try to rip the CD-DA from the disc and convert it into a .wav file.
Creation of empty files [was: Useful use of dd]
On 7/2/21 11:51 AM, Kushal Kumaran wrote: On Fri, Jul 02 2021 at 01:26:23 PM, Teemu Likonen wrote: For this new subject I will add another use: quickly create empty file of specific size, for example 5 * 1024 bytes: $ dd of=empty obs=1024 seek=5 count=0 2021-07-02 14:20:47 dpchrist@dipsy ~/sandbox/dd $ dd of=dd-sparse bs=1M seek=5 count=0 0+0 records in 0+0 records out 0 bytes copied, 6.9482e-05 s, 0.0 kB/s 2021-07-02 14:21:16 dpchrist@dipsy ~/sandbox/dd $ ll dd-sparse -rw-r--r-- 1 dpchrist dpchrist 5242880 2021-07-02 14:21:16 dd-sparse 2021-07-02 14:21:40 dpchrist@dipsy ~/sandbox/dd $ du --bytes dd-sparse 5242880 dd-sparse There's $ truncate --size 5k testfile for this purpose. 2021-07-02 14:23:34 dpchrist@dipsy ~/sandbox/dd $ time truncate --size 5M truncate-sparse real0m0.002s user0m0.002s sys 0m0.001s 2021-07-02 14:24:25 dpchrist@dipsy ~/sandbox/dd $ ll truncate-sparse -rw-r--r-- 1 dpchrist dpchrist 5242880 2021-07-02 14:24:25 truncate-sparse 2021-07-02 14:24:30 dpchrist@dipsy ~/sandbox/dd $ du --bytes truncate-sparse 5242880 truncate-sparse I expected sparse files, but du(1) does not indicate such (?). Comments? David
Useless use of shell pipelines [was: Useful use of dd]
On 7/2/21 12:49 AM, to...@tuxteam.de wrote:
Now to another pet peeve of mine: useless use of grep:
grep | sed -e 's/bla/foo/' ...
Perhaps the underlying issue is useless use of shell pipelines ("The
Unix Way"):
2021-07-02 12:44:43 dpchrist@dipsy ~/sandbox/perl
$ cat useless-use-of-grep
This is the first line: bla bla bla.
This is line : bla bla bla.
This is the last line: bla bla bla.
2021-07-02 12:45:38 dpchrist@dipsy ~/sandbox/perl
$ grep useless-use-of-grep | sed -e 's/bla/foo/'
This is line : foo bla bla.
Versus "all-in-one":
2021-07-02 12:45:39 dpchrist@dipsy ~/sandbox/perl
$ perl -ne 's/bla/foo/ && print if //' useless-use-of-grep
This is line : foo bla bla.
The former is better from a "golfing" standpoint (e.g. fewer characters
to type).
But, it is interesting that the benchmark results defy the common
perceptions of "userland tools are are fast" and "Perl is slow":
2021-07-02 12:59:55 dpchrist@dipsy ~/sandbox/perl
$ time for n in {1..1}; do grep useless-use-of-grep | sed -e
's/bla/foo/' > /dev/null ; done
real0m42.162s
user0m32.925s
sys 0m45.787s
2021-07-02 13:00:45 dpchrist@dipsy ~/sandbox/perl
$ time for n in {1..1}; do perl -ne 's/bla/foo/ && print if //'
useless-use-of-grep > /dev/null; done
real0m23.624s
user0m14.308s
sys 0m10.826s
Perhaps this is because processing is trivial and a pipeline of two
commands has twice the process creation costs of a single command (?).
David
Re: How to verify newly burned disc [Was: Fatal error while burning CD]
Greg Wooledge writes: > On Fri, Jul 02, 2021 at 08:51:54PM +0100, Richmond wrote: >> Michael Lange writes: >> >> > So, does anyone know about a way to verify the integrity of burned >> > audio-CDs? >> > >> >> This is a bit speculative because I cannot test it, but: >> >> k3b and brasero have options to verify written cd. >> >> I think you could verify using diff, i.e. diff /dev/cdrom file.iso >> >> Or you could mount the cd image via the loopback device, mount the cd, >> and then compare the .wav files individually to find which one the error >> is in. > > Audio CDs do not have a file system. There's nothing to mount. There > are no ".wav files". > > To the best of my knowledge, there is no way to verify every bit of > audio on an audio CD. They're simply not structured in a way that makes > it possible to retrieve a stream of digital audio data. Programs that > "rip" CD audio to files use heuristics and multiple tries and fancy > stuff like that, trying to get a good approximation of the original data > back from the disc. > > One thing I suppose you could do is generate the CDDB "disc ID" which is > based on the CD's metadata (track lengths), and compare it to the expected > value. This will at least tell you whether you've got the right number > of audio tracks and the correct lengths. Using Caja file manager I have put in the localtion bar (or rather it put in) cdda://sr0/ This shows me each of the wave files on the disk as track1.wav, track2.wav etc. The disk is a pre-recorded one I bought in a shop. It could be some clever stuff that caja is doing though.
Re: when will bullseye become stable?
On Fri, Jul 2, 2021 at 3:52 PM Long Wind wrote: > > i always use stable or old releases When it's ready. But we're coming up rapidly on full freeze in a couple weeks. https://release.debian.org/bullseye/freeze_policy.html#full
Re: when will bullseye become stable?
Le 02/07/2021 à 22:51, Long Wind a écrit : i always use stable or old releases probably at the end of this month of July Regards Thanks!
Re: How to verify newly burned disc [Was: Fatal error while burning CD]
On Fri, Jul 02, 2021 at 08:51:54PM +0100, Richmond wrote: > Michael Lange writes: > > > So, does anyone know about a way to verify the integrity of burned > > audio-CDs? > > > > This is a bit speculative because I cannot test it, but: > > k3b and brasero have options to verify written cd. > > I think you could verify using diff, i.e. diff /dev/cdrom file.iso > > Or you could mount the cd image via the loopback device, mount the cd, > and then compare the .wav files individually to find which one the error > is in. Audio CDs do not have a file system. There's nothing to mount. There are no ".wav files". To the best of my knowledge, there is no way to verify every bit of audio on an audio CD. They're simply not structured in a way that makes it possible to retrieve a stream of digital audio data. Programs that "rip" CD audio to files use heuristics and multiple tries and fancy stuff like that, trying to get a good approximation of the original data back from the disc. One thing I suppose you could do is generate the CDDB "disc ID" which is based on the CD's metadata (track lengths), and compare it to the expected value. This will at least tell you whether you've got the right number of audio tracks and the correct lengths.
Re: How to verify newly burned disc [Was: Fatal error while burning CD]
Michael Lange writes: > So, does anyone know about a way to verify the integrity of burned > audio-CDs? > This is a bit speculative because I cannot test it, but: k3b and brasero have options to verify written cd. I think you could verify using diff, i.e. diff /dev/cdrom file.iso Or you could mount the cd image via the loopback device, mount the cd, and then compare the .wav files individually to find which one the error is in.
Re: Useless use of "dd"
On 7/1/21 10:40 PM, Teemu Likonen wrote: * 2021-07-01 20:43:09-0700, David Christensen wrote: To "take an image", the script invokes dd(1) and pipes the output to gzip(1), copying raw device octets to a file. To "restore an image", the process is reversed. Sounds like the classic "useless use of dd". For general educational purposes I remind (not necessarily you) that "dd" is just a file copying (and conversion) tool, almost like "cat". By default "dd" is a slow version of "cat" because it uses smaller buffers. "dd" can be made faster by increasing its buffer size but that will not make it more than just "cat". So "dd" is not a special tool for accessing device files. Device files don't need special tools. They are files. The following command: dd if=/dev/sdX | gzip >image.gz is slower but functionally the same as either of these: gzip image.gz gzip --to-stdout /dev/sdX >image.gz Usually we don't need "dd" for anything but there are some options which are useful sometimes. For example, "dd" can report progress to standard error stream and it can seek and limit read to some blocks or bytes. My description was a high-level overview. As always, "the devil is in the details". dd(1) has features that would require extra work with cat(1) or gzip(1). The script provides all of the options to dd(1) that you mention, and more. 'bs=1048576' gives good performance, makes math easy, and dovetails with 'parted ... u MiB'. I also omitted functionality like MD5 and SHA256 checksum files, byte-for-byte verification, Bash code generation from Perl, and opportunities for concurrency (yet to be implemented). It's all good stuff that you encounter when you've been doing imaging by hand and decide to "up your game" with scripting. David
Re: How to verify newly burned disc
Hi, i wrote: > ... > You would need a filter program which takes care not to read more > ... > than ~ 20 MB/s. Michael Lange wrote: > I tried that, but as it seems without any effect on the drive's speed. > Maybe my efforts were not sufficient :) Did you test it with a superfast input like /dev/zero ? time dd if=/dev/zero bs=1M count=1024 | your_filter >/dev/null Does it curb that stream and need the due time ? > It looks like when reading a DVD-RW it takes about 1.2 seconds > to read 10 MB of data; when I insert the Asus-CD, the drive spins > audibly faster, but surprisingly takes about 3 seconds to read 10 MB. A rough estimation yields a linear density increase from CD to DVD by a factor of 2.5 (= sqrt(4480MB/700MB)). Multiplied by 1.2 this yields roughly 3, but does not explain the extra noise. You would need to read larger parts of the media to get an estimation of noise/speed ratio. > > Does yours pull in the tray automatically after 200 seconds of standing > > out ? > Yes, it actually does. At least it is not a random feature of individual drives. > > I made a little poll here about this behavior, 1.5 years ago: > I remember that :) > Actually I thought I had participated, but that appears to be a false > memory. It's my memory which goes dim. I have you on the result list with Reporter Drive Since MediaPulls ... Michael Lange Plextor PX-810SA 2007 DVDno Michael Lange TSSTcorp SH-224DB 2013 DVDno ... I now added you with a 2021 ASUS DRW-24D5MT which pulls. > > I wonder whether this is related to this obscure description > > "E-Green technology auto-closes drive application when not in use, > >saving over 50% power consumption for users" > I thought they just mean that it spins down after a few minutes, but who > knows? The drives themselves have internal power management with timers for partially shutting down the drive. The states are named "Active", "Idle", and "Standby". The timer thresholds can be set by the computer. Further the states can be ordered immediately by the computer. > On the disc that came with the drive there is a "ASUS > E-Green.exe", so maybe we would need to install this first to fully enjoy > the Wonders of "E-Green"? :) https://www.techwalla.com/articles/what-is-the-asus-e-green-utility could mean that the .exe agressively strives for "Standby" by setting low timer thresholds. It seems also to be capable to count the time in that state and to brag with its power savings. If my /dev/sr0 is annoyingly excited after Linux block i/o i run xorriso -outdev /dev/sr0 which ends by a drive calming START/STOP UNIT command. -- Another thing which makes me wonder about ASUS' description of the drive is where they expect us to still find M-Disc DVD+R media. Last time i looked i found only M-Disc BD-R (and some "currenlty unavailable" DVD offers). Have a nice day :) Thomas
Re: Wanted: a special purpose Debian installer
On Fri 02 Jul 2021 at 11:09:58 +0100, Brian wrote: > Indeed. Apologies, Felix. Having said that, perhaps installing in the same way as two other users have idicaated would allow you to make a useful contriburion without having to rely on memory. -- Brian.
Re: Useful use of dd [was: Useless use of "dd"]
On Fri, Jul 02 2021 at 01:26:23 PM, Teemu Likonen wrote: > * 2021-07-02 09:49:23+0200, to...@tuxteam.de wrote: > >> FWIW, I've found something which could be deemed to be an "useful use >> of dd" which somehow bears a hidden symmetry. As a replacement for >> `cat' whenever you need to put a name on the output file. > > For this new subject I will add another use: quickly create empty file > of specific size, for example 5 * 1024 bytes: > > $ dd of=empty obs=1024 seek=5 count=0 There's $ truncate --size 5k testfile for this purpose. -- regards, kushal
Re: Plantages Xorg (i915, context reset due to GPU hang)
Daniel Caillibaud a écrit : > Le 02/07/21 à 10:18, BERTRAND Joël a écrit : >> Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte >> graphique. > >> Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de >> carte-mère sans que cela soit réglable > > Ben, j'ai vraiment fait toutes les pages de paramétrage du bios et rien vu > là-dessus (c'est > une machine d'entrée de gamme qui ne peut pas recevoir de carte graphique > dédiée, ceci > explique peut-être cela). > > C'est peut-être une "amélioration" sur cette carte (ou le bios) qui > allouerait d'office au GPU > la RAM nécessaire à gérer sa résolution max (vu qu'on peut ajouter des écrans > à chaud il vaut > mieux que le GPU ait la RAM nécessaire), j'en sais trop rien… > > Il s'agit d'un cpu i5 de 10e génération, et vu que 32, 64 ou 128Mo ne > changent pas grand chose > quand tu as plusieurs Go de RAM (de 4 à 16 sur cette machine), ce bios dell > fait peut-être > cette allocation au max de manière systématique, ce serait pas idiot. Dell ? Fallais le dire plus tôt ;-) Je n'ai jamais eu que des problèmes avec leurs machines. JKB
Re: Whole Disk Encryption + SSD
On 7/2/21 8:02 AM, David Wright wrote: On Thu 01 Jul 2021 at 20:43:09 (-0700), David Christensen wrote: On 7/1/21 7:55 PM, David Wright wrote: On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote: I do not set the 'discard' (trim) option in fstab(5). If and when I want to erase unused blocks (such as before taking an image), I use fstrim(8). What improvement does erasing unused blocks achieve? Zero blocks are readily compressed, reducing the size of the image file. Ah, I see. So a spinning rust analogy might be: . Take an old conventional disk, sdz, where df shows 10% uasge, . cp /dev/zero a-file-on-sdz . rm a-file-on-sdz . dd if=/dev/sdz … and compressing it, saving ~90% space. But can I tweak my question a little— Say that /dev/sdz contained one partition, sdz1, which filled the disk and was a LUKS encrypted /home. In this case, the above would fail to save space because the raw device sdz would be full of "random" data. But what happens with an SSD? If, after the rm step above, you # fstrim /home the mountpoint, where /etc/fstab has the line /dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home then what gets zeroed, the container or the contained? I can't put my finger on any documentation that spells it out. AIUI userland programs such as fstrim(8) interact with the kernel via an application programming interface (API). Device drivers interact with the kernel and/or each other via device driver interfaces (DDI). Some device drivers are designed to interact with hardware. Other device drivers are designed to fit in between the kernel and/or device drivers -- for example, LVM, md, and dm-crypt. So, you can layer ext4 on top of LVM on top of dm-crypt (LUKS) on top of md on top of several SSD's. Given a file system driver that supports trim, fstrim makes an API call to the file system driver telling the file system driver to erase unused blocks. The file system driver knows what blocks are unused and makes DDI calls to trim those blocks. If everything between the file system driver and the SSD(s) supports trim commands, eventually the trim commands reach the SSD(s) and blocks are erased. Similarly, the response codes must be passed upwards from the SSD(s) to the file system driver, which then responds to fstrim. David
Re: systemd nfs mount blocked until first entered
On Fri, Jul 02, 2021 at 07:46:31PM +0200, Reiner Buehl wrote: > I think I found a solution! For whatever reason, my network interface > enp5s11 was not in the "auto" line in /etc/network/interfaces. After adding > it there and a reboot, the filesystem is mounted correct without any of > the x-systemd mount options. This happens a *lot*.
Re: systemd nfs mount blocked until first entered
I think I found a solution! For whatever reason, my network interface enp5s11 was not in the "auto" line in /etc/network/interfaces. After adding it there and a reboot, the filesystem is mounted correct without any of the x-systemd mount options. Am Fr., 2. Juli 2021 um 19:30 Uhr schrieb Reiner Buehl < reiner.bu...@gmail.com>: > Hello, > > this is the full unit: > > # /etc/systemd/system/vdr.service > [Unit] > Description=Video Disk Recorder > > Wants=systemd-udev-settle.service > After=systemd-udev-settle.service > > [Service] > Type=notify > ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh "commands" > ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh "reccmds" > ExecStart=/usr/bin/vdr > Restart=on-failure > RestartPreventExitStatus=0 2 > > [Install] > WantedBy=multi-user.target > > # /etc/systemd/system/vdr.service.d/override.conf > [Unit] > After=remote-fs.target > Requires=remote-fs.target > > I only added the x-systemd options to /etc/fstab because the filesystems > where not mounted at boot time at all with the old fstab options that I > used before the upgrade to Debian (I did use yavdr before - a distro that > was based on a super old 12.x version of Ubuntu). There I just used > > 192.168.1.2:/video /video nfs > defaults,rsize=8192,wsize=8192,soft,nolock,noatime 0 0 > > If I try with this entry, the auto-generated video.mount unit fails as it > seems to be started too early: > > ● video.mount - /video >Loaded: loaded (/etc/fstab; generated) >Active: failed (Result: exit-code) since Fri 2021-07-02 19:26:02 CEST; > 2min 46s ago > Where: /video > What: 192.168.1.2:/video > Docs: man:fstab(5) >man:systemd-fstab-generator(8) > > Jul 02 19:26:02 vdr systemd[1]: Mounting /video... > Jul 02 19:26:02 vdr mount[403]: mount.nfs: Network is unreachable > Jul 02 19:26:02 vdr systemd[1]: video.mount: Mount process exited, > code=exited, status=32/n/a > Jul 02 19:26:02 vdr systemd[1]: video.mount: Failed with result > 'exit-code'. > Jul 02 19:26:02 vdr systemd[1]: Failed to mount /video. > > Best regards, > Reiner > > Am Fr., 2. Juli 2021 um 19:15 Uhr schrieb Reco : > >> Hi. >> >> On Fri, Jul 02, 2021 at 06:12:58PM +0200, Reiner Buehl wrote: >> > I have a directory that is mounted via NFS from a remote server. >> >> Actually, you have an autofs mountpoint, because you set >> x-systemd.automount option in fstab. >> Only if something starts using that mountpoint an NFS filesystem should >> be mounted there. >> >> In another words - you do not require your NFS filesystem to be mounted >> at boot time, and thus remote-fs.target does not include your NFS >> filesystem. >> >> >> > If I boot the vdr daemon fails during startup with the error message >> >> In other words, vdr fails to trigger automounting of the filesystem in >> question. As usual with journald, the actual reason of this is not >> present in this log. >> >> >> > The vdr.service has an override of >> > >> > [Unit] >> > After=remote-fs.target >> > Requires=remote-fs.target >> > >> > to ensure that the filesystem is mounted. >> >> These dependencies are useless for your service given the current state >> of your fstab. >> The reason being - "autofs" filesystems belong to local-fs.target, not >> remote-fs.target, and explicitly depending on local-fs.target is useless >> anyway (it's one of the default dependencies for the most units). >> What you probably need here is a dependency for a .mount unit >> corresponding to your NFS filesystem. >> >> >> > If I try to restart vdr.service, it fails again with the same error but >> if >> > I just cd to the directory and then try to restart it, it starts and >> works >> > fine. >> >> Can you show the result of "systemctl cat vdr" please? >> >> > What is systemd doing here that blocks the mount point for the vdr >> process? >> >> Many things are possible here. You have ProtectSystem=full set in unit, >> or you have PrivateMounts=true set in there. >> >> > Do I need different fstab options? >> >> It depends. x-systemd.automount is useful, because it does not require >> your NFS server to be present at boot time. >> I'll refrain from suggesting certain hacks for now, I'd like to see your >> unit in full first. >> >> Reco >> >>
Re: Btrfs scrub going past 100%
On 7/2/21 5:48 PM, Dan Ritter wrote: Paul wrote: I run regular btrfs scrubs through btrfsmaintenance on my disk array without issues. This time, though, the scrub percentage went over 100%. I kept it running so that I can file a bug if this is one. Which package do I file this against? I believe it's in the Linux kernel not btrfs-progs, but I thought I would ask since I'm new to this. UUID: ---- Scrub started: Thu Jul 1 00:03:28 2021 Status: running Duration: 37:13:49 Time left: 21358913:01:19 ETA: Mon Feb 11 06:18:36 4458 Total to scrub: 29.08TiB Bytes scrubbed: 29.24TiB (100.56%) Rate: 228.79MiB/s Error summary: no errors found Reported to the btrfs list last year, doesn't look like there's any followup. Check out your time left calculation, too. https://lore.kernel.org/linux-btrfs/a17a65d0-68d4-e220-0b2d-5c19cdc7b...@petaramesh.org/ They mention "When the filesystem has grown during scrub...". I'm not sure if they mean they increased the size of the FS while it was scrubbing. Definitely not a good idea, IMO. It is probably significant that over the last year, I see a fair number of issues with crashes and unrecoverable data on the btrfs list. I've been using Btrfs for several years. It works quite well. I chose it over ZFS for its flexibility. The only issues I had are mostly my idiocy. Thankfully I was able to recover and didn't lose any data. Just a data point ;) On the ZFS list, most of the discussion is about optimal configurations. -dsr- An update about the scrub: an hour or so later the percentage went back to 1%. I don't remember what happened to the other parameters, but I just cancelled it anyway. I didn't have any errors, thankfully, as usual.
Re: How to verify newly burned disc
Hi, On Fri, 02 Jul 2021 12:24:17 +0200 "Thomas Schmitt" wrote: > Hi, > > i wrote: > > > You would need a filter program which takes care not to read more > > > than ~ 20 MB/s. Then the [Pioneer BDR-S09] drive slows down > > > automatically. > > Michael Lange wrote: > > I see, that does not sound trivial, at least to me :) > > It would be a nice first exercise in about any programming language. > The first time i implemented such a thing was for a QIC tape drive > which overheated when running at full speed. I tried that, but as it seems without any effect on the drive's speed. Maybe my efforts were not sufficient :) Or maybe it is because the drive does not seem to spin as fast as the Pioneer. It looks like when reading a DVD-RW it takes about 1.2 seconds to read 10 MB of data; when I insert the Asus-CD, the drive spins audibly faster, but surprisingly takes about 3 seconds to read 10 MB. > > > At the begin of this thread: > > > > [...] I finally picked no. 1 of 2 of these Asus DRW-24D5MTs [...] > > > So far the Asus managed to pass all tests, so probably I should just > > be grateful to all the transcendental authorities that guided my hand > > when I picked that carton from the shelf :) > > Does yours pull in the tray automatically after 200 seconds of standing > out ? Yes, it actually does. > > I made a little poll here about this behavior, 1.5 years ago: > https://lists.debian.org/debian-user/2020/01/msg00421.html > Overview of result: > https://lists.debian.org/debian-user/2020/02/msg00758.html I remember that :) Actually I thought I had participated, but that appears to be a false memory. For the record: afair the Plextor PX-810SA did nothing of that sort, Nor does the 'TSSTcorp' 'CDDVDW SH-224DB' in the other machine. > > I wonder whether this is related to this obscure description on > > https://www.asus.com/Motherboards-Components/Optical-Drives/Internal-DVD-Drive/DRW-24D5MT/ > > "E-Green technology auto-closes drive application when not in use, >saving over 50% power consumption for users" > > (What might be meant by "drive application" ?) I thought they just mean that it spins down after a few minutes, but who knows? On the disc that came with the drive there is a "ASUS E-Green.exe", so maybe we would need to install this first to fully enjoy the Wonders of "E-Green"? :) Best regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. The joys of love made her human and the agonies of love destroyed her. -- Spock, "Requiem for Methuselah", stardate 5842.8
Re: Btrfs scrub going past 100%
Paul wrote: > On 7/2/21 5:48 PM, Dan Ritter wrote: > > > It is probably significant that over the last year, I see a fair > > number of issues with crashes and unrecoverable data on the btrfs list. > > I've been using Btrfs for several years. It works quite well. I chose it over > ZFS for its flexibility. The only issues I had are mostly my idiocy. > Thankfully I was able to recover and didn't lose any data. > > Just a data point ;) That's the thing -- during the three years I ran btrfs, I had data loss issues that weren't, as far as I could tell, due to hardware failures or me being an idiot. -dsr-
Re: systemd nfs mount blocked until first entered
Hello, this is the full unit: # /etc/systemd/system/vdr.service [Unit] Description=Video Disk Recorder Wants=systemd-udev-settle.service After=systemd-udev-settle.service [Service] Type=notify ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh "commands" ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh "reccmds" ExecStart=/usr/bin/vdr Restart=on-failure RestartPreventExitStatus=0 2 [Install] WantedBy=multi-user.target # /etc/systemd/system/vdr.service.d/override.conf [Unit] After=remote-fs.target Requires=remote-fs.target I only added the x-systemd options to /etc/fstab because the filesystems where not mounted at boot time at all with the old fstab options that I used before the upgrade to Debian (I did use yavdr before - a distro that was based on a super old 12.x version of Ubuntu). There I just used 192.168.1.2:/video /video nfs defaults,rsize=8192,wsize=8192,soft,nolock,noatime 0 0 If I try with this entry, the auto-generated video.mount unit fails as it seems to be started too early: ● video.mount - /video Loaded: loaded (/etc/fstab; generated) Active: failed (Result: exit-code) since Fri 2021-07-02 19:26:02 CEST; 2min 46s ago Where: /video What: 192.168.1.2:/video Docs: man:fstab(5) man:systemd-fstab-generator(8) Jul 02 19:26:02 vdr systemd[1]: Mounting /video... Jul 02 19:26:02 vdr mount[403]: mount.nfs: Network is unreachable Jul 02 19:26:02 vdr systemd[1]: video.mount: Mount process exited, code=exited, status=32/n/a Jul 02 19:26:02 vdr systemd[1]: video.mount: Failed with result 'exit-code'. Jul 02 19:26:02 vdr systemd[1]: Failed to mount /video. Best regards, Reiner Am Fr., 2. Juli 2021 um 19:15 Uhr schrieb Reco : > Hi. > > On Fri, Jul 02, 2021 at 06:12:58PM +0200, Reiner Buehl wrote: > > I have a directory that is mounted via NFS from a remote server. > > Actually, you have an autofs mountpoint, because you set > x-systemd.automount option in fstab. > Only if something starts using that mountpoint an NFS filesystem should > be mounted there. > > In another words - you do not require your NFS filesystem to be mounted > at boot time, and thus remote-fs.target does not include your NFS > filesystem. > > > > If I boot the vdr daemon fails during startup with the error message > > In other words, vdr fails to trigger automounting of the filesystem in > question. As usual with journald, the actual reason of this is not > present in this log. > > > > The vdr.service has an override of > > > > [Unit] > > After=remote-fs.target > > Requires=remote-fs.target > > > > to ensure that the filesystem is mounted. > > These dependencies are useless for your service given the current state > of your fstab. > The reason being - "autofs" filesystems belong to local-fs.target, not > remote-fs.target, and explicitly depending on local-fs.target is useless > anyway (it's one of the default dependencies for the most units). > What you probably need here is a dependency for a .mount unit > corresponding to your NFS filesystem. > > > > If I try to restart vdr.service, it fails again with the same error but > if > > I just cd to the directory and then try to restart it, it starts and > works > > fine. > > Can you show the result of "systemctl cat vdr" please? > > > What is systemd doing here that blocks the mount point for the vdr > process? > > Many things are possible here. You have ProtectSystem=full set in unit, > or you have PrivateMounts=true set in there. > > > Do I need different fstab options? > > It depends. x-systemd.automount is useful, because it does not require > your NFS server to be present at boot time. > I'll refrain from suggesting certain hacks for now, I'd like to see your > unit in full first. > > Reco > >
Publish guest contributions
"Hi, We need an advertising space with do-follow links on your blog security-tracker.debian.org. • We provide 500+ words • no copy article • the duration will be a minimum of 1 year Can you please write to us if possible to place an article with a link leading to betting related site and how much it will cost? Please let me know if you are interested. Stay safe and healthy. Regards, "
Re: Wanted: a special purpose Debian installer
On Thu 01 Jul 2021 at 16:24:12 +0100, Brian wrote: [..] > on the system. So...a D-I bug? Quite possibly, but my involvement with it ends here. Others can pursue it in a suitable report. Note that the installation with "recommends=false" still sets up the system not to install recommended packages. A user really does need to know what he is doing with the commandline options given to D-I, whether or not they work. -- Brian.
Re: How do I get back the GRUB menu with the blue background?
Stella Ashburne wrote: > 7. Debian Testing was installed on the 100GB partition. Installation was > successful. > > 8. However, I am now unable to boot into the GRUB menu with the blue > background. Instead all I have is a black screen with the word grub> _ > (The underscore is actually the position of the cursor) > > After reading some stuff on the internet, please tell me if my > understanding of the following is correct: > > Grub's UEFI Stub is located in EFI System Partition (ESP) while its second > stage modules are in the /boot partition. /boot also contains Grub's > config file. It would appear that the bootloader in ESP is not updated to > match the modules in the /boot partition or it could be that > /boot/grub/grub.cfg is missing. > > Below's my attempt at getting back the Grub menu with the blue background: > > A. I used Debian Bullseye's weekly installer to boot up my machine and > chose Rescue mode. As this is a fresh installation, why don't you just wipe everything linux partitions and install again the way you want it. Alternatively boot into a usb or live cd or installer, mount the volumes and chroot into (there are many howtos) I use something like following where SYSTEM is the target ppath mount --make-unbindable -obind /proc/ $SYSTEM/proc/ && \ mount --make-unbindable -obind /dev/ $SYSTEM/dev/ && \ mount --make-unbindable -obind /dev/pts $SYSTEM/dev/pts && \ mount --make-unbindable -obind /run $SYSTEM/run && \ mount --make-unbindable -obind /sys $SYSTEM/sys/ && \ chroot $SYSTEM su - when you are there reinstall grub and run update-grub I hope this helps
Re: systemd nfs mount blocked until first entered
Hi. On Fri, Jul 02, 2021 at 06:12:58PM +0200, Reiner Buehl wrote: > I have a directory that is mounted via NFS from a remote server. Actually, you have an autofs mountpoint, because you set x-systemd.automount option in fstab. Only if something starts using that mountpoint an NFS filesystem should be mounted there. In another words - you do not require your NFS filesystem to be mounted at boot time, and thus remote-fs.target does not include your NFS filesystem. > If I boot the vdr daemon fails during startup with the error message In other words, vdr fails to trigger automounting of the filesystem in question. As usual with journald, the actual reason of this is not present in this log. > The vdr.service has an override of > > [Unit] > After=remote-fs.target > Requires=remote-fs.target > > to ensure that the filesystem is mounted. These dependencies are useless for your service given the current state of your fstab. The reason being - "autofs" filesystems belong to local-fs.target, not remote-fs.target, and explicitly depending on local-fs.target is useless anyway (it's one of the default dependencies for the most units). What you probably need here is a dependency for a .mount unit corresponding to your NFS filesystem. > If I try to restart vdr.service, it fails again with the same error but if > I just cd to the directory and then try to restart it, it starts and works > fine. Can you show the result of "systemctl cat vdr" please? > What is systemd doing here that blocks the mount point for the vdr process? Many things are possible here. You have ProtectSystem=full set in unit, or you have PrivateMounts=true set in there. > Do I need different fstab options? It depends. x-systemd.automount is useful, because it does not require your NFS server to be present at boot time. I'll refrain from suggesting certain hacks for now, I'd like to see your unit in full first. Reco
Re: systemd nfs mount blocked until first entered
On Fri, Jul 02, 2021 at 06:12:58PM +0200, Reiner Buehl wrote: > I have a directory that is mounted via NFS from a remote server. The mount > is done via an /etc/fstab entry like this: > > 192.168.1.2:/video /video nfs > defaults,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,rsize=8192,wsize=8192,soft,nolock,noatime > 0 0 That's a lot of options. I wonder what they all do. If you simply boot the machine and then login and run 'df', do you see the file system mounted? I'm wondering in particular about that x-systemd.automount option. Does that mean something like "don't mount this until I think someone really wants it"? https://manpages.debian.org/buster/systemd/systemd.automount.5.en.html says that these are "activated when the automount path is accessed", but it doesn't say what counts as "accessed". I wonder if removing the x-systemd.automount option would help you. The other thing you'll want to look at is how your network interface is configured. You've got x-systemd.requires=network-online.target which *sounds* reasonable, but only if the network interface is actually configured to be waited upon. If you're using /etc/network/interface (the Debian default) for your interface config, make sure the interface is marked as "auto", rather than as "allow-hotplug". The latter causes systemd NOT to wait for the interface. Make sure it says "auto" instead.
systemd nfs mount blocked until first entered
Hi all, I have a directory that is mounted via NFS from a remote server. The mount is done via an /etc/fstab entry like this: 192.168.1.2:/video /video nfs defaults,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,rsize=8192,wsize=8192,soft,nolock,noatime 0 0 If I boot the vdr daemon fails during startup with the error message vdr.service - Video Disk Recorder Loaded: loaded (/etc/systemd/system/vdr.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/vdr.service.d └─override.conf Active: failed (Result: exit-code) since Thu 2021-07-01 23:27:25 CEST; 8h ago Process: 523 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh commands (code=exited, status=0/SUCCESS) Process: 533 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh reccmds (code=exited, status=0/SUCCESS) Process: 543 ExecStart=/usr/bin/vdr (code=exited, status=2) Main PID: 543 (code=exited, status=2) Jul 01 23:27:25 vdr systemd[1]: Starting Video Disk Recorder... Jul 01 23:27:25 vdr vdr[543]: [543] ERROR: can't access /video Jul 01 23:27:25 vdr vdr[543]: vdr: can't access video directory /video Jul 01 23:27:25 vdr systemd[1]: vdr.service: Main process exited, code=exited, status=2/INVALIDARGUMENT Jul 01 23:27:25 vdr systemd[1]: vdr.service: Failed with result 'exit-code'. Jul 01 23:27:25 vdr systemd[1]: Failed to start Video Disk Recorder. The vdr.service has an override of [Unit] After=remote-fs.target Requires=remote-fs.target to ensure that the filesystem is mounted. If I try to restart vdr.service, it fails again with the same error but if I just cd to the directory and then try to restart it, it starts and works fine. What is systemd doing here that blocks the mount point for the vdr process? Do I need different fstab options? Best regards, Reiner
Re: x-window-manager alternative missing
On 2021-07-02 at 12:01, Siard wrote: > The Wanderer: > >> What package, or packages, set(s) up the x-window-manager alternative >> and define(s) symlinks for it? > > To set the default x-window-manager, you can use: > ># update-alternatives --config x-window-manager As far as I'm aware, that will only work if the x-window-manager alternative group is already defined. The problem I was seeing was that there *was* no such group defined to exist; i.e., such things as the /etc/alternatives/x-window-manager symlink did not exist. I ended up using # update-alternatives --install /usr/bin/x-window-manager x-window-manager /path/to/my/WM 95 where '95' was chosen because that's the priority of the existing alternative on the system I'm using as the base for comparison. > To only see the available (i.e. installed) x-window-managers: > >$ update-alternatives --list x-window-manager Or, for more information about the link group, '--query'. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: x-window-manager alternative missing
The Wanderer: > What package, or packages, set(s) up the x-window-manager alternative > and define(s) symlinks for it? To set the default x-window-manager, you can use: # update-alternatives --config x-window-manager To only see the available (i.e. installed) x-window-managers: $ update-alternatives --list x-window-manager
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 02/07/21 à 10:18, BERTRAND Joël a écrit : > Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte > graphique. > Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de > carte-mère sans que cela soit réglable Ben, j'ai vraiment fait toutes les pages de paramétrage du bios et rien vu là-dessus (c'est une machine d'entrée de gamme qui ne peut pas recevoir de carte graphique dédiée, ceci explique peut-être cela). C'est peut-être une "amélioration" sur cette carte (ou le bios) qui allouerait d'office au GPU la RAM nécessaire à gérer sa résolution max (vu qu'on peut ajouter des écrans à chaud il vaut mieux que le GPU ait la RAM nécessaire), j'en sais trop rien… Il s'agit d'un cpu i5 de 10e génération, et vu que 32, 64 ou 128Mo ne changent pas grand chose quand tu as plusieurs Go de RAM (de 4 à 16 sur cette machine), ce bios dell fait peut-être cette allocation au max de manière systématique, ce serait pas idiot. La commande `free -b` m'annonce 16159100 bytes au total, ce qui fait 15.41Gio (je suppose qu'une barette annoncée pour 16G fait 16Gio, donc ici y'aurait ~600Mio qui auraient été consommé par qqun) En tout cas merci pour tes explications. -- Daniel Le génie, c'est 1% d'inspiration et 99% de transpiration. Edison
Re: Font color selection in MATE terminal
Siard writes: > On Thu, 1 Jul 2021 22:37 -0700, Marc Shapiro wrote: >> On 6/22/21 9:23 AM, Siard wrote: >> > In the MATE Terminal settings (Edit > Profile Preferences), >> > tab 'Colors', under 'Palette', set 'Built-in schemes' to 'Custom' >> > and change every color in the color palette to black. >> > >> > Here is a screenshot: >> > https://i.postimg.cc/2yv17y3Y/mateterminalcolors.png >> >> Why select 'Custom'? >> >> Richard needs black on white, so he should select 'Black on white'. >> It works for me. I have been using 'Custom', Yellow on Black, like >> my first monitor many years ago. But selecting 'Black on white' >> gives exactly that. > > Yes, but it did not work for Richard, and as 'Custom' worked for me, > I came with this solution. > Later, it turned out that it was caused by a glitch in MATE Terminal > 1.16.3, used in Debian 9. Later versions worked fine. > So 'Black on white' is indeed the most obvious way. Strangely, I am using MATE terminal 1.20 and now it is not working. I have a profile called Black and White. I change the colour profile preferences to the black and white scheme, but when I launch emacs -nw, it displays blue underlined text in places. And when I go back and look at the colour preferences in MATE it has gone back to custom.
Re: x-window-manager alternative missing
On 2021-07-02 at 11:39, Greg Wooledge wrote: > On Fri, Jul 02, 2021 at 11:14:22AM -0400, The Wanderer wrote: > >> What package, or packages, set(s) up the x-window-manager >> alternative and define(s) symlinks for it? > > I take it from the content that I snipped that you're looking for a > list of window managers, and not a technical explanation of how the > alternatives system works. Not exactly - I was looking for anything that would set up that symlink, without necessarily assuming that every window-manager package would do it separately. If they do, however, then yes, that list - or at least a statement that "every window manager sets this up directly, independently of all the others" - would be the answer I was looking for. > For a list of x-window-managers, you can use: > > apt-cache showpkg x-window-manager > > Ignore everything up until "Reverse Provides:". That's the part you > want. I actually got to the point of looking for this technique during my own searching, but hadn't landed on it. Thanks for the pointer! In the end, a conversation with someone else ended up leading me to the conclusion that in fact what I hypothesized at the end of my previous mail is correct: it was set up by some previous package, I adjusted it to add the alternative for my locally-built but non-packaged WM, and then the package that originally set it up got removed. So I've just created it manually on the new machine, rather than dancing around with installing and removing packages I don't actually intend to use. It's up and running now. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: x-window-manager alternative missing
On Fri, Jul 02, 2021 at 11:14:22AM -0400, The Wanderer wrote: > What package, or packages, set(s) up the x-window-manager alternative > and define(s) symlinks for it? I take it from the content that I snipped that you're looking for a list of window managers, and not a technical explanation of how the alternatives system works. For a list of x-window-managers, you can use: apt-cache showpkg x-window-manager Ignore everything up until "Reverse Provides:". That's the part you want. It should also be noted that x-session-manager is used preferentially over x-window-manager, and some of the things that you might normally call a window manager actually end up being registered as an x-session-manager instead. So: apt-cache showpkg x-session-manager Again, ignore everything before "Reverse Provides:".
Re: Useful use of dd [was: Useless use of "dd"]
On Fri, Jul 02, 2021 at 10:02:49AM -0500, David Wright wrote: > On Fri 02 Jul 2021 at 13:35:17 (+0200), to...@tuxteam.de wrote: [...] > > Eek. Thanks. > > This reminds me of the sentiment expressed in > https://lists.debian.org/debian-user/2019/08/msg01454.html :-) Cheers - t signature.asc Description: Digital signature
Re: x-window-manager alternative missing
On Fri 02 Jul 2021 at 11:14:22 (-0400), The Wanderer wrote: > What package, or packages, set(s) up the x-window-manager alternative > and define(s) symlinks for it? > > I'm building a new computer, and setting up my (Debian-based) preferred > configuration on it, and I've just discovered that there is no > x-window-manager alternative defined; as a result, running startx > results in invoking x-terminal-emulator instead, which brings up X in a > very '80s-looking display and launches a single xterm. > > I could certainly just create the appropriate alternatives group myself, > based on what's already in place on the system I'm preparing to replace > with this new one, but I'd rather do this the right way unless there's > no clear viable alternative. However, I haven't so far managed to > identify what the Debian-native "right way" to get this set up is; on > all the previous computers I remember building, once I installed the > usual collection of make-X-available packages - specifically, that I > remember, xinit (for startx) and xserver-xorg - this is one detail that > Just Worked. > > I'm guessing that installing any of the various packages which have > "Provides: x-window-manager" might do it, but the computer I'm preparing > to replace doesn't have any of those installed, and still has the > x-window-manager alternative. (I run a WM which I compile and install > locally, rather than via a Debian package.) > > If I recall correctly, one of those packages probably *was* installed at > some early point in the original installation of the being-replaced > computer (now nearly a decade ago), so it's possible that installing it > set up the alternatives group and then I just reconfigured that group to > my preferred target, so removing the package didn't result in removing > the group... in which case installing one such package temporarily > should get things working, but it might make more sense to just create > the alternatives group by hand. Perhaps either install something simple enough to uninstall, like fvwm, or download the same and follow the postinst script. Basically, installing a window manager installs the alternatives scheme. Cheers, David.
Re: Debian Linux keyboard mapping files ...
On 7/2/21, Greg Wooledge wrote: > you're starting from some MASSIVELY incorrect assumptions, > but up until now, correcting all the background noise was never > important, because you were just poking around out of curiosity. Or so > we thought. I don't understand why "we" think "I was just poking around out of curiosity" (provided "we" has some powerful mind reading skills). I had spent some time finding such files and I thought there should be a way to somehow get such files out of Debian's installation disks. I also realized why I couldn't find the link that was suggested to me. I always exclude Windows results from google searches. I also included the results here in case anyone else has such needs. lbrtchx
x-window-manager alternative missing
What package, or packages, set(s) up the x-window-manager alternative and define(s) symlinks for it? I'm building a new computer, and setting up my (Debian-based) preferred configuration on it, and I've just discovered that there is no x-window-manager alternative defined; as a result, running startx results in invoking x-terminal-emulator instead, which brings up X in a very '80s-looking display and launches a single xterm. I could certainly just create the appropriate alternatives group myself, based on what's already in place on the system I'm preparing to replace with this new one, but I'd rather do this the right way unless there's no clear viable alternative. However, I haven't so far managed to identify what the Debian-native "right way" to get this set up is; on all the previous computers I remember building, once I installed the usual collection of make-X-available packages - specifically, that I remember, xinit (for startx) and xserver-xorg - this is one detail that Just Worked. I'm guessing that installing any of the various packages which have "Provides: x-window-manager" might do it, but the computer I'm preparing to replace doesn't have any of those installed, and still has the x-window-manager alternative. (I run a WM which I compile and install locally, rather than via a Debian package.) If I recall correctly, one of those packages probably *was* installed at some early point in the original installation of the being-replaced computer (now nearly a decade ago), so it's possible that installing it set up the alternatives group and then I just reconfigured that group to my preferred target, so removing the package didn't result in removing the group... in which case installing one such package temporarily should get things working, but it might make more sense to just create the alternatives group by hand. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
x-window-manager alternative missing
What package, or packages, set(s) up the x-window-manager alternative and define(s) symlinks for it? I'm building a new computer, and setting up my (Debian-based) preferred configuration on it, and I've just discovered that there is no x-window-manager alternative defined; as a result, running startx results in invoking x-terminal-emulator instead, which brings up X in a very '80s-looking display and launches a single xterm. I could certainly just create the appropriate alternatives group myself, based on what's already in place on the system I'm preparing to replace with this new one, but I'd rather do this the right way unless there's no clear viable alternative. However, I haven't so far managed to identify what the Debian-native "right way" to get this set up is; on all the previous computers I remember building, once I installed the usual collection of make-X-available packages - specifically, that I remember, xinit (for startx) and xserver-xorg - this is one detail that Just Worked. I'm guessing that installing any of the various packages which have "Provides: x-window-manager" might do it, but the computer I'm preparing to replace doesn't have any of those installed, and still has the x-window-manager alternative. (I run a WM which I compile and install locally, rather than via a Debian package.) If I recall correctly, one of those packages probably *was* installed at some early point in the original installation of the being-replaced computer (now nearly a decade ago), so it's possible that installing it set up the alternatives group and then I just reconfigured that group to my preferred target, so removing the package didn't result in removing the group... in which case installing one such package temporarily should get things working, but it might make more sense to just create the alternatives group by hand. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Whole Disk Encryption + SSD
On Fri, Jul 02, 2021 at 10:02:18AM -0500, David Wright wrote: But what happens with an SSD? If, after the rm step above, you # fstrim /home the mountpoint, where /etc/fstab has the line /dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home then what gets zeroed If everything's appropriately configured the free sectors will be marked as unused by the SSD and erased for reuse.
Re: Useful use of dd [was: Useless use of "dd"]
On Fri 02 Jul 2021 at 13:35:17 (+0200), to...@tuxteam.de wrote: > On Fri, Jul 02, 2021 at 07:31:24AM -0400, Greg Wooledge wrote: > > On Fri, Jul 02, 2021 at 09:49:23AM +0200, to...@tuxteam.de wrote: > > > sudo dd of=/etc/hosts oflags=append > > > > This appears to be a typo for "oflag=append", which is a GNU extension, > > not part of the standard POSIX dd. No wonder I didn't know about it. ;-) > > > > The bullseye version of GNU coreutils dd also gives a warning message > > with this particular flag: > > > > unicorn:~$ echo g | dd of=foo oflag=append > > dd: you probably want conv=notrunc with oflag=append > > 0+1 records in > > 0+1 records out > > 2 bytes copied, 9.141e-05 s, 21.9 kB/s > > > > Not sure if that's unique to bullseye. But anyway, yes, the warning > > is accurate; without conv=notrunc, my test file "foo" got overwritten > > with just the "g". > > Eek. Thanks. This reminds me of the sentiment expressed in https://lists.debian.org/debian-user/2019/08/msg01454.html Cheers, David.
Re: Whole Disk Encryption + SSD
On Thu 01 Jul 2021 at 20:43:09 (-0700), David Christensen wrote: > On 7/1/21 7:55 PM, David Wright wrote: > > On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote: > > > > > I do not set the 'discard' (trim) option in fstab(5). If and when I > > > want to erase unused blocks (such as before taking an image), I use > > > fstrim(8). > > > > Can you elaborate on a couple of things: > > > > How do you "take an image". Is this equivalent to a conventional > > dd if=/dev/sda …, or to some other process? > > I wrote a script. To "take an image", the script invokes dd(1) and > pipes the output to gzip(1), copying raw device octets to a file. To > "restore an image", the process is reversed. > > > > When I copy an entire conventional drive or partition, all the > > free blocks/unused sectors are carefully transferred to the copy. > > Same here. > > > > What improvement does erasing unused blocks achieve? > > Zero blocks are readily compressed, reducing the size of the image file. Ah, I see. So a spinning rust analogy might be: . Take an old conventional disk, sdz, where df shows 10% uasge, . cp /dev/zero a-file-on-sdz . rm a-file-on-sdz . dd if=/dev/sdz … and compressing it, saving ~90% space. But can I tweak my question a little— Say that /dev/sdz contained one partition, sdz1, which filled the disk and was a LUKS encrypted /home. In this case, the above would fail to save space because the raw device sdz would be full of "random" data. But what happens with an SSD? If, after the rm step above, you # fstrim /home the mountpoint, where /etc/fstab has the line /dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home then what gets zeroed, the container or the contained? I can't put my finger on any documentation that spells it out. Cheers, David.
Re: Btrfs scrub going past 100%
Paul wrote: > I run regular btrfs scrubs through btrfsmaintenance on my disk array without > issues. This time, though, the scrub percentage went over 100%. I kept it > running so that I can file a bug if this is one. > > Which package do I file this against? I believe it's in the Linux kernel not > btrfs-progs, but I thought I would ask since I'm new to this. > > UUID: ---- > Scrub started: Thu Jul 1 00:03:28 2021 > Status: running > Duration: 37:13:49 > Time left: 21358913:01:19 > ETA: Mon Feb 11 06:18:36 4458 > Total to scrub: 29.08TiB > Bytes scrubbed: 29.24TiB (100.56%) > Rate: 228.79MiB/s > Error summary: no errors found Reported to the btrfs list last year, doesn't look like there's any followup. Check out your time left calculation, too. https://lore.kernel.org/linux-btrfs/a17a65d0-68d4-e220-0b2d-5c19cdc7b...@petaramesh.org/ It is probably significant that over the last year, I see a fair number of issues with crashes and unrecoverable data on the btrfs list. On the ZFS list, most of the discussion is about optimal configurations. -dsr-
Re: Problemes amb un mòdul de python
Benvolguts, He pogut resoldre-ho afegint el fitxer ~/.config/python_keyring/keyringrc.cfg amb el contingut següent: > # Fitxer creat per mirar de resoldre el problema amb l'autenticació del > protonvpn-cli > # > > [backend] > default-keyring=keyring.backends.SecretService.Keyring I funciona, tinc que mirar quines implicacions te aquesta declaració: "default-keyring=keyring.backends.SecretService.Keyring" Bé, bé està el que bé acaba. -- Xavier De Yzaguirre i Maura xdeyzaguirre at protonmail(dot)ch S
Re: Useful use of dd
On Fri, Jul 02, 2021 at 01:26:23PM +0300, Teemu Likonen wrote: * 2021-07-02 09:49:23+0200, to...@tuxteam.de wrote: FWIW, I've found something which could be deemed to be an "useful use of dd" which somehow bears a hidden symmetry. As a replacement for `cat' whenever you need to put a name on the output file. For this new subject I will add another use: quickly create empty file of specific size, for example 5 * 1024 bytes: $ dd of=empty obs=1024 seek=5 count=0 For this it is IMO more clear to use truncate: truncate -s 5k empty On Fri, Jul 02, 2021 at 07:31:24AM -0400, Greg Wooledge wrote: On Fri, Jul 02, 2021 at 09:49:23AM +0200, to...@tuxteam.de wrote: sudo dd of=/etc/hosts oflags=append This appears to be a typo for "oflag=append", which is a GNU extension, not part of the standard POSIX dd. No wonder I didn't know about it. ;-) Because you've been asleep since the 80s when POSIX was relevant? :-D The bullseye version of GNU coreutils dd also gives a warning message with this particular flag: unicorn:~$ echo g | dd of=foo oflag=append dd: you probably want conv=notrunc with oflag=append 0+1 records in 0+1 records out 2 bytes copied, 9.141e-05 s, 21.9 kB/s Not sure if that's unique to bullseye. But anyway, yes, the warning is accurate; without conv=notrunc, my test file "foo" got overwritten with just the "g". It's been like that for more than a decade, sarge in the debian timeline. The warning was added for obvious reasons. :-) (There is a narrow use case for append without notrunc, which is why it's a warning and not a fatal error.)
Re: Debian Linux keyboard mapping files ...
On Fri, Jul 02, 2021 at 02:24:20AM -0400, Albretch Mueller wrote: > From your examples you included I will only need yielded glyphs if > they are commonly used in a language. Now, defining "commonly used" > would be an entirely different, yet valid question. > > I will have to code my way through those files to parse unicode <-> > key (or key sequence) "lookup tables" for each language and my effort > will need definitely more than "parsing" for non-alphabetical > languages. So, wait, you're NOT just abnormally curious? You actually believe you have some kind of REASON for wanting to know how the console and/or X keyboard input mechanism is implemented by Debian? If this is the case, stop messing around and TELL US what that reason is. What are you actually trying to do? As far as I've been able to tell with my rather limited knowledge of this topic, you're starting from some MASSIVELY incorrect assumptions, but up until now, correcting all the background noise was never important, because you were just poking around out of curiosity. Or so we thought.
Re: Useful use of dd [was: Useless use of "dd"]
On Fri, Jul 02, 2021 at 07:31:24AM -0400, Greg Wooledge wrote: > On Fri, Jul 02, 2021 at 09:49:23AM +0200, to...@tuxteam.de wrote: > > sudo dd of=/etc/hosts oflags=append > > This appears to be a typo for "oflag=append", which is a GNU extension, > not part of the standard POSIX dd. No wonder I didn't know about it. ;-) > > The bullseye version of GNU coreutils dd also gives a warning message > with this particular flag: > > unicorn:~$ echo g | dd of=foo oflag=append > dd: you probably want conv=notrunc with oflag=append > 0+1 records in > 0+1 records out > 2 bytes copied, 9.141e-05 s, 21.9 kB/s > > Not sure if that's unique to bullseye. But anyway, yes, the warning > is accurate; without conv=notrunc, my test file "foo" got overwritten > with just the "g". Eek. Thanks. Cheers - t signature.asc Description: Digital signature
Re: Useful use of dd [was: Useless use of "dd"]
On Fri, Jul 02, 2021 at 09:49:23AM +0200, to...@tuxteam.de wrote: > sudo dd of=/etc/hosts oflags=append This appears to be a typo for "oflag=append", which is a GNU extension, not part of the standard POSIX dd. No wonder I didn't know about it. ;-) The bullseye version of GNU coreutils dd also gives a warning message with this particular flag: unicorn:~$ echo g | dd of=foo oflag=append dd: you probably want conv=notrunc with oflag=append 0+1 records in 0+1 records out 2 bytes copied, 9.141e-05 s, 21.9 kB/s Not sure if that's unique to bullseye. But anyway, yes, the warning is accurate; without conv=notrunc, my test file "foo" got overwritten with just the "g".
Re: Font color selection in MATE terminal
On Thu, 1 Jul 2021 22:37 -0700, Marc Shapiro wrote: > On 6/22/21 9:23 AM, Siard wrote: > > In the MATE Terminal settings (Edit > Profile Preferences), > > tab 'Colors', under 'Palette', set 'Built-in schemes' to 'Custom' > > and change every color in the color palette to black. > > > > Here is a screenshot: > > https://i.postimg.cc/2yv17y3Y/mateterminalcolors.png > > Why select 'Custom'? > > Richard needs black on white, so he should select 'Black on white'. > It works for me. I have been using 'Custom', Yellow on Black, like > my first monitor many years ago. But selecting 'Black on white' > gives exactly that. Yes, but it did not work for Richard, and as 'Custom' worked for me, I came with this solution. Later, it turned out that it was caused by a glitch in MATE Terminal 1.16.3, used in Debian 9. Later versions worked fine. So 'Black on white' is indeed the most obvious way.
Re: Useful use of dd
* 2021-07-02 12:52:53+0200, Thomas Schmitt wrote: > Teemu Likonen wrote: >> For this new subject I will add another use: quickly create empty file >> of specific size, for example 5 * 1024 bytes: >>$ dd of=empty obs=1024 seek=5 count=0 > > Not to forget creation of sparse files with few disk consumption. My example above already does that. $ dd of=empty obs=100G seek=1 count=0 $ ls -gGlhs empty 0 -rw-r--r-- 1 100G 2021-07-02 14:21:18 empty Zero blocks actually allocated, so far. -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 signature.asc Description: PGP signature
Re: Useful use of dd
On Fri, Jul 02, 2021 at 12:52:53PM +0200, Thomas Schmitt wrote:
> Hi,
>
> Teemu Likonen wrote:
> > For this new subject I will add another use: quickly create empty file
> > of specific size, for example 5 * 1024 bytes:
> >$ dd of=empty obs=1024 seek=5 count=0
>
> Not to forget creation of sparse files with few disk consumption.
Nice.
And then, there's "oflag=sync". I hate it when the system says
"Done!" when writing to an USB stick, then I say "sync", and only
then the writing starts. For an unknown amount of time. Combine
with "status=progress" to taste :)
> For testing zisofs i have this in a script:
>
> #!/bin/bash
> # 100gb with big holes
> for i in {1..100}
> do
> echo $i | dd of=100gb bs=1 seek="$i"G 2>/dev/null
> done
>
> The resulting file "100gb" occupies 404 KB in an ext4 filesystem.
> (It shall not contain entirely zeros. So it is not the smallest possible
> 100 GiB file.)
nice, thanks.
Cheers
- t
signature.asc
Description: Digital signature
Re: Re: Buster on Win 10 Problems
Hi, you can run Debian on Virtualbox, but WSL is integrate in Windows, you can run application from app menu.
Re: Useful use of dd [was: Useless use of "dd"]
On Fri, Jul 02, 2021 at 01:26:23PM +0300, Teemu Likonen wrote: > * 2021-07-02 09:49:23+0200, to...@tuxteam.de wrote: > > > FWIW, I've found something which could be deemed to be an "useful use > > of dd" which somehow bears a hidden symmetry. As a replacement for > > `cat' whenever you need to put a name on the output file. > > For this new subject I will add another use: quickly create empty file > of specific size, for example 5 * 1024 bytes: > > $ dd of=empty obs=1024 seek=5 count=0 Clever :) Cheers - t signature.asc Description: Digital signature
Btrfs scrub going past 100%
Hello, I run regular btrfs scrubs through btrfsmaintenance on my disk array without issues. This time, though, the scrub percentage went over 100%. I kept it running so that I can file a bug if this is one. Which package do I file this against? I believe it's in the Linux kernel not btrfs-progs, but I thought I would ask since I'm new to this. Below is the scrub status:- user@pc ] sudo btrfs scrub status /mnt/SA1/ UUID: ---- Scrub started: Thu Jul 1 00:03:28 2021 Status: running Duration: 35:08:10 Time left: 0:38:00 ETA: Fri Jul 2 11:49:38 2021 Total to scrub: 29.07TiB Bytes scrubbed: 28.56TiB (98.23%) Rate: 236.75MiB/s Error summary: no errors found user@pc ] sudo btrfs scrub status /mnt/SA1/ UUID: ---- Scrub started: Thu Jul 1 00:03:28 2021 Status: running Duration: 37:13:49 Time left: 21358913:01:19 ETA: Mon Feb 11 06:18:36 4458 Total to scrub: 29.08TiB Bytes scrubbed: 29.24TiB (100.56%) Rate: 228.79MiB/s Error summary: no errors found Thanks
Re: Useful use of dd
Hi,
Teemu Likonen wrote:
> For this new subject I will add another use: quickly create empty file
> of specific size, for example 5 * 1024 bytes:
>$ dd of=empty obs=1024 seek=5 count=0
Not to forget creation of sparse files with few disk consumption.
For testing zisofs i have this in a script:
#!/bin/bash
# 100gb with big holes
for i in {1..100}
do
echo $i | dd of=100gb bs=1 seek="$i"G 2>/dev/null
done
The resulting file "100gb" occupies 404 KB in an ext4 filesystem.
(It shall not contain entirely zeros. So it is not the smallest possible
100 GiB file.)
Have a nice day :)
Thomas
Re: How do I get back the GRUB menu with the blue background?
Hi I see that you've not had any replies, so I'll attempt to assist. Even though I have no experience with GPT and UEFI, I have used LUKS and LVM. Thank you for making some effort to provide a detailed description of your situation. Please note that I have several questions (1, 2, 3) interleaved below, followed by some suggestions at the end. On Thu, 1 Jul 2021 at 23:20, Stella Ashburne wrote: > The partition table scheme is GPT and UEFI with Secure Boot is enabled. > I do not use legacy BIOS with master boot record. > Below is the partition layout of my SDD: 1) Do you mean "SSD". If not, what is SDD? > 536.9MB EFI system partition (ESP) > 511.7MB /boot (unencrypted) > 100GB encrypted logical volumes (contains 99GB of / partition, 1GB of swap > area.Debian Buster was installed on this partition) > 16MB Microsoft reserved area (automatically created by Microsoft Windows' > installer) > 100GB Microsoft Windows 10 > 1. Debian Buster's 64bit installer (version 10.10) was used to create the EFI > System Partition (ESP), the /boot partition and the encrypted logical > volumes. Installation was successful and I was able to boot into the GRUB > menu with a blue background. It had an entry named Debian GNU/Linux. > 2. Next I installed Microsoft Windows 10 and the installation was successful. > 3. I rebooted into Debian and used sudo os-prober to add the Microsoft > Windows' entry to GRUB followed by sudo update-grub > 4. Dual-boot of Debian and Windows was possible Ok. > Problem(s) happened after I did the following: > 5. With a USB stick containing the latest weekly build of Debian Testing > (Bullseye), I booted into the Debian's installer screen and deleted the 100GB > encrypted logical volumes. > 6. As a result, 100GB of free space was made available. I configured it to > have two encrypted logical volumes: 99GB of the / partition, 1GB of swap area. > 7. Debian Testing was installed on the 100GB partition. Installation was > successful. > 8. However, I am now unable to boot into the GRUB menu with the blue > background. Instead all I have is a black screen with the word grub> _ (The > underscore is actually the position of the cursor) There's a couple of things that might have gone wrong here. Exactly what is unclear at this stage. 2) Can you tell us, during your step 7, what instructions did you give to the installer at the "install a boot loader" stage? 3) And during the partitioning stages, can you tell us which existing devices (LUKS, LVM) did you attempt to reuse unchanged, and which did you recreate? >From my own experience, attempting to install into a pre-existing LVM logical volume on a LUKS physical volume, I did once see some unexpected failures. This might have been my error, or perhaps the installer might have some buggy behaviour in this kind of situation. I have not had time to investigate properly. If, in the installer, you were to start again from the device partition, and freshly create the LUKS device and the LVM logical volumes from scratch, then I would expect that to work. However if you were attempting to re-use any of these then I am less confident, after seeing possible failure myself. Even so, this might not be anything to do with your issue, and I suggest doing some inspection at the grub prompt before giving up on your existing installation and redoing it from scratch. I suggest to boot as you describe above (your step #8) until you reach the 'grub>' prompt. This is actually a very useful prompt but you need to know some tricks to use it. So begin by reading this page: https://www.gnu.org/software/grub/manual/grub/html_node/Naming-convention.html#Naming-convention The first trick is this command: grub> set pager=1 It makes the help command more usable. grub> help The next trick is to use tab-completion, as described in that documentation, as a way of getting grub to show you which devices and files it is aware of. For example, if you type: grub> ls ( and then press the tab key, grub should respond with a list of the devices it is aware of. Then each of those devices can be explored using the naming syntax as described in the documentation. For example, if one of your devices is (hd0,msdos1), you can type: grub> ls (hd0,msdos1)/ and then press the tab key, to see what files grub can see in the root directory of that device. You can use this method to try to find which device and directory contains your grub directory. It will look something like (hd0,msdos1)/grub and will contain the grub files including your grub.cfg menu. You could then use grub's 'cat' command to inspect the UUIDs it is attempting to use. However that's probably not useful at this time. When you find your grub.cfg, that is progress, and you can try booting from that menu. grub> configfile (hd0,msdos1)/path/to/grub.cfg However I expect that will not succeed, because the default grub.cfg by default uses UUID to identify all devices. And because you reinstalled (your step
Re: Useful use of dd [was: Useless use of "dd"]
* 2021-07-02 09:49:23+0200, to...@tuxteam.de wrote: > FWIW, I've found something which could be deemed to be an "useful use > of dd" which somehow bears a hidden symmetry. As a replacement for > `cat' whenever you need to put a name on the output file. For this new subject I will add another use: quickly create empty file of specific size, for example 5 * 1024 bytes: $ dd of=empty obs=1024 seek=5 count=0 -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 signature.asc Description: PGP signature
Re: How to verify newly burned disc
Hi, i wrote: > > You would need a filter program which takes care not to read more than > > ~ 20 MB/s. Then the [Pioneer BDR-S09] drive slows down automatically. Michael Lange wrote: > I see, that does not sound trivial, at least to me :) It would be a nice first exercise in about any programming language. The first time i implemented such a thing was for a QIC tape drive which overheated when running at full speed. At the begin of this thread: > > > [...] I finally picked no. 1 of 2 of these Asus DRW-24D5MTs [...] > So far the Asus managed to pass all tests, so probably I should just be > grateful to all the transcendental authorities that guided my hand when I > picked that carton from the shelf :) Does yours pull in the tray automatically after 200 seconds of standing out ? I made a little poll here about this behavior, 1.5 years ago: https://lists.debian.org/debian-user/2020/01/msg00421.html Overview of result: https://lists.debian.org/debian-user/2020/02/msg00758.html I wonder whether this is related to this obscure description on https://www.asus.com/Motherboards-Components/Optical-Drives/Internal-DVD-Drive/DRW-24D5MT/ "E-Green technology auto-closes drive application when not in use, saving over 50% power consumption for users" (What might be meant by "drive application" ?) Have a nice day :) Thomas
Re: Wanted: a special purpose Debian installer
On Fri 02 Jul 2021 at 04:55:04 -0500, Richard Owlett wrote: > On 07/01/2021 04:52 PM, Brian wrote: > > On Thu 01 Jul 2021 at 16:34:46 -0400, Felix Miata wrote: > > > > > Brian composed on 2021-07-01 21:05 (UTC+0100): > > > > > > > On Thu 01 Jul 2021 at 12:40:05 -0400, Felix Miata wrote: > > > > > > > > > > > Dunno what to tell you. Maybe that's because I always include also > > > > > tasks=standard > > > > Extremely unlikely. In fact, impossible. > > > > > > > > > Interesting claim. Care to explain further? > > > > Not particularly. The standard task does not pull in anything to > > account for mine or Richard's observations. > > That has not been established. It has been here. > > In fact, I did not install it. > > *BUT* I had made the assumption that his use of "tasks=standard" was > functionally equivalent to me checking "standard system utilities" in the > menu. It is. > I suspect that what the installer does when I check mark any menu item may > not match what I expect. Probably. > > > > Over to you and your imagination. > > > > Courtesy please. Indeed. Apologies, Felix. -- Brian.
Re: Wanted: a special purpose Debian installer
On 07/01/2021 04:52 PM, Brian wrote: On Thu 01 Jul 2021 at 16:34:46 -0400, Felix Miata wrote: Brian composed on 2021-07-01 21:05 (UTC+0100): On Thu 01 Jul 2021 at 12:40:05 -0400, Felix Miata wrote: Dunno what to tell you. Maybe that's because I always include also tasks=standard Extremely unlikely. In fact, impossible. Interesting claim. Care to explain further? Not particularly. The standard task does not pull in anything to account for mine or Richard's observations. That has not been established. In fact, I did not install it. *BUT* I had made the assumption that his use of "tasks=standard" was functionally equivalent to me checking "standard system utilities" in the menu. I suspect that what the installer does when I check mark any menu item may not match what I expect. Over to you and your imagination. Courtesy please.
Re: Plantages Xorg (i915, context reset due to GPU hang)
Daniel Caillibaud a écrit : > Le 01/07/21 à 21:03, BERTRAND Joël a écrit : >> Je ne me souviens pas, mais quelle est la taille de la mémoire >> graphique sur la machine en question ? > > Aucune idée… > > Comment je peux voir ça ? Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte graphique. J'ai fait la bêtise sur un poste de bureautique avec un i5 de limiter cette taille à 32 ou 64 Mo (je ne sais plus) et j'ai observé tout un tas de plantages divers et variés que ce soit sous Linux ou sous FreeBSD que, naturellement, personne n'arrivait à reproduire. Les applications qt5 plantaient immédiatement, les autres, beaucoup plus aléatoirement en fonction des allocations mémoires demandées par les bibliothèques graphiques (OpenGL est connue pour bufferiser côté client et ne balancer qu'une seule requête sans vérification côté serveur quitte à dépasser la mémoire de la carte graphique ou sa capacité d'adressage. En CAO, ça peut être rigolo, un outil comme KiCAD pouvant morceler ses requêtes sans empêcher OpenGL de balancer une requête ne tenant pas sur l'espace d'adressage du GPU qui est de 32 bits pour un i7-4490 !... Si ça, ce n'est pas un bug, je ne sais pas ce que c'est !). J'ai subi cela jusqu'au moment où j'ai tenté l'augmentation à 128 Mo et là, miracle, tout fonctionnait. >> Ça vaut le coup d'augmenter la taille pour voir si cela change quelque chose. > > J'ai fouillé tous les paramètres du bios en mode avancé mais rien trouvé qui > me permette de > choisir ça. > > Vu que c'est le chipset vidéo embarqué sur le CPU qui gère ça, il se sert pas > tout seul dans la > RAM en fonction de ses besoins ? Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de carte-mère sans que cela soit réglable (pour les générations jusqu'à la 7e incluse, après cette aventure et comme j'ai besoin pour la CAO de carte graphique qui dépote avec un adressage d'au moins 8 Go, j'ai pris des CPU sans GPU et je ne me suis plus préoccupé de la chose). Sinon, les sorties de X devraient te renseigner. Le GPU ne peut se servir lui-même dans la RAM. Il doit initialiser la mémoire au démarrage en mémoire utilisable par le système et RAM graphique (sinon, le noyau ne connaît pas la limite). En dehors de quelques systèmes bien spécialisés, il est impossible de modifier la quantité de mémoire d'un système dynamiquement. Bien cordialement, JKB
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 01/07/21 à 21:03, BERTRAND Joël a écrit : > Je ne me souviens pas, mais quelle est la taille de la mémoire > graphique sur la machine en question ? Aucune idée… Comment je peux voir ça ? > Ça vaut le coup d'augmenter la taille pour voir si cela change quelque chose. J'ai fouillé tous les paramètres du bios en mode avancé mais rien trouvé qui me permette de choisir ça. Vu que c'est le chipset vidéo embarqué sur le CPU qui gère ça, il se sert pas tout seul dans la RAM en fonction de ses besoins ? C'est ce processeur https://ark.intel.com/content/www/us/en/ark/products/196603/intel-core-i5-1035g1-processor-6m-cache-up-to-3-60-ghz.html Dans ses specs (pdf "10th Gen Intel® Core™ Processor Families Datasheet, Volume 2 of 2" récupéré sur cette page) on peut lire ce qui suit (qui me cause pas vraiment) 2.9 Graphics Memory Address Ranges The integrated memory controller can be programmed to direct memory accesses to the Processor Graphics when addresses are within any of the ranges specified using registers in MCH Device 2 configuration space. • The Graphics Memory Aperture Base Register (GMADR) is used to access graphics memory allocated using the graphics translation table. • The Graphics Translation Table Base Register (GTTADR) is used to access the translation table and graphics control registers. This is part of the GTTMMADR register. These ranges can reside above the Top-of-Low-DRAM and below High BIOS and APIC address ranges. They should reside above the top of memory (TOLUD) and below 4 GB so they do not take any physical DRAM memory space. Alternatively, these ranges can reside above 4 GB, similar to other BARs that are larger than 32 bits in size. GMADR is a Prefetchable range in order to apply USWC attribute (from the processor point of view) to that range. The USWC attribute is used by the processor for write combining. 2.9.1 IOBAR Mapped Access to Device 2 MMIO Space Device 2, Processor Graphics, contains an IOBAR register. If Device 2 is enabled, Processor Graphics registers or the GTT table can be accessed using this IOBAR. The IOBAR is composed of an index register and a data register. MMIO_Index: MMIO_INDEX is a 32-bit register. A 32-bit (all bytes enabled) I/O write to this port loads the offset of the MMIO register or offset into the GTT that needs to be accessed. An I/O Read returns the current value of this register. I/O read/write accesses less than 32 bits in size (all bytes enabled) will not target this register. MMIO_Data: MMIO_DATA is a 32-bit register. A 32-bit (all bytes enabled) I/O write to this port is re-directed to the MMIO register pointed to by the MMIO-index register. An I/O read to this port is re-directed to the MMIO register pointed to by the MMIO-index register. I/O read/write accesses less than 32 bits in size (all bytes enabled) will not target this register. The result of accesses through IOBAR can be: • Accesses directed to the GTT table. (that is, route to DRAM) • Accesses to Processor Graphics registers with the device. • Accesses to Processor Graphics display registers now located within the PCH. (that is, route to DMI). Note: GTT table space writes (GTTADR) are supported through this mapping mechanism. This mechanism to access Processor Graphics MMIO registers should NOT be used to access VGA I/O registers that are mapped through the MMIO space. VGA registers should be accessed directly through the dedicated VGA I/O ports. 2.9.2 Trusted Graphics Ranges Trusted graphics ranges are NOT supported. -- Daniel Les Etats-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation. Albert Einstein.
Useful use of dd [was: Useless use of "dd"]
On Fri, Jul 02, 2021 at 08:40:39AM +0300, Teemu Likonen wrote: [...] > dd if=/dev/sdX | gzip >image.gz > > is slower but functionally the same as either of these: > > gzip image.gz > gzip --to-stdout /dev/sdX >image.gz Quite right -- akin to "useless use of cat". FWIW, I've found something which could be deemed to be an "useful use of dd" which somehow bears a hidden symmetry. As a replacement for `cat' whenever you need to put a name on the output file. I'll try to explain: sometimes, you use `cat' to populate a file from stdin -- say from a script like so: #!/bin/sh cat <<__EOF >> /etc/hosts 127.0.0.1 www.google-analytics.com __EOF Now assume you don't want your whole script running under root. A `sudo cat' (with a suitable setup) or some moral equivalent would suffice. But, alas! the output redirect `>>' is the one needing the higher privileges, and that's done by the shell around cat! The customary pattern here is `tee': it passes stdin through to stdout, and makes a "side copy" into a named file. So you'll see things like this blah blah | sudo tee myfile > /dev/null i.e. use `tee's "side copy" and throw away the straight stream. Now OCD [1] seems to be a professional risk with some computer folks. This "splitting the channel to throw away one copy" somehow kept tickling me (although the folks at Combinatory Logic [2] don't seem to have problems with that kind of wastefulness). Well, that's where dd rescued me: sudo dd of=/etc/hosts oflags=append (note that if=- is the default). Season to taste :-) From the "semi-useful ramblings". Perhaps it amuses someone, then it was downright useful. FWIW [2], I still use `dd' where I could use `cp' or `cat'. Sometimes it does align better with my hands. But I agree that it's better left out when not needed, as is `cat'. Now to another pet peeve of mine: useless use of grep: grep | sed -e 's/bla/foo/' ... Cheers [1] Obsessive Compulsive Disorder [2] https://en.wikipedia.org/wiki/Combinatory_logic#Examples_of_combinators -- t signature.asc Description: Digital signature
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 01/07/21 à 20:30, Étienne Mollier a écrit : > Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être > que mon idée n'aura pas beaucoup de sens, mais est-ce que slack > propose de désactiver l'accélération graphique ? Peut-être que > désactiver ce paramètre aiderait à la stabilité de la machine ? Effectivement, cette case existe et était cochée, mais je ne me souviens pas exactement quand je l'ai fait, c'est pas très vieux. Mais l'accélération matérielle de slack pourrait planter le module i915 alors qu'il n'y a pas de fenêtre de l'appli ouverte ? (la plupart du temps il tourne en arrière plan, en tout cas dans la très grande majorité de mes plantages il n'y avait pas de fenêtre slack, même réduite, juste l'icone de slack dans la zone dont j'ai oublié le nom, à coté de l'heure/son/wifi/…) > J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le > site de slack.com Pfff, même ça je l'avais pas trouvé, j'avais installé via snapd n'ayant pas trouvé ce deb. J'ai désinstallé slack via snapd, désinstallé snapd (j'aime pas trop avoir un truc qui tourne dans le dos d'apt pour faire son boulot) et installé ce .deb. > et j'ai vu que le programme embarquait un > chrome-sandbox setuid, combiné à des bibliothèques OpenGL et > Vulkan tierces. D'où l'idée que, si ce programme exécute des > bibliothèques graphiques buguées en tant que root, alors > peut-être que ça expliquerait les crashes avec le pilote i915. Merci pour cette excellente piste ! Je le laisse tourner avec l'accélération matérielle désactivée, on verra… -- Daniel Il est très curieux de constater que dans l'armée, les statistiques le prouvent, la mortalité augmente bizarrement en temps de guerre. Alphonse Allais pgpUIlWwMeI23.pgp Description: Signature digitale OpenPGP
Re: How to verify newly burned disc
Hi, On Tue, 29 Jun 2021 12:08:13 +0200 "Thomas Schmitt" wrote: (...) > > > For data-discs I finally found a recipe that seems to > > work in the archives of debianforum.de : > > $ wc -c whatever.iso > > 8237400064 whatever.iso > > $ dd if=/dev/sr0 | head -c 8237400064 | md5sum > > Yes. See also the FAQ about Debian ISO images: > https://www.debian.org/CD/faq/#verify > > The trick is to curb the reader to the size of the ISO image for which > you know the checksum. > The ISO images themselves contain a data field with their filesystem > size. This may or may not be the size of the ISO image file. > So it is better to record both, image size and checksum for the purpose > of later verification. thanks for the detailed explanation. I managed to wrap these commands in a little script, so now I can do this with a single command, I think this wil do the trick for my purpose. > > Unfortunately there is apparently no way to control the reading > > speed here, so maybe one should be careful with these Pioneer > > drives :) > > You would need a filter program which takes care not to read more than > ~ 20 MB/s. Then the drive slows down automatically. > > (It is not decided who is at fault with the BD-RE cracks: Pioneer or > Verbatim or both ...) I see, that does not sound trivial, at least to me :) Fortunately there seems to be no danger with the Asus drive here, it does not sound like it is spinning unreasonably fast when when using dd, so I think it should be save just to skip this step. > > So, does anyone know about a way to verify the integrity of burned > > audio-CDs? > > Success is normally judged by playing the CD on the intended player > device, which in most cases is not the CD burner. > > > Difficulties are to be expected if you want to verify the burn success > by audio data comparison: > (...) Ok, I thought so. Checking success by listening to the CD playing on my stereo will be good enough, I guess. And I`ll just assume that if data discs are ok the same will be true for audio-CDs. So far the Asus managed to pass all tests, so probably I should just be grateful to all the transcendental authorities that guided my hand when I picked that carton from the shelf :) Thanks again for your patience, and have a nice day :-) Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. Compassion -- that's the one things no machine ever had. Maybe it's the one thing that keeps men ahead of them. -- McCoy, "The Ultimate Computer", stardate 4731.3
Re: Debian Linux keyboard mapping files ...
David Chartash at the corpora research mailing list pointed out to me I could find what I wanted at: http://kbdlayout.info/ and within Debian using `man 5 keyboard` > There's no such table: it cannot exist. Which unicode number would you > assign to CapsLock, or RightShift. There are several layers of > translation which lie between pressing/releasing a key and assigning > a character to the result. Some of these tables are built up out of > component parts, like the basic letter keys, the "shift"s at their > edges, function keys, keypads, multimedia, etc. > For a start, mapping key depressions to unicode text is a many-to-one > mapping. Well, when I said "look up table" I meant also such sequences of chars including escape sequences which end up being written as a character in text files. Non-alphabetical languages use input methods. > ¹ AltGr o yields ø, fair enough, > but > CapsLock /o yields ø > CapsLock 'o yields ó > CapsLock `o yields ò > CapsLock ^o yields ô > CapsLock ~o yields õ > CapsLock -o yields ō > CapsLock "o yields ö > CapsLock !o yields ọ > CapsLock .o yields ȯ > CapsLock #o yields º > CapsLock oo yields ° > and there's really no limit, so long as I can recall them: > CapsLock co yields © > CapsLock ro yields ® > CapsLock so yields § > CapsLock %o yields ‰ > and you don't need an AltGr key, and you can configure it > to seamlessly work on both VC and in X. From your examples you included I will only need yielded glyphs if they are commonly used in a language. Now, defining "commonly used" would be an entirely different, yet valid question. I will have to code my way through those files to parse unicode <-> key (or key sequence) "lookup tables" for each language and my effort will need definitely more than "parsing" for non-alphabetical languages. thank you, lbrtchx
