Re: grub-pc error when upgrading from buster to bullseye
On 2024-02-12 15:14, Greg Wooledge wrote: According to <https://unix.stackexchange.com/questions/745904/how-does-the-grub-pc-postinstall-script-know-which-device-to-install-to> it uses debconf's database. That page includes instructions for viewing the device and changing it. I had just started looking into the grub-pc package before I saw this. I'll be able to test this out sometime tomorrow. I can't verify this on my machine, because mine uses UEFI. Will advise. Thank you Greg! -- Regards, John Boxall
Re: grub-pc error when upgrading from buster to bullseye
On 2024-02-12 09:34, Thomas Schmitt wrote: The disk/by-id file names are made up from hardware properties. I believe to see in the name at least: Manufacturer, Model, Serial Number. So you will have to find the configuration file which knows that /dev/disk/by-id address and change it either to the new hardware id or to a /dev/disk/by-uuid address, which refers to the cloned disk content. Have a nice day :) Thomas Thank you Thomas. That is what I am trying to find as I have searched for both the SSD drive model number and the WWN on the cloned HDD but can't find anything. I am aware that the label and uuid (drive and partition) are replicated on the cloned drive, but I can't find the model number (in text format) stored anywhere on the drive. I will keep looking. -- Regards, John Boxall
grub-pc error when upgrading from buster to bullseye
I am attempting to upgrade my laptop (Thinkpad X230) from buster to bullseye and have run into the error below. In order to ensure that all goes well and not to lose all of the tweaks I have added over time, I am performing the upgrade first on a cloned HDD (via "dd") of the working SDD. apt-get -y upgrade --without-new-pkgs Setting up grub-pc (2.06-3~deb11u6) ... /dev/disk/by-id/ata-WDC_WDS100T2B0A-00SM50_21185R801540 does not exist, so cannot grub-install to it! You must correct your GRUB install devices before proceeding: DEBIAN_FRONTEND=dialog dpkg --configure grub-pc dpkg --configure -a dpkg: error processing package grub-pc (--configure): installed grub-pc package post-installation script subprocess returned error exit status 1 All of the latest updates for buster have been applied before starting the process (below). apt-get update;apt-get -y upgrade;apt-get -y dist-upgrade; #shutdown, boot Debian live #clone working SSD drive to an HDD #boot cloned drive #login and open terminal session #su to root update-initramfs -u -k all grub-install --recheck /dev/sda apt-get update;apt-get -y upgrade;apt-get -y dist-upgrade; #modify /etc/apt/source.list to point to bullseye #modify all /etc/apt/source.list.d/* files to point to bullseye apt-get update;apt-get -y upgrade --without-new-pkgs; Running the recommended dpkg commands brings up the dialog to install grub and does complete successfully so that I can then run "apt-get -y dist-upgrade", which also runs successfully. What is confusing to me is that the error indicates the source SDD even though I have updated the boot images and installed grub on the cloned HDD. Is there some other configuration file that needs to be updated/removed so that the grub-pc install works without intervention? Source system info: user:~$ uname -a Linux laptop 4.19.0-26-amd64 #1 SMP Debian 4.19.304-1 (2024-01-09) x86_64 GNU/Linux user:~$ cat /etc/debian_version 10.13 user:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 36 bits physical, 48 bits virtual CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 58 Model name: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz Stepping:9 CPU MHz: 1202.696 CPU max MHz: 3600. CPU min MHz: 1200. BogoMIPS:5786.44 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache:256K L3 cache:4096K NUMA node0 CPU(s): 0-3 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d -- Regards, John Boxall
Re: Unable to open Thunderbird as default calendar app
On 2023-03-29 23:18, Max Nikulin wrote: Thank you for the insights Max. Updating the default mime type for webcal resolved my problem. -- Regards, John Boxall
Re: Unable to open Thunderbird as default calendar app
On 2023-03-29 00:21, Max Nikulin wrote: Your description is too general, it lacks details. E.g. you did not provide exact commands and their output that you use to check that defaults are set properly. Max, though I queried several of the mime types (via "xdg-mime query default *), the one I missed was "x-scheme-handler/webcal" which was still set to Evolution. "xdg-mime query default x-scheme-handler/webcal org.gnome.Evolution.desktop" In Firefox check application associations in preferences (settings). I was able to change the application association in Firefox which allowed me to select the Thunderbird launch script in /usr/bin and then process the URL. Chrome does not have the same capability as Firefox for application associations and relies on the system file associations. If you save link target to disk, can you open the downloaded file by thunderbird directly and by xdg-open? What is MIME type reported by the "file" utility? Yes, saving the file would have worked. file "appointments (4).ics" appointments (4).ics: vCalendar calendar file Behavior might depend on your desktop environment. GNOME desktop. It is hard to reason whether it should work without details what you have added to this file. These were queried (via xdg-mime) then added or changed in the files listed: text/calendar=thunderbird.desktop text/x-vcard=thunderbird.desktop application/mbox=thunderbird.desktop message/rfc822=thunderbird.desktop x-scheme-handler/mailto=thunderbird.desktop Check entries related to evolution in this file and MIME types specified in its .desktop file. I missed the x-scheme-handler/webcal mime type which was the root of my problem. Thank you for the help and push to look closer. -- Regards, John Boxall
Unable to open Thunderbird as default calendar app
I am trying to launch Thunderbird as my calendar application when opening a webcal link. Though I have updated all appropriate gnome-mimeapps.list and mimeapps.list files and used xdg-mime to query and set the default calendar application, my user session wants to open Evolution. The GNOME defaults for mail and calendar were already set to Thunderbird. If I remove Evolution, the dialog opens but specifies xdg-open and there are no options to choose another application. This happens in both Chrome and Firefox. I am running Debian 10/Buster with all of the latest updates. The following files have been updated to point to Thunderbird: ~/.config/gnome-mimeapps.list ~/.config/mimeapps.list /etc/xdg/gnome-mimeapps.list /etc/xdg/mimeapps.list ~/.local/share/applications/gnome-mimeapps.list ~/.local/share/applications/mimeapps.list /usr/local/share/applications/gnome-mimeapps.list /usr/local/share/applications/mimeapps.list /usr/share/applications/gnome-mimeapps.list /usr/share/applications/mimeapps.list I would appreciate if someone could point me to the missing puzzle piece. -- Regards, John Boxall
Re: apt update fails due to Label and Version changes for buster security
On 2022-12-16 13:00, Tim Woodall wrote: Thanks Tim, I will root around in the docs a little more. Strange because I've done multiple updates since your last backup date of Dec 2nd and not had this issue. H. -- Regards, John Boxall
apt update fails due to Label and Version changes for buster security
The following happened just now when updating my Buster system: + apt update Hit:1 http://deb.debian.org/debian buster InRelease Get:2 http://security.debian.org/debian-security buster/updates InRelease [34.8 kB] Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease Hit:4 http://deb.debian.org/debian buster-updates InRelease E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Label' value from 'Debian' to 'Debian-Security' N: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Version' value from '10.13' to '10' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. Do you want to accept these changes and continue updating from this repository? [y/N] n Hit:5 https://download.virtualbox.org/virtualbox/debian buster InRelease Hit:6 https://updates.signal.org/desktop/apt xenial InRelease Reading package lists... Done E: Failed to fetch http://security.debian.org/debian-security/dists/buster/updates/InRelease E: Some index files failed to download. They have been ignored, or old ones used instead. - I didn't have this issue about four hours ago. Does anyone have any ideas? -- Regards, John Boxall
Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update
On 2022-11-02 03:40, Anssi Saari wrote: Looks like a linux-5.10 source package was indeed added to Buster in August and as you noted, it's getting security updates too. There's some info on the what and when at https://tracker.debian.org/pkg/linux-5.10 but I don't know the why. Here is the information on the "why": https://www.debian.org/lts/security/2022/dla-3102 -- Regards, John Boxall
Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update
to a null pointer dereference or memory leak. A user permitted to mount arbitrary filesystem images could use these to cause a denial of service (crash or resource exhaustion). CVE-2022-3625 A flaw was discovered in the devlink subsystem which can lead to a use-after-free. The security impact of this is unclear. CVE-2022-3629 The syzbot tool found a memory leak in the Virtual Socket Protocol implementation. A local user could exploit this to cause a denial of service (resource exhaustion). CVE-2022-3633 The Linux Verification Center found a memory leak in the SAE J1939 protocol implementation. A local user could exploit this to cause a denial of service (resource exhaustion). CVE-2022-3635 Several race conditions were discovered in the idt77252 ATM driver, which can lead to a use-after-free if the module is removed. The security impact of this is unclear. CVE-2022-3649 The syzbot tool found flaws in the nilfs2 filesystem driver which can lead to a use-after-free. A user permitted to mount arbitrary filesystem images could use these to cause a denial of service (crash or memory corruption) or possibly for privilege escalation. CVE-2022-20421 A use-after-free vulnerability was discovered in the binder_inc_ref_for_node function in the Android binder driver. On systems where the binder driver is loaded, a local user could exploit this for privilege escalation. CVE-2022-20422 A race condition was discovered in the instruction emulator for 64-bit Arm systems. Concurrent changes to the sysctls that control the emulator could result in a null pointer dereference. The security impact of this is unclear. CVE-2022-39188 Jann Horn reported a race condition in the kernel's handling of unmapping of certain memory ranges. When a driver created a memory mapping with the VM_PFNMAP flag, which many GPU drivers do, the memory mapping could be removed and freed before it was flushed from the CPU TLBs. This could result in a page use-after-free. A local user with access to such a device could exploit this to cause a denial of service (crash or memory corruption) or possibly for privilege escalation. CVE-2022-39190 Gwangun Jung reported a flaw in the nf_tables subsystem. A local user could exploit this to cause a denial of service (crash). CVE-2022-39842 An integer overflow was discovered in the pxa3xx-gcu video driver which could lead to a heap out-of-bounds write. This driver is not enabled in Debian's official kernel configurations. CVE-2022-40307 A race condition was discovered in the EFI capsule-loader driver, which could lead to use-after-free. A local user permitted to access this device (/dev/efi_capsule_loader) could exploit this to cause a denial of service (crash or memory corruption) or possibly for privilege escalation. However, this device is normally only accessible by the root user. CVE-2022-41222 A race condition was discovered in the memory management subsystem that can lead to stale TLB entries. A local user could exploit this to cause a denial of service (memory corruption or crash), information leak, or privilege escalation. CVE-2022-41674, CVE-2022-42719, CVE-2022-42720, CVE-2022-42721, CVE-2022-42722 Soenke Huster discovered several vulnerabilities in the mac80211 subsystem triggered by WLAN frames which may result in denial of service or the execution of arbitrary code. CVE-2022-43750 The syzbot tool found that the USB monitor (usbmon) driver allowed user-space programs to overwrite the driver's data structures. A local user permitted to access a USB monitor device could exploit this to cause a denial of service (memory corruption or crash) or possibly for privilege escalation. However, by default only the root user can access such devices. For Debian 10 buster, these problems have been fixed in version 5.10.149-2~deb10u1. This update also fixes a regression for some older 32-bit PCs (bug #1017425), and enables the i10nm_edac driver (bug #1019248). It additionally includes many more bug fixes from stable updates 5.10.137-5.10.149 inclusive. We recommend that you upgrade your linux-5.10 packages. For the detailed security status of linux-5.10 please refer to its security tracker page at: https://security-tracker.debian.org/tracker/linux-5.10 Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams -- Regards, John Boxall
Re: linux-image-4.19.0-22-amd64
On 2022-09-30 13:31, Dan Ritter wrote: Marc Auslander wrote: linux-image-amd64 wants linux-image-4.19.0-22-amd64 but only linux-image-4.19.0-22-amd64-unsigned show up in a search. You are on an old version of Debian. Upgrade to the current stable version or go digging through the archives to get what you want. linux-image-amd64 is a virtual package that pulls in the specific package that your machine architecture needs. You can apt install linux-image-4.19.0-22-amd64-unsigned instead. If you don't use UEFI Secure Boot -- and you probably don't -- the unsigned package does everything you need. -dsr- I have a similar (same?) problem with my system. apt list -a --upgradable Listing... Done linux-image-amd64/oldstable 4.19+105+deb10u17 amd64 [upgradable from: 4.19+105+deb10u16] linux-image-amd64/oldstable,now 4.19+105+deb10u16 amd64 [installed,upgradable to: 4.19+105+deb10u17] dpkg -l | grep linux-image rc linux-image-4.19.0-13-amd64 4.19.160-2 amd64Linux 4.19 for 64-bit PCs (signed) rc linux-image-4.19.0-14-amd64 4.19.171-2 amd64Linux 4.19 for 64-bit PCs (signed) rc linux-image-4.19.0-16-amd64 4.19.181-1 amd64Linux 4.19 for 64-bit PCs (signed) rc linux-image-4.19.0-17-amd64 4.19.194-3 amd64Linux 4.19 for 64-bit PCs (signed) rc linux-image-4.19.0-18-amd64 4.19.208-1 amd64Linux 4.19 for 64-bit PCs (signed) rc linux-image-4.19.0-19-amd64 4.19.232-1 amd64Linux 4.19 for 64-bit PCs (signed) ii linux-image-4.19.0-20-amd64 4.19.235-1 amd64Linux 4.19 for 64-bit PCs (signed) ii linux-image-4.19.0-21-amd64 4.19.249-2 amd64Linux 4.19 for 64-bit PCs (signed) ii linux-image-amd644.19+105+deb10u16 amd64Linux for 64-bit PCs (meta-package) When I try either an "apt upgrade" or "apt full-upgrade", the package is not upgraded to "4.19+105+deb10u17". Could this be a result of there being no more updates to buster? -- Regards, John Boxall
Re: Comments on upgrade steps from one version of Debian to another
On 2022-08-20 19:27, Chuck Zmudzinski wrote: You can use apt, apt-get, or aptitude to run the commands that do most of the work, and in your script you chose apt for that task. I recall reading that they do not all use the same algorithm to determine which packages to upgrade and in what order, at each stage of the upgrade. I think I read somewhere that aptitude has the best algorithm, but apt-get is more suitable for a script. Chuck, I found the DebianUpgrade wiki page and all of the commands use "apt". When I have used "apt-get" it regularly pumps out a disclaimer that it doesn't have a good/reliable cli for scripting. I'm going to look at aptitude a little more. -- Regards, John Boxall
Re: Comments on upgrade steps from one version of Debian to another
On 2022-08-21 10:19, Andrew M.A. Cater wrote: apt-get autoremove I will definitely be adding this step. apt-get is definitely recommended for this at the moment, I think, and it > When I have seen other discussions about update/upgrade/etc, it was "apt" that people tended to recommend versus "apt-get". I was using apt-get in the original version, and switched to apt after reading those posts. I'll be creating several versions to see what works best. All the very best, as ever, Andy Cater Thanks and likewise! -- Regards, John Boxall
Re: Comments on upgrade steps from one version of Debian to another
On 2022-08-21 10:04, john doe wrote: The lines for the security mirror has changed on Bullseye. Thank you! I will be sure to add that check in. The script does not bail out on command failure, you might want to takecare of that if you automate this process by way of a script. That is all I can say on the cmds. Yes, there is a bail out at each step. "pipefail" was a good thing to learn about. If I may, for a fiew servers I would do it manually instead of blindly using a bunch of commands. I have one file/NFS server, a laptop and a desktop, so not a lot to worry aboutand at my leisure. If you need to automate this process, you should familiorize yourself with something like Ansible or in anycase a more robust solution. Thanks, I will look at ansible. -- Regards, John Boxall
Re: Comments on upgrade steps from one version of Debian to another
On 2022-08-20 16:24, Charles Curley wrote: I would not do that as a script. You have a good recipe there, but I would run each step manually so I could correct errors, adjust configuration files, and otherwise shoot trouble as it appears. I did a lot of testing the first time I ran the script and feel that I can get away with it. I do have a complete log of all command output. You should probably run 'apt auto-remove' from time to time in there as needed. That is a good point. I'll probably through at least one in before updating the sources.list files. Maybe one at the end as well. -- Regards, John Boxall
Re: Comments on upgrade steps from one version of Debian to another
On 2022-08-20 19:27, Chuck Zmudzinski wrote: On 8/20/2022 3:48 PM, John Boxall wrote: I created an upgrade script based on something I found a few years ago that indicated the steps to follow to upgrade from one version of Debian to another (e.g. Buster 10 to Bullseye 11). As I am going to need to run this script at some point (I am still running Buster/10 on my systems), I thought I'd ask the Debian user brain trust to comment/critique the scripted steps. So here they are: ### Start apt -y install aptitude aptitude search \'~o\' apt update apt -y upgrade apt -y full-upgrade dpkg -C apt-mark showhold # Update sources.list # Update files in sources.list.d (I don't even have this part started yetdidn't know I needed it the last time I ran it) # apt-get check apt update apt list --upgradable apt-get check apt -y upgrade apt -y full-upgrade aptitude search \'~o\' ### End Thoughts/critique/criticism/flames/etc Hi John, here are my suggestions: You can use apt, apt-get, or aptitude to run the commands that do most of the work, and in your script you chose apt for that task. I recall reading that they do not all use the same algorithm to determine which packages to upgrade and in what order, at each stage of the upgrade. I think I read somewhere that aptitude has the best algorithm, but apt-get is more suitable for a script. I don't remember if there are advantages or disadvantages to using apt. So you should do a little research to try to find the most up-to-date information about the pros and cons of the different apt related tools. The Debian wiki has a page on that, I think. Also, you might want to make sure you record the upgrade session in a logfile so you can examine what the script actually did in case there are problems. And of course, backup or take a snapshot beforehand so you can restore the system back to a working state in case things get broken badly. HTH, Chuck Thanks Chuck, very good points. apt always tells you that it isn't reliable in a script, which I am aware of, however, I'll check the wiki. I "think" that applies to apt-get as well. I've never used aptitude for anything but the one command (it was one of those recommended on the web page I saw), but will investigate it further. I use "tee" extensively in the script and record all of the command output. As for a backup, I will be cloning the drive to a backup and performing a test update to that drive first. My only real concern is the non-Debian software that I've installed over the years. We'll see how it goes. -- Regards, John Boxall
Comments on upgrade steps from one version of Debian to another
I created an upgrade script based on something I found a few years ago that indicated the steps to follow to upgrade from one version of Debian to another (e.g. Buster 10 to Bullseye 11). As I am going to need to run this script at some point (I am still running Buster/10 on my systems), I thought I'd ask the Debian user brain trust to comment/critique the scripted steps. So here they are: ### Start apt -y install aptitude aptitude search \'~o\' apt update apt -y upgrade apt -y full-upgrade dpkg -C apt-mark showhold # Update sources.list # Update files in sources.list.d (I don't even have this part started yetdidn't know I needed it the last time I ran it) # apt-get check apt update apt list --upgradable apt-get check apt -y upgrade apt -y full-upgrade aptitude search \'~o\' ### End Thoughts/critique/criticism/flames/etc -- Regards, John Boxall
Re: Unable to minimize Firefox 91.5.0esr at top of frame
On 2022-01-13 17:55, Ralph Katz wrote: 1) Latest Debian stable is 11 (Bullseye). 2) Latest Firefox ESR is today's security upgrade, 91.5.0esr (64-bit). 3) On my XFCE desktop, firefox functions exactly as you seek. Perhaps you have desktop environment or window manager issue? More details about that could be helpful. 1) Debian 10 (Buster) 2) FF ESR 91.5.0esr (64-bit) (released at the same time as the instance for Bullseye) 3) Gnome3 with Wayland disabled. I also tried with Wayland enabled and no difference. Perhaps it is a Gnome issue. I'll keep looking. -- Regards, John Boxall
Unable to minimize Firefox 91.5.0esr at top of frame
After upgrading to the latest Debian 10 (Buster) Firefox ESR (91.5.0esr 64bit), I found that I could not minimize the window by right clicking on the top of the window frame and selecting "Minimize", whether the menu bar was present or not. The menu for selecting minimize was not even present. I was able to perform the minimize with the old (78.x) release. I recently installed the latest FF release from the Mozilla site (version 95.0.2 64bit) and noted the same situation. Is this expected going forward or is this a bug? -- Regards, John Boxall
Re: xsane can't see Brother ADS-2700W scanner
On 2021-04-03 1:00 p.m., Charlie Gibbs wrote: On 2021-04-02 10:56 a.m., Charlie Gibbs wrote: the error message. I forget the exact wording, but it was pretty specific about the USB device being full, as opposed to some sort of internal memory overflow. Charlie, It is also a possibility that your USB thumb drive _doesn't_ have the capacity that it says it does. There are a lot of "fake" USB thumb drives that have far less capacity than advertised. Would you be able to try an external hard drive connected via a USB adapter? -- Regards, John Boxall
Re: on the verge of shopping for new desktop hardware, recommendations?
On 2021-03-07 1:06 p.m., songbird wrote: apparently Gigabyte has/had some strange ideas about UEFI. sadly i didn't know this and couldn't shop other than through the phone line talking to someone so i had to rely upon them selecting a motherboard for me. don't really want to sent it back either. I have two Gigabyte m/b's I've been using for some time and only recently got things, sort of, figured out. Here are a few suggestions and I hope they work for your m/b: - disablbe IOMMU support (more on this in a moment) - specify "UEFI and Legacy" for "Boot Mode Selection" - specify "Legacy first" for "Storage Boot Option Control" - specify "Legacy OPROM" for "Other PCI Device ROM Priority" - though this will depend on your installed hardware - I have switched "SATA mode selection" to "AHCI" instead of "IDE" - your choice - If you decide to _not_ use EFI, __ALWAYS_ go into the boot menu to select the BIOS mode boot for the USB stick you are using. - Once in the Debian installer boot menu: - in BIOS mode press the "TAB" key (I __SO__ wish I had found out about this months ago) - add the following to the "linux" command line: iommu=soft - if you are going to create a raid array (mine is raid5) also add this to the "linux" line: rootdelay=10 - press the key - if you choose EFI boot mode, edit the install command line as above Until I started using the above I couldn't get any of the USB ports to function and the raid array to come up properly. YMMV. -- Regards, John Boxall
Re: Sharing a scanner from a Buster system
On 2021-03-07 12:47 p.m., Brad Rogers wrote: On Sun, 7 Mar 2021 17:34:59 + Brian wrote: Hello Brian, put it there because I tend to forget changes I make in /etc! In this You're using a computer; you don't /need/ to remember those changes. Use the computer to do it for you. IOW, create a text file documenting those system additions you've made. Put a link to the file on your desktop. You'll never forget the document is there. Then, when you get curious enough to look at the file again, your memory will be jogged. Brad, I agree 100%..unfortunately, like my memory, I use selective action.sometimes I create one and other times :-) -- Regards, John Boxall
Re: Sharing a scanner from a Buster system
On 2021-03-07 12:45 p.m., Brian wrote: On Sun 07 Mar 2021 at 17:34:59 +, Brian wrote: John, I forgot to ask before - and forgot again! What device are you using? An Epson Perfection 2480 Photo. So, having read a little further, maybe I could have used the Epson offering for a driver. I didn't because, well, I hadn't read further and because "it just worked" under Bullseye. I haven't rebuilt the specific system in question to Buster yet, but on my test system with the scanner attached the bug report fix worked fine. -- Regards, John Boxall
Re: Sharing a scanner from a Buster system
On 2021-03-05 12:04 p.m., Brian wrote:
Thank you, too. In the light of your issue, the Troubleshooting section
now has a link to the bug report. Hopefully, this will help users.
Brian, in the reference to the bug report, were you referring to the file:
/etc/udev/rules.d/65-libsane.rules
Contents:
ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw
$env{DEVNAME}"
I suppose I could have changed /lib/udev/rules.d/60-libsane.rules to
include that line. Not sure which is cleaner. If I upgrade the system
from Buster to Bullseye the file I created would be redundant.
Thoughts?
--
Regards,
John Boxall
Re: Sharing a scanner from a Buster system
On 2021-03-05 6:05 a.m., Brian wrote: [1} https://wiki.debian.org/SaneOverNetwork#Sharing_a_USB_Connected_Scanner:_the_Basics The note on Bug #918358 towards the end of https://wiki.debian.org/Scanner#perms could help with a solution. Once I looked at the bug report it most certainly did! Succinct and to the point. Thank you! -- Regards, John Boxall
Re: Sharing a scanner from a Buster system
On 2021-03-05 4:50 a.m., David Pottage wrote: David, Thank you for the detailed instructions. I hope this solves your problem. I struggled with that exact issue a couple of months ago, and I know how frustrating it can be. It should. I will try it later today. The frustration was amplified because of my experience after using Bullseye and not needing to do any of it. -- Regards, John Boxall
Re: Sharing a scanner from a Buster system
On 2021-03-05 3:38 a.m., Darac Marjal wrote: First of all, you might need to give us some hint as to how it doesn't work? Agreed...bad form...no excuse. "scanimage -L" on the client did not show the scanner whereas on the server it did. I tried from both root and non-root users. "doesn't work" could range from "can't see the scanner at all" to "always produces a black image" to "inexplicably fills the room with rabid weasels". Based on this (from the reference) "The server will now be sharing the USB connected scanner with other designated machines on the network. " I would have expected to be able to see the scanner on the client in the scanimage output without having to do anything else. On the Bullseye instance the scanimage output did show the scanner with no additional steps. Thank you for the feedback. -- Regards, John Boxall
Sharing a scanner from a Buster system
I have been trying for some time to setup a system that will share an attached scanner over the network. I had hoped to use Buster as it is still the stable instance of Debian. I have followed everything in [1] but I could never get it to work. I then tried Bullseye and it worked right away. Today I decided to install a clean NETINST image of each and repeat the "server" steps as outlined at [1]. Even though the howto states that it covers Debian from versions 8 to 11, I could not get it to work on Buster (10). The process failed on Buster, again, even though scanimage on the system saw the USB scanner (Epson Perfection 2480 Photo). I then installed Bullseye. The exact same process and the very same saned.conf file worked immediately. The client was the same in both cases (Buster). Is there a tweak that I am missing? Has there been a change that isn't in Buster but has made it to Bullseye? Any recommendations on debug steps would be appreciated? [1} https://wiki.debian.org/SaneOverNetwork#Sharing_a_USB_Connected_Scanner:_the_Basics -- Regards, John Boxall
Re: How to self-load non-freeware firmware on existing netinst ISO installer
On 2021-02-24 11:07 a.m., Brian wrote: On Wed 24 Feb 2021 at 22:51:05 +0800, Robbi Nespu wrote: [...] TLDR; I want firmware-iwlwifi already loaded and working during Debian installation phase, not after install. This is from memory; I haven't done it for some time. 1. The USB stick you boot from will have empty space or a secomd partition. 2. Extract the firmware files from the .deb and put them on the stick. 3. Boot and change to console 2: ALT-F2. 4. Mount the partition holding the firmware on /mnt. 5. Create /lib/firmware: mkdir /lib/firmware and transfer the firmware there. 6. ALT-F1 to go back to d-i. d-i should now find the firmware. Alternatively, you can extract the firmware files to a different USB stick and put them in the root of that one, insert both and the installer will find the files when you boot the original USB stick. -- Regards, John Boxall
Re: Lenovo wireless network not work?
On 2021-01-31 12:12 p.m., sebul wrote: Hello. I have a Lenovo IdeaCentre Mini 5 01IMH05. Spec is https://psref.lenovo.com/Detail/IdeaCentre/IdeaCentre_Mini_5_01IMH05?M=90Q70006KA I installed Debian 10.7 on it. How can I use wireless networks on Lenovo IdeaCentre Mini 5? This might help: https://www.cyberciti.biz/faq/linux-find-wireless-driver-chipset/ -- Regards, John Boxall
Re: I have a Gigabyte GA-A320M-H is there a BUG in this motherboard?
On 2021-01-02 4:06 a.m., ike wrote: On 01/01/2021 11:42 PM, ike wrote: I have a Gigabyte GA-A320M-H I have tried to install Debian 10.7 . I have enable Iommu and CSM. When the menu comes up it does not matter what I select after I hit enter the screen is just a mess can you help me please. After I press enter the screen is just lines dots and a mess. I under stand there is a BUG in Lommu if so how do I fix it. I am not an expert with this so be patient with me please. Thank you Isaac Shields nejek...@bigpond.com Issac, If you have been able to complete the Buster install and install GRUB on the appropriate disk, please try the following: __DISABLE__ IOMMU support in the motherboard BIOS. Reboot to the GRUB menu and type "e" to edit the default boot option type " iommu=soft" (no quotes) at the end of the "linux" line. Press the "F10" key to boot the default option. If that works (the system comes up to a Debian login screen) then you need to edit /etc/default/grub (under the root user; create a backup copy first) and update the line below with: GRUB_CMDLINE_LINUX="iommu=soft" Save the updated file Run the "update-grub" command (again, under the root user). Reboot I have two systems with Gigabyte motherboards and I need to add this to the GRUB configuration in order to get all USB ports working properly. -- Regards, John Boxall
Re: Installation instructions.
On 2020-12-05 4:07 p.m., David wrote: I have both i386 and amd64 machines available to test, and I'm using i386 when trying to assist Peter. David, In your testing have you been able to cleanly boot and run the installer through to completion, whether i386 or amd64? I have some results from a buster amd64 VirtualBox guest, but it isn't clean (kernel mismatch), but the install does progress. I will be testing on bare metal soon-ish. -- Regards, John Boxall
Re: Installation instructions.
On 2020-12-01 5:50 p.m., pe...@easthope.ca wrote:
but the CD image is not found.
Peter,
Can you please confirm if you are/are not trying to boot the ISO image
from a USB stick?
If you _are_ you are may be running into the same head-banging situation
I was having the past week. It was a combination of flakey motherboard
BIOS configuration and one kernel commandline parameter ("iommu=soft")
that needed to be specified to deal with the flakey m/b.
Until I configured the m/b to process Legacy first (before UEFI),
disabled IOMMU, selected the UEFI instance of the USB stick and
specified the above kernel parameter by editing the GRUB configuration,
I could not get _two_ different Gigabyte motherboards to find the USB
stick as a CDROM. On one of them I had to go into the BIOS to explicitly
specify "USB Mass Storage" as "CDROM", in addition to the above. Both
m/b's are using an AMI BIOS.
--
Regards,
John Boxall
Re: NTFS partitions can't be mounted
P.S. Debian is working 100% perfectly, it is up and running, the unique problem is the access to the NTFS partitions You are running into Windows "hibernation" that leaves the disks in an "unclean" state when shut down in that manner (sadly, a default..."fastboot" as John Doe was pointing you to). From CNET: "In the Command Prompt *window*, type powercfg.exe /*hibernate* off and press the Enter key. ..." Shut the Windows system down and try again. -- Regards, John Boxall
Re: Fixing a Grub Foul-up
You might be running in to the problem that the blkid that is expected may be changed during boot. As I am running into a similar problem on a system I upgraded to buster from stretch, this link might help: https://www.thegeekdiary.com/inconsistent-device-names-across-reboot-cause-mount-failure-or-incorrect-mount-in-linux/ On 2020-11-16 1:48 p.m., Martin McCormick wrote: I have goofed, I think. There is a serca-2000-vintage Dell Optiplex that has been working fine up to yesterday when I did the usual apt-get update followed by the apt-get upgrade on buster. The update and upgrade appeared to work. One of the things that got visited was grub and it was then that I was reminded that there was another drive in the system that had a bootable image of buster on it also. Grub reported seeing it on /dev/sdc which is coorrect. This particular system has a zip drive that always shows up as /dev/sdb so the next hard drive after /dev/sda is /dev/sdc. I rebooted to make sure all was well and waited and waited . . . The system sits there like a bump on a log. I have a usb device that lets one mount IDE and SATA drives that are outside the system so I pulled the sata drive which is the boot drive for the now dead system and plugged it in to the usb converter. the drive breezes through fsck and looks perfectly normal. I looked at /boot/grub/grub.cfg which one is not supposed to edit as grub builds it based on /etc/default/grub which one does edit. If I was to mount that partition on a working system, it, of course, will have a different device number such as /dev/sde1 instead of /dev/sda1 which it should have when booting up the system it normally runs in. Is there a safe way to mount this drive, possibly using chroot, re-run grub-config and get the drive bootable again? If I look at grub.cfg and /etc/default/grub, everything looks as if it should work but it doesn't. I think boot problems are some of the most agrevating issues. They are true show stoppers. I've got backups but that's beside the point. Unless I can fix whatever happened, it's going to be quite a time waster. Thanks for any constructive suggestions. Martin McCormick -- Regards, John Boxall
Re: SANE default scanner
I was having the same problem with the same model mfp. I had to go into the HPLIP Toolbox app and setup the printer. Once I did that xsane and simple scan could find the scanner. On 2020-07-27 8:40 a.m., Nicolas George wrote: Georgi Naplatanov (12020-07-27): https://linux.die.net/man/1/scanimage "The -d or --device-name options must be followed by a SANE device-name like 'epson:/dev/sg0' or 'hp:/dev/usbscanner0'. A (partial) list of available devices can be obtained with the --list-devices option (see below). If no device-name is specified explicitly, scanimage reads a device-name from the environment variable SANE_DEFAULT_DEVICE. If this variable is not set, scanimage will attempt to open the first available device. " Thanks. Unfortunately, it does not work: for GUI tools, this environment variable pre-selects the device in the device selection dialog, but it does not make it appear if it is not detected (?!???@!%@?!!!?). Also, it works for only one scanner. Regards, -- Regards, John Boxall
