Re: net.ipv6.conf.intf.disable_ipv6 behavior changes
Am 03.09.22 um 06:32 schrieb Casey Deccio: >> On Sep 2, 2022, at 8:14 PM, Kevin Price wrote >> We got him. :) Casey, you file the bug report, Okay? > Done! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018999 > Thanks for all the help! You are very welcome. Thanks a lot for this conversation, which felt very pleasant to me, and kind, productive, and helpful, even though especially my initial reply was quite tight-lipped. Thanks to our well-working cooperation. We've successfully and quite quickly pinpointed the cause of a real-world problem that likely affects many others. ^5 IMHO, this is a good example of how I wish the Debian/FLOSS community to always be. Or any good community, for that matter. If I may: Very well done, Casey. *shoulder tap* What caught my initial attention was the possibility of the kernel broadly changing its behavior within a stable release, which in itself would pose a huge problem, which to prevent is the very purpose of stable. Glad that turned out to be false. Your appreciativeness encouraged me to follow up on this, which rewarded me with quite some fun in helping to solve this little puzzle with you, and with the bonus of a few decoys in our way. ;D Out of curiosity I've subscribed to your bug #1018999. Very well written. Its outcome we'll see. As to if, when, and how it might get fixed, I'm not all that optimistic, so you might want to stick with any workarounds for a while. (maybe a tailored deb package that _Conflicts_: connman and _Recommends_: network-manager, or else maybe a kernel boot command line parameter "ipv6.disable=1", which completely overrides sysctl, or whatever may suit your needs) Although connman is actively being maintained upstream and in Debian right now, it's far from granted this bug will be acknowledged as such at all, either in Debian or upstream. Otherwise it might be dismissed as connman's "expected behavior". Although I'm not in favor of that in this case, I do understand the argument that a program designed for the sole purpose of managing network interfaces, actually manages network interfaces. Maybe not in the way we'd like. Maybe it could manage them to more satisfaction by asking permission before overriding the user's preference to disable_ipv6, which it doesn't. Thus #1018999. In case your bug gets acknowledged, (which is a huge if) I'd expect any resolution to appear in stable no sooner than in Bookworm, whenever that may be released. (...very purpose of stable...) Also, in case bug #1018999 is not going to be fully resolved to your needs, we might consider filing a wishlist "bug report" against lxde to at least change their recommendation into something less troublesome, such as network-manager maybe. Which does not interfere with the user's preferences in the same way. Oh BTW, I ought to file another bug report against connman (if not already pending) for not being able to be installed via ssh in a DHCP environment. (because during postinst it reconfigures the network interfaces, failing to use the proper FQDN in DHCP requests, thus getting a new IP address assigned and cutting off the ssh session) Not quite certain, but I guess this violates some existing Debian policy, or else a new Debian policy to come into place rather soon. (bug report against debian-policy) Thank you Casey for being part of the Debian community. Your participation makes Debian a better place to be, so please keep it up! -- Kevin
Re: Fwd: Recuperar el espacio de lo ilegible.
El 3/9/22 a las 18:04, Aristobulo Pinzon escribió: El sáb, 3 sept 2022 a las 15:33, Aristobulo Pinzon () escribió: El 2022-09-01 a las 16:21 -0500, Aristobulo Pinzon escribió: Hola gente inteli... Me estoy quedando sin espacio en la partición raíz y me aparece esto: Tamaño: 278107 elementos, en total 8,6 GiB (9.204.394.052 bytes) (parte del contenido es ilegible) 18,0 MiB libres de 9,4 GiB (99% en uso) Cómo recupero el espacio de lo ilegible? El mensaje debe ser del gestor de archivos Nemo, que ejecutado como usuario no tiene acceso a ciertos archivos, de ahí el mensaje críptico. Muchas gracias … Si es algo parecido, es un mensaje de thunar. El cuando al espacio recuerda que el sistema de archivos ext3/4 se reserva el 5% del tamaño de la partición para sus cositas (5% de 9,5 GiB son unos 470 MiB). Ahh eso no lo había previsto… Busca archivos gordos (en mi chuleta tengo esta orden: «du -BM | sort -nr | less») y mira a ver si los puedes eliminar (por ser de caché, paquetes deb que ya hayas instalado, registros que no necesites, etc...). Ja!… Me mostró una lista terrible y difícil de manejar. Sin envargo encontré que hay tres kerneles con sus respectivos vmlinuz: /boot/initrd.img-5.10.0-9-amd64 /boot/initrd.img-5.10.0-13-amd64 /boot/initrd.img-5.17.0-trunk-amd64 /boot/config-5.10.0-9-amd64 /boot/config-5.10.0-13-amd64 /boot/config-5.17.0-trunk-amd64 /boot/System.map-5.10.0-9-amd64 /boot/System.map-5.10.0-13-amd64 /boot/System.map-5.17.0-trunk-amd64 /boot/vmlinuz-5.10.0-9-amd64 /boot/vmlinuz-5.10.0-13-amd64 /boot/vmlinuz-5.17.0-trunk-amd64 de los cuales está en uso el /boot/initrd.img-5.17.0-trunk-amd64 y su respectivo /boot/vmlinuz-5.17.0-trunk-amd64 y funciona muy bien. ¿ Puedo eliminar los otros sin ningún problema? Sí, y elimina todo lo relacionado a esos kernels. Quédate con uno, el que esté en uso. apt purge *5.10.0-9* Saludos, Saludos también a todos y muchas gracias... Saludos JAP
Re: Re: Fwd: Recuperar el espacio de lo ilegible.
El sáb, 3 sept 2022 a las 15:33, Aristobulo Pinzon () escribió: > > El 2022-09-01 a las 16:21 -0500, Aristobulo Pinzon escribió: > > > Hola gente inteli... > > > > Me estoy quedando sin espacio en la partición raíz y me aparece esto: > > > > Tamaño: > > > > 278107 elementos, en total 8,6 GiB (9.204.394.052 bytes) > > > > (parte del contenido es ilegible) > > > > 18,0 MiB libres de 9,4 GiB (99% en uso) > > > > Cómo recupero el espacio de lo ilegible? > > El mensaje debe ser del gestor de archivos Nemo, que ejecutado como > usuario no tiene acceso a ciertos archivos, de ahí el mensaje críptico. > Muchas gracias … Si es algo parecido, es un mensaje de thunar. > El cuando al espacio recuerda que el sistema de archivos ext3/4 se > reserva el 5% del tamaño de la partición para sus cositas (5% de 9,5 GiB > son unos 470 MiB). > Ahh eso no lo había previsto… > Busca archivos gordos (en mi chuleta tengo esta orden: «du -BM | sort -nr | > less») y mira a ver si los puedes eliminar (por ser de caché, paquetes > deb que ya hayas instalado, registros que no necesites, etc...). > Ja!… Me mostró una lista terrible y difícil de manejar. Sin envargo encontré que hay tres kerneles con sus respectivos vmlinuz: /boot/initrd.img-5.10.0-9-amd64 /boot/initrd.img-5.10.0-13-amd64 /boot/initrd.img-5.17.0-trunk-amd64 /boot/config-5.10.0-9-amd64 /boot/config-5.10.0-13-amd64 /boot/config-5.17.0-trunk-amd64 /boot/System.map-5.10.0-9-amd64 /boot/System.map-5.10.0-13-amd64 /boot/System.map-5.17.0-trunk-amd64 /boot/vmlinuz-5.10.0-9-amd64 /boot/vmlinuz-5.10.0-13-amd64 /boot/vmlinuz-5.17.0-trunk-amd64 de los cuales está en uso el /boot/initrd.img-5.17.0-trunk-amd64 y su respectivo /boot/vmlinuz-5.17.0-trunk-amd64 y funciona muy bien. ¿ Puedo eliminar los otros sin ningún problema? > Saludos, Saludos también a todos y muchas gracias... -- La Razón en su sentido absoluto no es algo que esté en el cielo esperando a ser descubierto, sino que está mezclada con la sinrazón, con lo irrelevante y lo cotidiano.
Re: Seeing progross during fsck on boot
On Sat 03 Sep 2022 at 11:31:27 (-0400), Greg Wooledge wrote: > On Sat, Sep 03, 2022 at 10:06:56AM -0500, David Wright wrote: > > When I booted my system this morning, I naturally selected the FSCK > > option in Grub, and sure enough, I saw a progress bar as the root > > filesystem was checked. Nothing for the others, though. (I use > > systemd. I'm sure it's trivial to edit sysvinit scripts to add -C > > and make sequential if either is not the default.) > > That's great information. It sounds like the fsck of the root file system > is handled inside the initramfs, and that the scripts/whatever which do > it are already passing the -C option. In view of Sven's post, I should point out my boot line was: linux /boot/vmlinuz-5.10.0-17-amd64 root=LABEL=toto05 ro systemd.show_status=true quiet forcefsck I also wrote: > > The root filesystem should never be checked at the same time as > > others. but I did notice that my /etc/fstab contains: LABEL=toto05 / ext4 errors=remount-ro 0 1 UUID=C027-B627 /boot/efi vfat umask=0077 0 1 /dev/mapper/swap none swap nofail LABEL=toto06 /home ext4 errors=remount-ro,nofail,noauto,user,exec,suid 0 2 LABEL=toto04 /axisbus ext4 errors=remount-ro,nofail 0 2 which has two filesystems marked 1 in field six. AFAIK that is the default. > So all that remains is to find a way to pass that option for the *other* > file systems, which are presumably done outside of the initramfs. > Unfortunately, that's where I hit a wall. It doesn't look like systemd > provides a friendly way to add that option. (I'll be happy to be proven > wrong.) So I changed the sixth fields above from 1 1 2 2 to 1 0 0 2, rebuilt the initfamfs just in case (though fstab is empty there), then rebooted with forcefsck again. I was worried about the fact that I get a 2–3 second blank during boot up, but no fear, when the login prompt appeared, toto04 was still being checked. The appearance is quite different: [ OK ] Started Disk Manager. (42.9% complete) Checking in progress on 1 disk (43.2% complete) Debian GNU/Linux 11 (bullseye) axis 192.168.1.14 … … Checking in progress on 0 disks (100.0% complete) _ Those are the final texts: the numbers were obviously increasing while being displayed, but no visual progress bar. I didn't see anything like that earlier today, nor after I had restored the fstab to normality (forcefsck each time). But I should point out that toto06 has a LUKS-encrypted filesystem on it, which can only be decrypted after I login as user unlock and type the passphrase. Cheers, David.
Re: failing HDD, ddrescue says remaning time is 7104d
On 9/3/22 08:46, ppr wrote: Le 01/09/2022 à 00:24, David Wright a écrit : -R --reverse will start an attempt from the end of the disk, and if you're extremely lucky, it might copy most of the remaining 960-odd GB of data. OTOH it might only confirm that the disk is closer to meeting its maker than it was when you started the rescue. Thank you all for yours anwsers. Following the suggestion of Cindy I rebooted the computer to see if session's reboot freshness affects transfer. It did not in my case. Transfert rate is very slow but ddrescue make some progress. After 5 days and one interruption (for rebooting), here is the current status: --- # ddrescue -n /dev/sdb /media/sara/2274a2da-1f02-4afd-a5c5-e8dcb1c02195/recup_HDD_sara/image_HDD1.img /media/sara/2274a2da-1f02-4afd-a5c5-e8dcb1c02195/recup_HDD_sara/recup.log GNU ddrescue 1.23 Press Ctrl-C to interrupt Initial status (read from mapfile) rescued: 33992 MB, tried: 0 B, bad-sector: 0 B, bad areas: 0 Current status ipos: 72645 MB, non-trimmed: 26050 kB, current rate: 1638 B/s opos: 72645 MB, non-scraped: 0 B, average rate: 55829 B/s non-tried: 951012 MB, bad-sector: 0 B, error rate: 0 B/s rescued: 49165 MB, bad areas: 0, run time: 3d 3h 29m pct rescued: 4.91%, read errors: 490, remaining time: 5382d 14h time since last successful read: 0s Copying non-tried blocks... Pass 1 (forwards) --- I am considering using -R option (as suggested by David Wright) to see if ddrescue can have better transfert rate starting from the other side of the HDD. My concern is whether or not ddrescue can resume a job started, stopped, and relaunched with -R option added. ddrescue's manual says only: --reverse Reverse the direction of all passes (copying, trimming, scraping, and retrying). Every pass that is normally run forwards will now be run backwards, and vice versa. '--reverse' does not modify the size of the blocks copied during each phase, just the order in which they are tried. If I stop ddrescue and add -R option, would the mapfile be able to handle this (ddrescue started from the beginning and the end the the drive)? I also add some information related to other answers: - The destination HDD is an external USB3 one. It is a physical RAID 1 with two 8To HDD 7200rpm. The commercial name is Lacie 2big raid. The fact is image is growing and the speed seems to vary (even if never fast) lets me think it is perhaps the HDD condition which is the cause of the slow transfer rate. - I commented out the failing HDD in /etc/fstab and disable smartmontools tests for this drive. I did not try to mount the HDD. Cheers. ppr I assume you are not seeing any problems with the destination drive (via dmesg(1), /var/log/messages, etc.)? Interpreting the ddrescue(1) output: https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Invoking-ddrescue At 7200 RPM, ddrescue(1) should be reading 120 blocks per second. At 512 bytes per block, that is 61,440 bytes per second. I interpret the "current rate: 1638 B/s" and "error rate: 0 B/s" statistics to mean that the drive read 3 blocks and returned 0 errors in the second prior to the displayed output. So, the drive took an average of 40 internal reads for each of those 3 blocks returned to ddrescue(1) (via the kernel). While it is good that the drive is returning data, reading each block 40 times scares me. You want ddrescue to read and return the good blocks once each, and then fight the bad blocks. Looking at the command line options: https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Invoking-ddrescue I would interrupt (Ctrl+C) the current run and re-invoke ddrescue(1) with the following options: -a 30720 -d -R -T 10 I would not use "-K" option. I expect the GNU project carefully tuned the initial and maximum skip size parameters. But, I do not know for what size disk(s); yours is 1 TB. I would STFW for specific advice before adjusting those parameters. I would not use the "-n" option. The scrape phase is part of the design of ddrescue; I would keep it. The timeout option "-T 10" might stop ddrescue if it gets stuck when you are not paying attention. If this happens, you can rethink the options when restarting. "--delay-slow=3", "--pause-on-error=3", and "--reset-slow=3" might be useful for tuning "-a". The "-i" option might be useful when restarting ddrescue. Leave it off the first time you try "-R". I sometimes watch disk I/O with nmon(1). But, the direct access "-d" option might prevent nmon(1) from seeing disk I/O. The verbose "-v" might be worth a try. David
Re: Seeing progross during fsck on boot
On 2022-09-01 22:51 +0100, Mike wrote: > A long time, maybe 11 years ago, I built a NAS box based around comodity > hardware and the Debian of the day. It's currently been through several > apt-get dist-upgrades and currently running Debian 11 with loads of old > config grandfathered into it. > > It's a server, so runs 24x7 but every few months or so falls on its > arse. Periodically it wants to fsck the disks, either because they've > gone 20 mounts or so without a fsck or more often because they've gone > however many days it is without a fsck. > > This I can live with. I can even live with the fact that with several > TB file systems and quite a few files, the processs takes around fuor > hours. I'd just be nice to have some progress reported. While it > managed to spit details of any file system errors that have been found > and corrected, other than that it sits there utterly silent. For hours. > I can see that it's doing something as 1) it's expected behaviour and 2) > I can see the disk light solid on. Nevertheless, it would be nice to > see the progress bar indicting how it was getting along. > > Does aoyone have any idea how to enable this? I have no idea where to > look. I've had several attempts at finding the answer with a well-known > Internet search engine but while I've found many similar questions and > even sometimes the same one as I'm asking but so far an answer has > proved illusive. > > Does anyone have any suggestions for a solution or indeed where one may > look for one? You probably want "ShowStatus=auto" in the [Manager] section of /etc/systemd/system.conf, or boot with the "systemd.show_status=auto" option. See the systemd manpage: , | KERNEL COMMAND LINE | [...] |systemd.show_status |Takes a boolean argument or the constants error and auto. Can |be also specified without an argument, with the same effect as |a positive boolean. If enabled, the systemd manager (PID 1) |shows terse service status updates on the console during |bootup. With error, only messages about failures are shown, |but boot is otherwise quiet. auto behaves like false until |there is a significant delay in boot. Defaults to enabled, |unless quiet is passed as kernel command line option, in which |case it defaults to error. If specified overrides the system |manager configuration file option ShowStatus=, see systemd- |system.conf(5). ` Cheers, Sven
Re: Seeing progross during fsck on boot
On 9/3/2022 4:18 PM, Charles Curley wrote: On Sat, 3 Sep 2022 22:57:19 +1000 David wrote: Nice write-up, especially the last part. One nit-pick I imagine that could be overcome by copying the above service file to /etc/lib/systemd/system/systemd-fsck-root.service and editing the above ExecStart line to use /sbin/fsck instead. I believe on Debian that should be /etc/systemd/system/systemd-fsck-root.service There is a systemd command for editing systemd files which will if necessary do that copy transparently for you. I forget right now what that is. I guess the CMD [1] in question is: $ systemctl edit [ <--full> ] [1] https://www.freedesktop.org/software/systemd/man/systemctl.html# -- John Doe
Re: KVM sur un CPU intel sans vmx
Merci pour votre réponse, vous faite bien de soulever le problème des 32 bits, parce que mon but serait d'apprendre à me servir d'une distro style https://www.proxmox.com Y a pas en 32 bits raison pour laquelle j'envisagais de le faire en mode DIY partir de KVM sur une Debian 32 bits. Mais ca va exploser la raideur de ma courbe d'apprentissage et ça risque de me décourager. Je crois que vais plutôt essayer de trouver un vieil ordi de récup avec un CPU 64 bits qui a la virtualisation. ;-) C'est tellement facile à trouver gratos avec tous ceux qui s'en débarrassent parce qu'il rame sous WIn... Envoyé avec la messagerie sécurisée [Proton Mail](https://proton.me/). --- Original Message --- Le samedi 3 septembre 2022 à 16:49, NoSpam a écrit : > Bonjour > > Le 03/09/2022 à 16:36, benoit a écrit : > >> Bonjour, >> >> Je voudrais apprendre à virtualiser (hyperviseurs de type 1 ) un Linux avec >> KVM, me fout des perfs c'est juste pour apprendre. >> >> La machine de test est un atom N270 sans vmx, ça ne marchera pas du tout ou >> ça sera juste moins performant sans la virtualisation matérielle ? > > Cela fonctionnera mais il faudra être TRES patient et utiliser du 32 bits > suivant la date de fabrication du processeur > > -- > Daniel
Re: failing HDD, ddrescue says remaning time is 7104d
Le 01/09/2022 à 00:24, David Wright a écrit : -R --reverse will start an attempt from the end of the disk, and if you're extremely lucky, it might copy most of the remaining 960-odd GB of data. OTOH it might only confirm that the disk is closer to meeting its maker than it was when you started the rescue. Thank you all for yours anwsers. Following the suggestion of Cindy I rebooted the computer to see if session's reboot freshness affects transfer. It did not in my case. Transfert rate is very slow but ddrescue make some progress. After 5 days and one interruption (for rebooting), here is the current status: --- # ddrescue -n /dev/sdb /media/sara/2274a2da-1f02-4afd-a5c5-e8dcb1c02195/recup_HDD_sara/image_HDD1.img /media/sara/2274a2da-1f02-4afd-a5c5-e8dcb1c02195/recup_HDD_sara/recup.log GNU ddrescue 1.23 Press Ctrl-C to interrupt Initial status (read from mapfile) rescued: 33992 MB, tried: 0 B, bad-sector: 0 B, bad areas: 0 Current status ipos: 72645 MB, non-trimmed: 26050 kB, current rate:1638 B/s opos: 72645 MB, non-scraped:0 B, average rate: 55829 B/s non-tried: 951012 MB, bad-sector:0 B,error rate: 0 B/s rescued: 49165 MB, bad areas:0,run time: 3d 3h 29m pct rescued:4.91%, read errors: 490, remaining time: 5382d 14h time since last successful read: 0s Copying non-tried blocks... Pass 1 (forwards) --- I am considering using -R option (as suggested by David Wright) to see if ddrescue can have better transfert rate starting from the other side of the HDD. My concern is whether or not ddrescue can resume a job started, stopped, and relaunched with -R option added. ddrescue's manual says only: --reverse Reverse the direction of all passes (copying, trimming, scraping, and retrying). Every pass that is normally run forwards will now be run backwards, and vice versa. '--reverse' does not modify the size of the blocks copied during each phase, just the order in which they are tried. If I stop ddrescue and add -R option, would the mapfile be able to handle this (ddrescue started from the beginning and the end the the drive)? I also add some information related to other answers: - The destination HDD is an external USB3 one. It is a physical RAID 1 with two 8To HDD 7200rpm. The commercial name is Lacie 2big raid. The fact is image is growing and the speed seems to vary (even if never fast) lets me think it is perhaps the HDD condition which is the cause of the slow transfer rate. - I commented out the failing HDD in /etc/fstab and disable smartmontools tests for this drive. I did not try to mount the HDD. Cheers. ppr
Re: Seeing progross during fsck on boot
On Sat, Sep 03, 2022 at 10:06:56AM -0500, David Wright wrote: > When I booted my system this morning, I naturally selected the FSCK > option in Grub, and sure enough, I saw a progress bar as the root > filesystem was checked. Nothing for the others, though. (I use > systemd. I'm sure it's trivial to edit sysvinit scripts to add -C > and make sequential if either is not the default.) That's great information. It sounds like the fsck of the root file system is handled inside the initramfs, and that the scripts/whatever which do it are already passing the -C option. So all that remains is to find a way to pass that option for the *other* file systems, which are presumably done outside of the initramfs. Unfortunately, that's where I hit a wall. It doesn't look like systemd provides a friendly way to add that option. (I'll be happy to be proven wrong.)
Re: Seeing progross during fsck on boot
On Sat 03 Sep 2022 at 08:18:18 (-0600), Charles Curley wrote: > On Sat, 3 Sep 2022 22:57:19 +1000 > David wrote: > > Nice write-up, especially the last part. > > One nit-pick > > > > I imagine that could be overcome by copying the above service file to > > /etc/lib/systemd/system/systemd-fsck-root.service and editing the > > above ExecStart line to use /sbin/fsck instead. > > I believe on Debian that should be > /etc/systemd/system/systemd-fsck-root.service > > There is a systemd command for editing systemd files which will if > necessary do that copy transparently for you. I forget right now what > that is. systemctl edit Controlled by SYSTEMD_EDITOR, subject to the vagaries of su/sudo. Cheers, David.
Re: Seeing progross during fsck on boot
On Sat 03 Sep 2022 at 08:03:38 (-0400), Greg Wooledge wrote: > On Sat, Sep 03, 2022 at 09:56:34AM +0100, Mike wrote: > > Rereading my original request, I think perhaps I wasn't entirely clear > > on a couple of points: > > I thought it was clear. Some of the responses completely baffled me. > One person even mentioned xterm -- like, *what*? How does xterm come > into play when you're booting a server and there's no GUI yet? TL;DR sorry to shock your sensibilities by the mention of xterm. -- It doesn't. If you read what I wrote, you will see that I mentioned xterm as a disclaimer that /I/ don't know anything about the arguments to -C because /I/ was using xterm. In case you missed it, my post was to point out that fsck can still, with appropriate filesystems, spit out a progress bar of equals signs. There was no indication then of which filesystems were in use until the OP's second post, nor of their disposition, nor which init system is being used. With sysvinit, I think it could be trivial to check the disks sequentially, /if/ there were several disks /and/ the increase in time taken were less important than the confidence gained in seeing signs of life. I don't have the time or confidence to delve into bowels of systemd and initrds like David. > > Maybe I'm being nostalgic but I seem to recall in days gone by that fsck > > printed a progress bar out of hashes to show how it was getting along. And that was written long after my post. > Near as I can tell, that was a feature of the old sysv-rc scripts, > which ran (originally/mostly) in series, instead of in parallel. The > fsck progress bar(s) seem to have been lost in the move to systemd, > perhaps because writing a progress bar isn't considered viable in a > highly parallel boot system where other things might also be trying to > write to the console. Or perhaps for other reasons. The root filesystem should never be checked at the same time as others. As it's pointed out somewhere or other, you don't know whether fsck is intact and competent to check other filesystems until it's been checked itself. When I booted my system this morning, I naturally selected the FSCK option in Grub, and sure enough, I saw a progress bar as the root filesystem was checked. Nothing for the others, though. (I use systemd. I'm sure it's trivial to edit sysvinit scripts to add -C and make sequential if either is not the default.) As for why -C bothered me, I think I'm dredging up some wrinkle I encountered when I wanted a cron job to print a little table to the screen 30 secnds after booting. I remember having to open a tty specifically, because stdout didn't seem to appear on the screen. (I guess it would just try to email it instead.) I also ?know that some people don't see all the booting messages on the screen because they have some sort of ?splash screen (is that what plymouth is all about?). So I don't know if -C is meant to cope with possibilities like that, or when fscking non-root disks is still occurring while a graphical login screen is displayed. Cheers, David.
Re: Seeing progross during fsck on boot
On Sun, 4 Sept 2022 at 00:18, Charles Curley wrote: > On Sat, 3 Sep 2022 22:57:19 +1000 David wrote: > > I imagine that could be overcome by copying the above service file to > > /etc/lib/systemd/system/systemd-fsck-root.service and editing the > > above ExecStart line to use /sbin/fsck instead. > > I believe on Debian that should be > /etc/systemd/system/systemd-fsck-root.service Hi Charles, yes thanks for picking up that edit mistake, it was supposed to be a simple change (lib --> etc) but I neglected to delete the 'lib'. Also I noticed another error in my transcription of the console message, I missed the hyphen in the package name, it should be: Begin: Will now check root file system ... fsck from util-linux 2.36.1
Re: KVM sur un CPU intel sans vmx
Bonjour Le 03/09/2022 à 16:36, benoit a écrit : Bonjour, Je voudrais apprendre à virtualiser (hyperviseurs de type 1 ) un Linux avec KVM, me fout des perfs c'est juste pour apprendre. La machine de test est un atom N270 sans vmx, ça ne marchera pas du tout ou ça sera juste moins performant sans la virtualisation matérielle ? Cela fonctionnera mais il faudra être TRES patient et utiliser du 32 bits suivant la date de fabrication du processeur -- Daniel
KVM sur un CPU intel sans vmx
Bonjour, Je voudrais apprendre à virtualiser (hyperviseurs de type 1 ) un Linux avec KVM, me fout des perfs c'est juste pour apprendre. La machine de test est un atom N270 sans vmx, ça ne marchera pas du tout ou ça sera juste moins performant sans la virtualisation matérielle ? Merci Envoyé avec la messagerie sécurisée [Proton Mail](https://proton.me/).
Re: Seeing progross during fsck on boot
On Sat, 3 Sep 2022 22:57:19 +1000 David wrote: Nice write-up, especially the last part. One nit-pick > I imagine that could be overcome by copying the above service file to > /etc/lib/systemd/system/systemd-fsck-root.service and editing the > above ExecStart line to use /sbin/fsck instead. I believe on Debian that should be /etc/systemd/system/systemd-fsck-root.service There is a systemd command for editing systemd files which will if necessary do that copy transparently for you. I forget right now what that is. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Seeing progross during fsck on boot
On Sat, 3 Sept 2022 at 18:57, Mike wrote: > Thanks for the replies. > > Rereading my original request, I think perhaps I wasn't entirely clear > on a couple of points: [...] Hi again. Those points seemed clear to me. > Maybe I'm being nostalgic but I seem to recall in days gone by that fsck > printed a progress bar out of hashes to show how it was getting along. [...] > TL;DR: When my server boots up and decdies to spent four hours fscking > the disks, I'd just like to see some indiction that it's still alive and > doing something :-) But what is now unclear is that your latest message does not give any indication if the replies that you already received have satisfied your request for help, or not. So I took another look at your request. I'm now able to provide more information than last time. Which I am writing up because learned a few things, so I thought I would share that with the list, so that we can help each other figure things out. There are four parts to this message: 1) Before systemd 2) Now with systemd 3) But what about initrd 4) Final part The final part is the only part that's actually useful, probably :) Part 1) Before systemd -- In the manpage 'man 5 fstab' read about the "sixth field". In the manpage 'man 8 fsck' read about the '-A' option. In the manpage 'man 8 fsck' read about the '-C' option. In the manpage 'man 8 e2fsck' read about the '-C' option. All of the above explains how fsck will work when /sbin/fsck or /usr/sbin/fsck is in use. Before systemd, that external binary was run by the init system during the boot process, and there would have been some script somewhere that a sysadmin could change its arguments. So the above information might have been of use in that situation. The manpage 'man 8 fsck' documents several environment variables that I had not noticed before, so just out of curiousity I went looking for how they might be used and I discovered the following. Part 2) Now with systemd /etc/fstab still works as described above. However there is documentation out there that suggests that the work of fsck has now been taken over by systemd-fsck, which is documented by 'man 8 systemd-fsck.service' and its friends. The /usr/lib/systemd/system/systemd-fsck-root.service file contains the line: ExecStart=/lib/systemd/systemd-fsck I looked at the source code for that file here: https://github.com/systemd/systemd/blob/main/src/fsck/fsck.c which is interesting because it says: "This program expects one or no arguments." revealing that there is no way for the system administrator to provide arguments or environment variables to the boot-time fsck process. The source code shows that systemd-fsck generates these arguments internally before it passes them to /sbin/fsck. I imagine that could be overcome by copying the above service file to /etc/lib/systemd/system/systemd-fsck-root.service and editing the above ExecStart line to use /sbin/fsck instead. I did try running /lib/systemd/systemd-fsck manually, but I don't have any large drives here that are unencrypted, so every filesystem that I have available to test just completed too quickly to show any progress bar. (More about that in part 4 ... ) Part 3) But what about initrd - When I looked at the Archlinux wiki at https://wiki.archlinux.org/title/Fsck it describes a different mechanism where fsck is done by the initrd. The Debian machinery is different, but this idea made me think that maybe this has nothing to do with systemd. So, I did boot a test machine (Debian 11) with "break=bottom" and had a dumb poke around the initrd, and I found this (transcribed by hand, blanks omitted): -begin- (initramfs) cat /run/initramfs/fsck.log Log of fsck -C -a -T -t ext4 /dev/sda2 Sat Sep 3 10:53:44 2022 SATPRO_X: clean, 34049/794624 files, 445226/3173376 blocks Sat Sep 3 10:53:44 2022 -end- And I also noticed that the console messages say (transcribed by hand): -begin- Begin: Will now check root file system ... fsck from util linux 2.36.1 [/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2 SATPRO_X: clean, 34049/794624 files, 445226/3173376 blocks done. -end- And after more poking around, I'm guessing that fsck is called from /usr/share/initramfs-tools/scripts function _checkfs_once() with '-C' (in the fsck.log above) and that fsck.ext4 reports (in the console message above) that it takes that to mean '-C0'. So, it is currently my naive understanding that all of this is happening in the initrd, before systemd starts. Which would mean that Part 2 of this message is completely irrelevant. Someone please do correct me if that is wrong. Part 4) Final part -- > Someone asked about the file systems in use. Some are ext3 and some are > ext4. In case you are not aware, fsck on ext4 uses a completely different algorithm that is orders of magnitude faster than ext3. So if
Re: Seeing progross during fsck on boot
On 9/3/22 04:56, Mike wrote: On Fri, Sep 02, 2022 at 12:31:35AM +0200, DdB wrote: Just thinking about your request ... Imagine this: You run "fsck -N ..." and get a rough estimate about the time necessary to get the I/O and the job done, then it would be easy to set up some timed countdown in parallel with the real fsck job, just for you to have an idea about the time left. Alternatively, copy the whole device to another place, peform the fsck there and decide, if copying back the result would be faster of just running fsck on the original device. What i am intending to make you think about: Sometimes it is way more difficult and time consuming to get a rough estimate of some result, than to actually just get it for real. (You may talk to some math PHD about that.) ... not worth the effort, because even you would prefer to get the result as fast as possible and not wait twice the time just to know ahead of time, when the job is likely to finish. Does that make sense to you too? Hi, Thanks for the replies. Rereading my original request, I think perhaps I wasn't entirely clear on a couple of points: 1) When there server starts, the default behaviour is to fsck the disks if they have been longer than 120 days (or something like that) without a fsck. It's a server and runs 24x7, so you can bet your bottom dollar that if if it does reboot, it will need to fsck. You can also bet that it was an uncontrolled shutdown because the UPS caught fire or something, so it's probably wise to run fsck. I haev no issue with this happening 2) I'm not too worried about how long it's actually going to take. The main issue is that I've had a couple of instances where the box has rebooted, I've sat around waiting for it to reboot, wondered why it hasn't, plugged a monitor in and seen jack on the screen, then just as I panic about what major issue could be wrong with it and key CTRL+ALT+DEL to see if I missed anything... I see the disk lights are solid on and assume it must be running fsck. Sometimes it does find some erros and spits that out to the screen. Otherwise it just sits there like a dog that's been shown a card trick. Maybe I'm being nostalgic but I seem to recall in days gone by that fsck printed a progress bar out of hashes to show how it was getting along. Someone asked about the file systems in use. Some are ext3 and some are ext4. TL;DR: When my server boots up and decdies to spent four hours fscking the disks, I'd just like to see some indiction that it's still alive and doing something :-) Regards, Mike. This is from the e2fsck manual. It may be relevant SIGNALSThe following signals have the following effect when sent to e2fsck. SIGUSR1 This signal causes e2fsck to start displaying a completion bar or emitting progress information. (See discussion of the -C option.) SIGUSR2 This signal causes e2fsck to stop displaying a completion bar or emitting progress information. -- Frank McCormick
Re: Seeing progross during fsck on boot
On Sat, Sep 03, 2022 at 09:56:34AM +0100, Mike wrote: > Rereading my original request, I think perhaps I wasn't entirely clear > on a couple of points: I thought it was clear. Some of the responses completely baffled me. One person even mentioned xterm -- like, *what*? How does xterm come into play when you're booting a server and there's no GUI yet? > Maybe I'm being nostalgic but I seem to recall in days gone by that fsck > printed a progress bar out of hashes to show how it was getting along. Near as I can tell, that was a feature of the old sysv-rc scripts, which ran (originally/mostly) in series, instead of in parallel. The fsck progress bar(s) seem to have been lost in the move to systemd, perhaps because writing a progress bar isn't considered viable in a highly parallel boot system where other things might also be trying to write to the console. Or perhaps for other reasons. It appears that systemd-fsck(8) is the documentation for the new regime. Note this paragraph: systemd-fsck does not know any details about specific filesystems, and simply executes file system checkers specific to each filesystem type (/sbin/fsck.type). These checkers will decide if the filesystem should actually be checked based on the time since last check, number of mounts, unclean unmount, etc. Also note that /lib/systemd/systemd-fsck is a compiled program, not a shell script, so we can't just go in and edit the thing to make it pass -C. Now, here's an interesting thing: fsck.ext(4) refers to e2fsck.conf(5). Did you know that e2fsck (aka fsck.ext4) has a configuration file? I didn't either. e2fsck.conf(5) says that the pathname is /etc/e2fsck.conf (which doesn't exist by default on Debian 11). It also says that there are some options available, which can be set in the configuration file: report_features If this boolean relation is true, e2fsck will print the file system features as part of its verbose reporting (i.e., if the -v option is specified) report_time If this boolean relation is true, e2fsck will run as if the op‐ tions -tt are always specified. This will cause e2fsck to print timing statistics on a pass by pass basis for full file system checks. report_verbose If this boolean relation is true, e2fsck will run as if the op‐ tion -v is always specified. This will cause e2fsck to print some additional information at the end of each full file system check. Unfortunately, I couldn't find any wording about the progress bar. I don't see how to turn that on from the config file. So... sadly, I don't see a simple way to get the progress bar back. You could play around with this e2fsck.conf file and see what the options do, or you could edit the freakin' systemd SOURCE CODE to change how systemd-fsck calls fsck. I don't see a sensible way to insert a wrapper script into the execution flow, so I really wouldn't try going down that road. If none of these options work, you might need to talk to the systemd people about it, maybe putting in a feature request, or seeing if one of them knows a trick that'll work.
Re: Sometimes different network interface name?
David Wright writes: > If you look at how the package iwd keeps the kernel's choice of name, > you'll see it installs: [...] Interesting. I can't say I'm convinced by the systemd.link manpage that this is the correct configuration but let's assume the iwd peeps know what they're doing. I set this up since it's so simple. For the record, the type for this interface is wwan. I'll try a few reboots at some quiet time.
Re: Seeing progross during fsck on boot
On Fri, Sep 02, 2022 at 12:31:35AM +0200, DdB wrote: > Just thinking about your request ... > > Imagine this: You run "fsck -N ..." and get a rough estimate about the > time necessary to get the I/O and the job done, then it would be easy to > set up some timed countdown in parallel with the real fsck job, just for > you to have an idea about the time left. > > Alternatively, copy the whole device to another place, peform the fsck > there and decide, if copying back the result would be faster of just > running fsck on the original device. > > What i am intending to make you think about: Sometimes it is way more > difficult and time consuming to get a rough estimate of some result, > than to actually just get it for real. (You may talk to some math PHD > about that.) ... not worth the effort, because even you would prefer to > get the result as fast as possible and not wait twice the time just to > know ahead of time, when the job is likely to finish. > > Does that make sense to you too? > > Hi, Thanks for the replies. Rereading my original request, I think perhaps I wasn't entirely clear on a couple of points: 1) When there server starts, the default behaviour is to fsck the disks if they have been longer than 120 days (or something like that) without a fsck. It's a server and runs 24x7, so you can bet your bottom dollar that if if it does reboot, it will need to fsck. You can also bet that it was an uncontrolled shutdown because the UPS caught fire or something, so it's probably wise to run fsck. I haev no issue with this happening 2) I'm not too worried about how long it's actually going to take. The main issue is that I've had a couple of instances where the box has rebooted, I've sat around waiting for it to reboot, wondered why it hasn't, plugged a monitor in and seen jack on the screen, then just as I panic about what major issue could be wrong with it and key CTRL+ALT+DEL to see if I missed anything... I see the disk lights are solid on and assume it must be running fsck. Sometimes it does find some erros and spits that out to the screen. Otherwise it just sits there like a dog that's been shown a card trick. Maybe I'm being nostalgic but I seem to recall in days gone by that fsck printed a progress bar out of hashes to show how it was getting along. Someone asked about the file systems in use. Some are ext3 and some are ext4. TL;DR: When my server boots up and decdies to spent four hours fscking the disks, I'd just like to see some indiction that it's still alive and doing something :-) Regards, Mike. signature.asc Description: PGP signature
