Re: usrmerge
On 03/10/2022 09:40, Frank wrote: Op 02-10-2022 om 21:29 schreef billium: /usr/bin /usr/lib* & /usr/sbin are directories /lib/x86_64-linux-gnu & /usr/lib/x86_64-linux-gnu are directories /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc.so.6 are both files Before the fault occurred I had made no changes (except apt update /upgrade). After the fault, I tried changing the root directory (/lib /bin) files to sym links but got bored by the time I had done thirty different files. Bad idea anyway. It's not about symlinking individual files. Everything is moved to the corresponding subdirectories in /usr and the directories in the root are replaced by symlinks. There are only six of those on my system (also debian testing). I undid the above changes, and the system works o.k., just not upgradeable. Right. I still don't get how that libc.so.6 file could have ended up in two places (earlier failed usrmerge? another script? manually after all?), but in my view there are only two possible ways to fix this: the clean one (reinstalling) and the messy one (completing the usrmerge manually). Be aware that the latter comes with no guarantees whatsoever and will probably fail massively if you didn't fully restore the above changes (i.e. left a symlink somewhere). If you want to go the messy route, I'll need to check a couple of things first. Can't do that until later today. Regards, Frank There was no failed or manual moves. usrmerge may have failed during previous upgrades and I may not have noticed. Please do not waste any time on this as no one else has reported errors. It is not that difficult to install :) . Thanks again for your time. Billy
Re: usrmerge
On 02/10/2022 20:09, Frank wrote: Op 02-10-2022 om 19:12 schreef billium: /bin, /lib(*) and /sbin are directories not links, sorry I did not make that clear. And the corresponding items in /usr? Also directories? What about /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6? Both files? And /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu? Both directories? Did you by any chance copy (or move or symlink) individual files before the usrmerge upgrade? Regards, Frank Thanks Frank /usr/bin /usr/lib* & /usr/sbin are directories /lib/x86_64-linux-gnu & /usr/lib/x86_64-linux-gnu are directories /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc.so.6 are both files Before the fault occurred I had made no changes (except apt update /upgrade). After the fault, I tried changing the root directory (/lib /bin) files to sym links but got bored by the time I had done thirty different files. I undid the above changes, and the system works o.k., just not upgradeable. Billy
Re: usrmerge
On 02/10/2022 18:19, Michael Stone wrote: On Sun, Oct 02, 2022 at 06:12:45PM +0100, billium wrote: may be I am idiot for keeping it so long since a re-install. I think stretch was the install, and it is now on bookworm. FYI, skipping releases is not supported; in future, go through each release in order when upgrading. Whether that was the cause of the problem it's impossible to say based on the information available. There was no skipping, I went through all testings from stretch through buster, bullseye on to bookworm the years.
Re: usrmerge
On 02/10/2022 15:32, Michael Biebl wrote: On Sat, Oct 01, 2022 at 11:06:55AM +0100, billium wrote: Since the last update to my debian testing I am unable to install anything or upgrade. Setting up usrmerge (31) ... FATAL ERROR: Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6 exist. How did you arrive in this state? Is /lib already a symlink to /usr/lib on your system? This is a good question. billium, if you by any chance have a backup of your system from before the upgrade, it would be great if you can file a bug report against the usrmerge package so its maintainers can have a look. Michael Thanks Michael /bin, /lib(*) and /sbin are directories not links, sorry I did not make that clear. I only backup /etc and /home and some other setting files, even though it is testing. This is the first big failure, for me, in the years, though re-install is not a big issue, which I will do some time later as it all works but just cannot be updated and no new applications. I see your point in knowing weather the previous or the failed update caused the problem would help the maintainer. But all I can state is that it was between upgrades as no other application installs were made in this time. I do not know what I can say in a bug report ... may be I am idiot for keeping it so long since a re-install. I think stretch was the install, and it is now on bookworm. Billy
Re: usrmerge
On 01/10/2022 15:07, billium wrote: Thanks for your time Greg This occurred from updates only no installs for a while. I did try moving some of the files and sym linking, then rebooting to check, all worked (inc libc) but got bored doing it after about 30 times. I also tried sym linking /usr/bin and /usr/lib etc but it locked up then :). This system is old now repeatedly doing upgrade, dist-upgrade and full-upgrade through the years. So maybe its time is done ! :( One mistake, through laziness, I never update the config files, so maybe a re-install (Sounds Windows-ish) may help. This is the original text: aurora:~# apt autoremove Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 604 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up usrmerge (31) ... FATAL ERROR: Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6 exist. You can try correcting the errors reported and running again /usr/lib/usrmerge/convert-usrmerge until it will complete without errors. Do not install or update other Debian packages until the program has been run successfully. E: usrmerge failed. dpkg: error processing package usrmerge (--configure): installed usrmerge package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: usrmerge E: Sub-process /usr/bin/dpkg returned an error code (1) also: aurora:~# apt install usr-is-merged Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: usr-is-merged 0 upgraded, 1 newly installed, 0 to remove and 604 not upgraded. 1 not fully installed or removed. Need to get 4,920 B of archives. After this operation, 12.3 kB of additional disk space will be used. Get:1 http://ftp.uk.debian.org/debian testing/main amd64 usr-is-merged all 31 [4,920 B] Fetched 4,920 B in 0s (35.6 kB/s) Selecting previously unselected package usr-is-merged. (Reading database ... 493237 files and directories currently installed.) Preparing to unpack .../usr-is-merged_31_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_31_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_31_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Billy On 01/10/2022 13:40, Greg Wooledge wrote: On Sat, Oct 01, 2022 at 11:06:55AM +0100, billium wrote: Since the last update to my debian testing I am unable to install anything or upgrade. Setting up usrmerge (31) ... FATAL ERROR: Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6 exist. How did you arrive in this state? Is /lib already a symlink to /usr/lib on your system? I can move the stated file and create a symlink DO NOT TRY THAT! That's libc. If you try to move that in the most naive way imaginable, your system will break immediately. If you've already got a fully merged /usr, there is a package you can install to indicate this (usr-is-merged). Install that, and usrmerge won't try to set itself up. Or something like that. So I'm told. I'm not running testing at this time. If you've got a *partially* merged /usr, then I may not be able to help you much. You'll need an expert. A good start would be understanding whatever state you're in and how you got there. Did a previous apt-get operation try to install usrmerge and fail? Do you have the original error message? Can you trace through the steps that usrmerge performs, and undo whichever ones have already been done? Or, if you're close to completion, complete the remaining steps by hand, and then install usr-is-merged? In the worst possible case, you might need to reinstall from scratch. So, no matter what you try to do at this point, making a full backup of your important data (/home /etc /usr/local and so on) would be highly advisable. Sorry about top posting misplaced cursor
Re: usrmerge
Thanks for your time Greg This occurred from updates only no installs for a while. I did try moving some of the files and sym linking, then rebooting to check, all worked (inc libc) but got bored doing it after about 30 times. I also tried sym linking /usr/bin and /usr/lib etc but it locked up then :). This system is old now repeatedly doing upgrade, dist-upgrade and full-upgrade through the years. So maybe its time is done ! :( One mistake, through laziness, I never update the config files, so maybe a re-install (Sounds Windows-ish) may help. This is the original text: aurora:~# apt autoremove Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 604 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up usrmerge (31) ... FATAL ERROR: Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6 exist. You can try correcting the errors reported and running again /usr/lib/usrmerge/convert-usrmerge until it will complete without errors. Do not install or update other Debian packages until the program has been run successfully. E: usrmerge failed. dpkg: error processing package usrmerge (--configure): installed usrmerge package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: usrmerge E: Sub-process /usr/bin/dpkg returned an error code (1) also: aurora:~# apt install usr-is-merged Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: usr-is-merged 0 upgraded, 1 newly installed, 0 to remove and 604 not upgraded. 1 not fully installed or removed. Need to get 4,920 B of archives. After this operation, 12.3 kB of additional disk space will be used. Get:1 http://ftp.uk.debian.org/debian testing/main amd64 usr-is-merged all 31 [4,920 B] Fetched 4,920 B in 0s (35.6 kB/s) Selecting previously unselected package usr-is-merged. (Reading database ... 493237 files and directories currently installed.) Preparing to unpack .../usr-is-merged_31_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_31_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_31_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Billy On 01/10/2022 13:40, Greg Wooledge wrote: On Sat, Oct 01, 2022 at 11:06:55AM +0100, billium wrote: Since the last update to my debian testing I am unable to install anything or upgrade. Setting up usrmerge (31) ... FATAL ERROR: Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6 exist. How did you arrive in this state? Is /lib already a symlink to /usr/lib on your system? I can move the stated file and create a symlink DO NOT TRY THAT! That's libc. If you try to move that in the most naive way imaginable, your system will break immediately. If you've already got a fully merged /usr, there is a package you can install to indicate this (usr-is-merged). Install that, and usrmerge won't try to set itself up. Or something like that. So I'm told. I'm not running testing at this time. If you've got a *partially* merged /usr, then I may not be able to help you much. You'll need an expert. A good start would be understanding whatever state you're in and how you got there. Did a previous apt-get operation try to install usrmerge and fail? Do you have the original error message? Can you trace through the steps that usrmerge performs, and undo whichever ones have already been done? Or, if you're close to completion, complete the remaining steps by hand, and then install usr-is-merged? In the worst possible case, you might need to reinstall from scratch. So, no matter what you try to do at this point, making a full backup of your important data (/home /etc /usr/local and so on) would be highly advisable.
usrmerge
Since the last update to my debian testing I am unable to install anything or upgrade. Setting up usrmerge (31) ... FATAL ERROR: Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6 exist. I can move the stated file and create a symlink but there are so many files, it seems endless. Has anybody got a quick reliable solution? Thanks Billy
Re: Markdown previewer
On 17/03/2021 08:34, Darac Marjal wrote: On 17/03/2021 06:30, Victor Sudakov wrote: Dear Colleagues, Can you please advise a good GUI Markdown previewer? Many editors (vim, mousepad) can highlight Markdown syntax, but it's a different matter. I'd like the previewer to display rendered Markdown nicely with fonts, hyperlinks, numbered lists etc. VSCodium (https://vscodium.com) can do a good job of this, and is a popular all-purpose IDE. Simply open the Markdown file and press Ctrl+K, V to get a live side-by-side preview. If you want something command-line based, then you need to convert the Markdown code to code that some other renderer will understand. Pandoc (https://packages.debian.org/buster/pandoc) can do that for you with a simple "pandoc -o README.html README.md" or "pandoc -o README.pdf README.md" etc. If you are on KDE there is ReText.
Re: Home made backup system
On 18/12/2019 17:02, rhkra...@gmail.com wrote: Aside / Admission: I don't backup all that I should and as often as I should, so I'm looking for ways to improve. One thought I have is to write my own backup "system" and use it, and I've thought about that a little, and provide some of my thoughts below. A purpose of sending this to the mailing-list is to find out if there already exists a solution (or parts of a solution) close to what I'm thinking about (no sense re-inventing the wheel), or if someone thinks I've overlooked something or making a big mistake. Part of the reason for doing my own is that I don't want to be trapped into using a system that might disappear or change and leave me with a problem. (I subscribe to a mailing list for one particular backup system, and I wrote to that list with my concerns and a little bit of my thoughts about my own system (well, at the time, I was hoping for a "universal" configuration file (the file that would specify what, where, when, how each file, directory, or partition to be backed up would be treated), one that could be read and acted upon by a great variety (and maybe all future backup programs). The only response I got (iirc) was that since their program was open source, it would never go away. (Yet, if I'm not mixing up backup programs, they were transitioning from using Python 2 as the underlying language to Python 3 -- I'm not sure Python 2 would ever go completely away, or become non-functional, but it reinforces my belief / fear that any (complex?) backup program, even open source, would someday become unusable. So, here are my thoughts: After I thought about (hoped for) a universal config file for backup programs and it seeming that no such thing exists (not surprising), I thought I'd try to create my own -- this morning as I thought about it a little more (despite a headache and a non-working car what I should be working on), I thought that the simplest thing for me to do is write a bash script and a bash subroutine, something along these lines: * the backups should be in formats such that I can access them by a variety of other tools (as appropriate) if I need to -- if I backup an entire directory or partition, I should be able to easily access and restore any particular file from within that backup, and do so even if encrypted (i.e., encryption would be done by "standard programs" (a bad example might be ccrypt) that I could use "outside" of the backup system. * the bash subroutine (command) that I write should basically do the following: * check that the specified target exists (for things like removable drives or NAS type things) and has (sufficient) space (not sure I can tell that until after backup is attempted) (or an encrypted drive that is not mounted / unencrypted, i.e., available to write to) * if the right conditions don't exist (above) tell me (I'm thinking of an email as email is something that always gets my attention, maybe not immediately, but soon enough) * if the right conditions do exist, invoke the commands to backup the files * if the backup is unsuccessful for any reason, notify me (email again) * optionally notify me that the backup was successful (at least to the extent of writing something) * optionally actually do something to confirm that the backup is readable / usable (need to think about what that could be -- maybe write it (to /tmp or to a ramdrive), do something like a checksum (e.g., sha-256 or whatever makes sense) on it and the original file, and confirm they match * ??? All of the commands invoked by the script should be parameters so that the commands can be easily changed in the future (e.g., cp / tar / rsync, sha-256 or whatever, ccrypt or whatever, etc.) Then the master script (actually probably scripts, e.g. one or more each for hourly, daily, weekly, ... backups) would be invoked by cron (or maybe include the at command? --my computers run 24/7 unless they crash, but for others, at or something similar might be a better choice) would invoke that subroutine / command for each file, directory, or partition to be backed up, specifying the commands to use, what files to backup, where to back them up, encrypted or not, compressed or not, tarred or not, etc. In other words, instead of a configuration file, the system would just use bash scripts with the appropriate commands, and invoked at the appropriate time by cron (or with all backup commands in one script with backup times specified with at or similar). Aside: even if Amanda (for example) will always exist, I don't really want to learn anything about it or any other program that might cease to be maintainied in the future. The rsync web site had some good examples. There is a daily rotating one and overall backups also. I use these to backup to a Debian nas and a VPS.
Re: Is Debian 9 supposed to work on a Geode?
Geode does not have the full i686 instruction set. (Something about NOPL) Try i486 Apparently faster than i586. This is from memory and depends on GX or LX some say compile with flags |-march=i486 -mtune=geode| Or just use x86. :) On 28/04/2019 20:54, Björn Persson wrote: Björn Persson wrote: Brian wrote: brian@futro:~$ uname -a Linux futro 4.9.0-7-686 #1 SMP Debian 4.9.110-3+deb9u1 (2018-08-03) i586 GNU/Linux That's an older Linux than I got. Perhaps I could try that package, if I can get hold of it. I've installed linux-image-4.9.0-7-686. It hangs in the same way as the later versions. I don't know why it works for you and not for me. Björn Persson
cross compiling for arm
I am having problems with cross compiling a small program for the BeagleBone (single board Arm Cortex A processor) on an amd64 PC. I can compile the program on the BeagleBone, but would like to use QTcreator on the Debian Buster desktop PC. With the BeagleBone on Stretch and the development PC on Buster , I use the crossbuild-essential-armhf v12.5 to produce the Arm binary. Unfortunately it uses GLIBC_2.28. Buster itself uses 2.27 and Stretch 2.24. S I cannot run my produced binary. I notice Sid uses GLIBC_2.28 but I do not want to put this on a BeagleBone. I tried buster on the BeagleBone but it also uses 2.27. I tried to force crossbuild to the Stretch version of 12.3 but I probably did not do that correctly. I could use a Stretch chroot on the development PC but then could not use my normal QTcreator or put Stretch on the PC but other programs require Buster. When the program is run, the error is "/lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.28' not found" I would prefer to keep the BeagleBone on Stretch. Is there a way round this library dependency? Thanks in anticipation. Billy
Thinkpad X220
I have a problem with Linux on my Lenovo Thinkpad X220 and m looking to find anyone who may have had, and solved the problem. On my installed Debian buster, kernel 4.12.01 presents no problem, but when I updated to 4.13.0 I noticed the fan runs at full speed all the time and the laptop is slow to respond both with and without X. HTOP shows all four cores as normal (less than 1% usage) and normal memory usage. I did a diff between .configs and there were some new drivers but they were not used, NVEM was changed from module to in kernel (m to y) and security from DAC to apparmor. I created and ran the latest Debian install CD onto USB (using as live rather than install), which uses kernel 4.13 and that had the same problem as did a PureOS live cd. I Also tried the latest Kali Linux, with kernel 4.14 and it is still the same. The laptop runs fine with 4.12.01, but it would be good to know what is wrong. So before making and playing around with the kernel, I thought I would ask here if anybody has experienced the same problem. I think it may have started with the update to 4.12.02 Also why wouldn't htop see this activity? I also have a Thinkpad T410 which is running Sid on 4.14 with no problem. Billy
