Re: usb => serial port converter
On 08/07/2024 22:46, Lee wrote: On Sun, Jul 7, 2024 at 8:51 PM Andy Smith wrote: In my experience USB serial gadgets on Linux tend to just work or will never work. It worked this time! Other than plugging it into a windows machine that had the proper drivers first, I don't know what changed. Some devices may advertise them as mass storage drives at first to autorun windows drivers installer. I would not expect it from a cheap serial port adapter though. See the usb-modeswitch package to change exposed USB interface from command line. Great! I had to add myself to the dialout group to be able to talk to the device, but screen /dev/ttyUSB0 38400 works. systemd-logind may grant access to the currently active user. Search for "uaccess" in /usr/lib/udev/rules.d/ <https://github.com/systemd/systemd/issues/4288> "Document the uaccess mechanism / dynamic device permissions" <https://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management> Tomasz Torcz. Linux automatic user ACL management
Re: usb => serial port converter
Hi Lee, Its very much "horses for courses". If all you want to do is talk to network switch console ports, there are cheap cables from Amazon that will do that. If you *only* want a general purpose RS-232 StarTech and TrendNet should just work. If you want to be able to do other things like RS-422 and RS-485, I would recommend a Moxa uPort 1150. Be aware that you will have to install the Moxa driver to use this - its not generally included with the kernel. Cheers, Paul. On Sun, 7 Jul 2024 at 22:02, Lee wrote: > What's everybody using for a usb => serial port converter? > > I got a new network switch and .. OhNoes!! how to I talk to the darn > thing??? > > I went looking thru cabinets and came up with a keyspan usb -> serial > dongle; a quick search found the site with driver downloads, but they > all were for Windows or MacOS. I tried plugging the dongle into my > debian laptop but it didn't recognize it :( > > So... what are people using to talk to serial devices now that PCs > don't come with serial ports anymore? > > And what program are you using to talk to something over the serial > link? pterm or something else? > > I still have a Windows machine, so install the drivers, configure > putty to talk to COM4 & I'm good to go. But I'm trying to get *away* > from Windows. How do I talk to my switch over the serial port? > > Thanks, > Lee > > -- *Paul Duncan* Lead Marine Technician, RV Falkor(too) SCHMIDT OCEAN INSTITUTE mobile +1 650 387 4151 VOIP +1 954 672 4943 www.schmidtocean.org Follow us on Twitter, Facebook and Google+ *This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged* *information. Any unauthorized review, use, disclosure or distribution is prohibited. If you have received it in* *error, please advise the sender by reply email and delete the message and any attachments. Thank you.*
Re: usb => serial port converter
On Mon, Jul 8, 2024 at 11:56 AM Lee wrote:
>
> On Sun, Jul 7, 2024 at 8:51 PM Andy Smith wrote:
> >
> > On Sun, Jul 07, 2024 at 06:02:18PM -0400, Lee wrote:
> > > I tried plugging the dongle into my debian laptop but it didn't
> > > recognize it :(
> >
> > In my experience USB serial gadgets on Linux tend to just work or
> > will never work.
>
> It worked this time!
> Other than plugging it into a windows machine that had the proper
> drivers first, I don't know what changed.
>
> > > And what program are you using to talk to something over the serial
> > > link? pterm or something else?
> >
> > I use either minicom or GNU Screen. You'll need to know the baud
> > rate that the device expects, though you can just try a few common
> > ones and see what works. e.g.
> >
> > # screen /dev/ttyUSB0 115200
>
> Great! I had to add myself to the dialout group to be able to talk to
> the device, but
> screen /dev/ttyUSB0 38400
> works.
You should also add TIOCEXCL on the file descriptor to ensure
exclusive access to the device. Otherwise, other programs will try to
open the modem and probe it by sending commands to it. It will screw
up your reads on the fd.
/* NetworkManager and ModemManager will try to open our device */
/* on occasion. Set TIOCEXCL to ensure we get exclusive access */
if (ioctl(fd, TIOCEXCL, NULL) == -1) {
log_warn("Failed to set TIOCEXCL on device: %s\n", strerror(errno));
}
Jeff
Re: usb => serial port converter
On Sun, Jul 7, 2024 at 8:51 PM Andy Smith wrote: > > Hi, > > On Sun, Jul 07, 2024 at 06:02:18PM -0400, Lee wrote: > > I tried plugging the dongle into my debian laptop but it didn't > > recognize it :( > > In my experience USB serial gadgets on Linux tend to just work or > will never work. It worked this time! Other than plugging it into a windows machine that had the proper drivers first, I don't know what changed. > > And what program are you using to talk to something over the serial > > link? pterm or something else? > > I use either minicom or GNU Screen. You'll need to know the baud > rate that the device expects, though you can just try a few common > ones and see what works. e.g. > > # screen /dev/ttyUSB0 115200 Great! I had to add myself to the dialout group to be able to talk to the device, but screen /dev/ttyUSB0 38400 works. Thanks Lee
Re: usb => serial port converter
On Sun, Jul 07, 2024 at 06:02:18PM -0400, Lee wrote: > What's everybody using for a usb => serial port converter? > > I got a new network switch and .. OhNoes!! how to I talk to the darn thing??? Most of them work with Linux anyway (some of them with some limitations). Stick it in and look at the logs. Usually there is a device /dev/ttyUSBxxx. That one is your friend. > I went looking thru cabinets and came up with a keyspan usb -> serial > dongle; a quick search found the site with driver downloads, but they > all were for Windows or MacOS. Ah, the privileges of proprietary software :-) You not only get to pay, but you get to put more dubious software into your box. > I tried plugging the dongle into my > debian laptop but it didn't recognize it :( What does "lsusb" say? What does "dmesg | tail" say shortly after you inserted your dongle? Cheers -- t signature.asc Description: PGP signature
Re: usb => serial port converter
Hi, On Sun, Jul 07, 2024 at 06:02:18PM -0400, Lee wrote: > I tried plugging the dongle into my debian laptop but it didn't > recognize it :( In my experience USB serial gadgets on Linux tend to just work or will never work. The default Debian kernels do have USB serial converter support enabled and all the drivers as modules. You'll probably find it a better use of your time to just buy one that is known to work, as they are quite cheap. > So... what are people using to talk to serial devices now that PCs > don't come with serial ports anymore? Here are some notes from FreeBSD, which is a bit pickier than Linux on this, so should be conservative advice: https://wiki.freebsd.org/USB/Peripherals/Serial > And what program are you using to talk to something over the serial > link? pterm or something else? I use either minicom or GNU Screen. You'll need to know the baud rate that the device expects, though you can just try a few common ones and see what works. e.g. # screen /dev/ttyUSB0 115200 Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: usb => serial port converter
On Sun, 7 Jul 2024, Lee wrote: > What's everybody using for a usb => serial port converter? > > I got a new network switch and .. OhNoes!! how to I talk to the darn thing??? > > I went looking thru cabinets and came up with a keyspan usb -> serial > dongle; a quick search found the site with driver downloads, but they > all were for Windows or MacOS. I tried plugging the dongle into my > debian laptop but it didn't recognize it :( > > So... what are people using to talk to serial devices now that PCs > don't come with serial ports anymore? > > And what program are you using to talk to something over the serial > link? pterm or something else? > > I still have a Windows machine, so install the drivers, configure > putty to talk to COM4 & I'm good to go. But I'm trying to get *away* > from Windows. How do I talk to my switch over the serial port? > > Thanks, > Lee > i've used this for many years Bus 001 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 Serial (UART) IC bcdDevice6.00 iManufacturer 1 FTDI iProduct2 UC232R iSerial 3 FTF588Y9
Re: usb => serial port converter
On 7/7/24 18:02, Lee wrote: What's everybody using for a usb => serial port converter? I got a new network switch and .. OhNoes!! how to I talk to the darn thing??? I went looking thru cabinets and came up with a keyspan usb -> serial dongle; a quick search found the site with driver downloads, but they all were for Windows or MacOS. I tried plugging the dongle into my debian laptop but it didn't recognize it :( So... what are people using to talk to serial devices now that PCs don't come with serial ports anymore? And what program are you using to talk to something over the serial link? pterm or something else? I still have a Windows machine, so install the drivers, configure putty to talk to COM4 & I'm good to go. But I'm trying to get *away* from Windows. How do I talk to my switch over the serial port? See if you can find a usb-232 from FDTI. And keep looking if you see a Prolific, its not very good. Thanks, Lee . Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
usb => serial port converter
What's everybody using for a usb => serial port converter? I got a new network switch and .. OhNoes!! how to I talk to the darn thing??? I went looking thru cabinets and came up with a keyspan usb -> serial dongle; a quick search found the site with driver downloads, but they all were for Windows or MacOS. I tried plugging the dongle into my debian laptop but it didn't recognize it :( So... what are people using to talk to serial devices now that PCs don't come with serial ports anymore? And what program are you using to talk to something over the serial link? pterm or something else? I still have a Windows machine, so install the drivers, configure putty to talk to COM4 & I'm good to go. But I'm trying to get *away* from Windows. How do I talk to my switch over the serial port? Thanks, Lee
Documentation improvement (optical and USB install media)
Nobody is advocating removing the optical disk media options. There are no plans to do so, that I am aware of. Planning to do so would not make sense, since the current build process happily produces images suitable for both optical disks and USB filesystem devices. All the discussion has been about documentation changes, to make it more clear how to use the existing images. -dsr-
Yet another lick at Gmail and Google [was: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick]
On Tue, Apr 16, 2024 at 01:39:34PM -, Curt wrote: [...] > It would've been clearer to have advised using another mail application, > period [...] > But no harm, no foul, and all is well. The only real mystery is how > Tomas resisted getting yet another lick in against Gmail and Google, et > al. Because it'd been off-topic, just as your little oblique stab here is ;-D Cheers -- t signature.asc Description: PGP signature
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-16, John Crawley wrote: > > If you do not trust Gmail as a web application, use a mail application > that supports IMAP. > Gmail supports IMAP since more or less forever. >>> >>> AIUI the OP's problem was not when reading mail, but with mail >>> submission of attachments. >> >> And in what way does that affect a true statement and a phraseology that >> clearly implies an nonexistent incompatibility? > > Loosen the interpretation of Max Nikulin's statement slightly: > "If you do not trust Gmail as a web application, use any mail application > that supports IMAP" > and it makes sense. > I've just loosened it.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-16, Max Nikulin wrote: > > If you do not trust Gmail as a web application, use a mail application > that supports IMAP. Gmail supports IMAP since more or less forever. >>> >>> AIUI the OP's problem was not when reading mail, but with mail >>> submission of attachments. >> >> And in what way does that affect a true statement and a phraseology that >> clearly implies an nonexistent incompatibility? > > I am completely lost. Mail messages (with attachments) may be submitted It would've been clearer to have advised using another mail application, period, if the OP didn't trust Gmail. But the manner in which you phrased your advice implied that Gmail was a "web application" that didn't support IMAP, which is false, so I piped up (or is it in?) in my admittedly somewhat oblique (to the matter at hand) manner. But no harm, no foul, and all is well. The only real mystery is how Tomas resisted getting yet another lick in against Gmail and Google, et al. --
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Mon 15 Apr 2024 at 18:52:33 (-), Curt wrote: > On 2024-04-15, David Wright wrote: > > On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: > >> On 2024-04-04, Max Nikulin wrote: > >> > > >> > If you do not trust Gmail as a web application, use a mail application > >> > that supports IMAP. > >> > > >> > >> Gmail supports IMAP since more or less forever. > > > > AIUI the OP's problem was not when reading mail, but with mail > > submission of attachments. > > And in what way does that affect a true statement and a phraseology that > clearly implies an nonexistent incompatibility? It doesn't, and wasn't intended to. The OP was worried about security of the attachment process during mail submission. IMAP is not involved. I'm told that gmail offers an SMTP interface, but I don't know how well it works, or its pros and cons. That's why I wrote "the OP's problem was … with mail submission …", in case that had got forgotten with the thread drifting across to the topic of reading emails. Clearer? Cheers, David.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 16/04/2024 01:52, Curt wrote: On 2024-04-15, David Wright wrote: On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: On 2024-04-04, Max Nikulin wrote: If you do not trust Gmail as a web application, use a mail application that supports IMAP. Gmail supports IMAP since more or less forever. AIUI the OP's problem was not when reading mail, but with mail submission of attachments. And in what way does that affect a true statement and a phraseology that clearly implies an nonexistent incompatibility? I am completely lost. Mail messages (with attachments) may be submitted to gmail using SMTP. Certainly it is possible to use different applications to read and to send mails, but by default I assume that users seek for a complete solution. I had a hope that my suggestion to use some mail user agent that support IMAP was clear enough. I expect that most of them (at least wide spread) support submission of mail as well. Use code you trust and protocols having specifications available. I admit that some users have troubles with OAuth2 authentication in various MUAs or with enabling application-specific passwords for their google account.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 16/04/2024 03:52, Curt wrote: On 2024-04-15, David Wright wrote: On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: On 2024-04-04, Max Nikulin wrote: If you do not trust Gmail as a web application, use a mail application that supports IMAP. Gmail supports IMAP since more or less forever. AIUI the OP's problem was not when reading mail, but with mail submission of attachments. And in what way does that affect a true statement and a phraseology that clearly implies an nonexistent incompatibility? Loosen the interpretation of Max Nikulin's statement slightly: "If you do not trust Gmail as a web application, use any mail application that supports IMAP" and it makes sense. -- John
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-15, David Wright wrote: > On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: >> On 2024-04-04, Max Nikulin wrote: >> > >> > If you do not trust Gmail as a web application, use a mail application >> > that supports IMAP. >> > >> >> Gmail supports IMAP since more or less forever. > > AIUI the OP's problem was not when reading mail, but with mail > submission of attachments. And in what way does that affect a true statement and a phraseology that clearly implies an nonexistent incompatibility? > Cheers, > David. > > --
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: > On 2024-04-04, Max Nikulin wrote: > > > > If you do not trust Gmail as a web application, use a mail application > > that supports IMAP. > > > > Gmail supports IMAP since more or less forever. AIUI the OP's problem was not when reading mail, but with mail submission of attachments. Cheers, David.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-04, Max Nikulin wrote: > > If you do not trust Gmail as a web application, use a mail application > that supports IMAP. > Gmail supports IMAP since more or less forever.
Re: Identificación de dispositivos USB
El 12/4/24 a las 17:54, Sergio Daniel Gomez escribió: Buenas, gente de esta linda lista. Les consulto un tema a resolver... Tengo que captura video de hdmi de dos dispositivos simultáneamente, para esto compré una segunda capuradora hdmi con la única diferencia que una es USB2.0 y la nueva USB3.0... El problema es que se mezclan las señales y lo que se captura en una, se ve en la otra, es decir... mplayer -tv:///dev/video0 muesta lo mismo que mplayer -tv:///dev/video2, siendo distintos usb. dmesg muesta esto: [ 4.544037] usb 1-2: New USB device found, idVendor=534d, idProduct=2109, bcdDevice=21.00 [ 917.970275] usb 1-9: New USB device found, idVendor=534d, idProduct=2109, bcdDevice=21.00 Insisto, la única diferencia es que una una es USB2.0 y la nueva USB3.0... Alguien tiene idea de cómo solucionar esto o alguna sugerencia? Gracias, gracias, gracias. Sergio Bueno, parece que el problema es mplayer y vlc, recordé que en época de covid-19 hice un streaming con dos capturdoras usb2.0 utilizando obs-studio, que no me sirve para lo que necesito ahora, así que probé con ffplay y funcionó correctamente Saludos. Sergio
Identificación de dispositivos USB
Buenas, gente de esta linda lista. Les consulto un tema a resolver... Tengo que captura video de hdmi de dos dispositivos simultáneamente, para esto compré una segunda capuradora hdmi con la única diferencia que una es USB2.0 y la nueva USB3.0... El problema es que se mezclan las señales y lo que se captura en una, se ve en la otra, es decir... mplayer -tv:///dev/video0 muesta lo mismo que mplayer -tv:///dev/video2, siendo distintos usb. dmesg muesta esto: [ 4.544037] usb 1-2: New USB device found, idVendor=534d, idProduct=2109, bcdDevice=21.00 [ 917.970275] usb 1-9: New USB device found, idVendor=534d, idProduct=2109, bcdDevice=21.00 Insisto, la única diferencia es que una una es USB2.0 y la nueva USB3.0... Alguien tiene idea de cómo solucionar esto o alguna sugerencia? Gracias, gracias, gracias. Sergio
Re: problem with live usb booting
On 4/11/24 10:14, Greg Wooledge wrote: On Thu, Apr 11, 2024 at 01:30:46PM +, sarath wrote: dear debian I have created live usb with debian-live-12.5.0-amd64-standard.iso using tool Ventoy-1.0.95. When tried to booting it is ended with command line options. please help me to the next step It's not clear to me what you mean. Was there an *error* message? If so, what does it say? If you simply mean "I expected a graphical interface, and instead I got a text console login prompt", that's because you used the -standard image which has a minimalist set of packages, equivalent to what you would get if you installed Debian normally, and un-selected the desktop environment option, and only left "Standard" selected. If you want a graphical interface, you'll need a different image. I agree with Greg - I use Ventoy/debian-live-12.2.0-amd64-xfce.iso and it works just fine in the xfce graphical interface. Use the desktop you prefer as part of the debian live iso for a graphical install.
Re: problem with live usb booting
On Thu, Apr 11, 2024 at 01:30:46PM +, sarath wrote: > dear debian > > I have created live usb with debian-live-12.5.0-amd64-standard.iso using tool > Ventoy-1.0.95. When tried to booting it is ended with command line options. > please help me to the next step It's not clear to me what you mean. Was there an *error* message? If so, what does it say? If you simply mean "I expected a graphical interface, and instead I got a text console login prompt", that's because you used the -standard image which has a minimalist set of packages, equivalent to what you would get if you installed Debian normally, and un-selected the desktop environment option, and only left "Standard" selected. If you want a graphical interface, you'll need a different image.
problem with live usb booting
dear debian I have created live usb with debian-live-12.5.0-amd64-standard.iso using tool Ventoy-1.0.95. When tried to booting it is ended with command line options. please help me to the next step thanks regards Sarathdc Sent with [Proton Mail](https://proton.me/) secure email.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 31/03/2024 22:35, David Wright wrote: On Sun 31 Mar 2024 at 09:42:37 (+0300), Antti-Pekka Känsälä wrote: But I'm worried my Gmail in Firefox is capable of stealing files off my USB stick. I've no answer for that, particularly in view of Max's reply to my previous post. I've always copied files to and from USB sticks, floppy disks, CDs, etc), using the hard disk as a staging area. I think, it is a reasonable approach when combined with other measures. Frankly speaking, I am not convinced that there is something weird with Gmail and Firefox. If you do not trust Gmail as a web application, use a mail application that supports IMAP. Isolate applications you do not trust and do not expose your private files to them. There is a number of possibilities, but neither is perfect: - multiple system users and file permissions combined with ACLs - virtual machines - mount, user and other namespaces, e.g. the following options - containers - tools like firejail and bubblewrap - flatpak and snap (designed for some kind of isolation, but I am unsure if it may be configured to specific needs) Mount a USB drive to a trusted environment and copy specific files to a location available to a suspicious application.
Re: Debian ISOs on USB stick
On 4/3/24 05:56, Thomas Schmitt wrote: Hi, i read from bytes 2085412 to 2085479: "Info rrmation Syste rm VolumeSYSTEM~" which is similar to the alterations of one of the USB sticks shown in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998#35 The web knows about a Microsoft folder named "System Volume Information". https://answers.microsoft.com/en-us/windows/forum/all/system-volume-information-what-is-it-and-what-is/3bc81844-0baa-46bd-9949-4efb4678b677 "whenever I put my flash-drive or my micro sd adapter and sd card into my windows 8.1 something called "System Volume Information" is always getting added on." So did you perhaps show this USB stick to a running MS-Windows system ? Have a nice day :) Thomas It is possible the drive was inserted into a Windows computer. If and when I need a newer d-i, perhaps I will put the ISO onto a USB flash drive, conduct more experiments, and post the results. I apologize for blaming d-i for what might be Dell, Intel, BIOS/UEFI, Microsoft, and/or other bugs. David
Re: Debian ISOs on USB stick
Hi, i read from bytes 2085412 to 2085479: "Info rrmation Syste rm VolumeSYSTEM~" which is similar to the alterations of one of the USB sticks shown in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998#35 The web knows about a Microsoft folder named "System Volume Information". https://answers.microsoft.com/en-us/windows/forum/all/system-volume-information-what-is-it-and-what-is/3bc81844-0baa-46bd-9949-4efb4678b677 "whenever I put my flash-drive or my micro sd adapter and sd card into my windows 8.1 something called "System Volume Information" is always getting added on." So did you perhaps show this USB stick to a running MS-Windows system ? Have a nice day :) Thomas
Re: Debian ISOs on USB stick
Hi, David Christensen wrote: > # cmp --verbose debian-11.3.0-amd64-netinst.iso /dev/sdb I got my copy from https://get.debian.org/images/archive/11.3.0/amd64/iso-cd/debian-11.3.0-amd64-netinst.iso SHA256 matches: 7892981e1da216e79fb3a1536ce5ebab157afdd20048fe458f2ae34fbc26c19b In a further mail: > https://cdimage.debian.org/cdimage/archive/11.3.0/amd64/iso-cd/ Same SHA256 there. > 2083201 0 377 Byte counting of cmp is decimal and starts at 1. xorriso can search for files which have their data in a block range. 2083201 / 2048 = block 1017. Range size in this case is just 1 block: $ xorriso -indev debian-11.3.0-amd64-netinst.iso -find / -lba_range 1017 1 -exec report_lba -- ... Report layout: xt , Startlba , Blocks , Filesize , ISO image path File data lba: 0 , 1016 , 1296 , 2654208 , '/boot/grub/efi.img' So it's indeed occupied by the FAT filesystem image which contains the EFI-specific boot equipment. > 4719105 0 56 Byte 4719105 is in block 2304, i.e. still in /boot/grub/efi.img, which has bytes up to the end of block 2311. I guess the bytes with the 2xx numbers are the directory change and the 4xx numbers are content of new files. You could mount both ISOs (e.g. at /mnt/iso1 and /mnt/iso2) and then the two FAT image files (e.g. /mnt/iso1/boot/grub/efi.img and /mnt/iso2/boot/grub/efi.img) in order to learn which files have emerged or changed in the USB stick's mounted FAT filesystem. Maybe we find a new ESP groper additionaly to Lenovo and Microsoft. Usually they leave traces for which one can search in the web. Have a nice day :) Thomas
Re: Debian ISOs on USB stick, was: SOLVED
On 4/3/24 03:36, David Christensen wrote: On 4/3/24 00:30, Thomas Schmitt wrote: Hi, David Christensen wrote: It's a relatively simple experiment to confirm that a USB flash drive with d-i changes after the first boot. This could still be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998 where Lenovo BIOS and/or MS-Windows altered the USB stick. Same for finding which bytes change. I fail to find this particular info in Date: Tue, 2 Apr 2024 14:46:42 -0700 From: David Christensen Message-ID: If we have the exact ISO name (i.e. URL from where it stems) and the byte address of the alteration, xorriso can find the affected file, if any. In case of bug #1056998 it was the EFI partition image /boot/grub/efi.img. Mounting the altered and unaltered image files showed changes in the FAT filesystem which point to the culprits Lenovo and Microsoft. The other plausible way of altering the ISO image on the stick would be adding a new partition. The MBR partition table is part of the Debian ISO and thus part of the checksummed area. Even if all other alterations happen after the end of the checksummed ISO image, the changed partition table will cause the Debian checksum to become invalid. (I am not aware that Debian installer changes the table. If it does indeed then this might be worth a new bug discussion.) Have a nice day :) Thomas 2024-04-03 03:29:18 root@laalaa /samba/dpchrist/iso/debian/11.3.0 # cmp --verbose debian-11.3.0-amd64-netinst.iso /dev/sdb 2083201 0 377 2083202 0 377 2083203 0 377 2085249 0 377 2085250 0 377 2085251 0 377 2085409 0 102 2085410 0 40 2085412 0 111 2085414 0 156 2085416 0 146 2085418 0 157 2085420 0 17 2085422 0 162 2085423 0 162 2085425 0 155 2085427 0 141 2085429 0 164 2085431 0 151 2085433 0 157 2085437 0 156 2085441 0 1 2085442 0 123 2085444 0 171 2085446 0 163 2085448 0 164 2085450 0 145 2085452 0 17 2085454 0 162 2085455 0 155 2085457 0 40 2085459 0 126 2085461 0 157 2085463 0 154 2085465 0 165 2085469 0 155 2085471 0 145 2085473 0 123 2085474 0 131 2085475 0 123 2085476 0 124 2085477 0 105 2085478 0 115 2085479 0 176 2085480 0 61 2085481 0 40 2085482 0 40 2085483 0 40 2085484 0 26 2085486 0 167 2085487 0 174 2085488 0 277 2085489 0 235 2085490 0 124 2085491 0 235 2085492 0 124 2085495 0 175 2085496 0 277 2085497 0 235 2085498 0 124 2085500 0 5 4719105 0 56 4719106 0 40 4719107 0 40 4719108 0 40 4719109 0 40 4719110 0 40 4719111 0 40 4719112 0 40 4719113 0 40 4719114 0 40 4719115 0 40 4719116 0 20 4719118 0 167 4719119 0 174 4719120 0 277 4719121 0 235 4719122 0 124 4719123 0 235 4719124 0 124 4719127 0 175 4719128 0 277 4719129 0 235 4719130 0 124 4719132 0 5 4719137 0 56 4719138 0 56 4719139 0 40 4719140 0 40 4719141 0 40 4719142 0 40 4719143 0 40 4719144 0 40 4719145 0 40 4719146 0 40 4719147 0 40 4719148 0 20 4719150 0 167 4719151 0 174 4719152 0 277 4719153 0 235 4719154 0 124 4719155 0 235 4719156 0 124 4719159 0 175 4719160 0 277 4719161 0 235 4719162 0 124 4719169 0 102 4719170 0 107 4719172 0 165 4719174 0 151 4719176 0 144 4719180 0 17 4719182 0 377 4719183 0 377 4719184 0 377 4719185 0 377 4719186 0 377 4719187 0 377 4719188 0 377 4719189 0 377 4719190 0 377 4719191 0 377 4719192 0 377 4719193 0 377 4719194 0 377 4719197 0 377 4719198 0 377 4719199 0 377 4719200 0 377 4719201 0 1 4719202 0 111 4719204 0 156 4719206 0 144 4719208 0 145 4719210 0 170 4719212 0 17 4719214 0 377 4719215 0 145 4719217 0 162 4719219 0 126 4719221 0 157 4719223 0 154 4719225 0 165 4719229 0 155 4719231 0 145 4719233 0 111 4719234 0 116 4719235 0 104 4719236 0 105 4719237 0 130 4719238 0 105 4719239 0 176 4719240 0 61 4719241 0 40 4719242 0 40 4719243 0 40 4719244 0 40 4719246 0 171 4719247 0 174 4719248 0 277 4719249 0 235 4719250 0 124 4719251 0 235 4719252 0 124 4719255 0 175 4719256 0 277 4719257 0 235 4719258 0 124 4719259 0 1 4719260 0 5 4719261 0 114 4721153 0 173 4721155 0 71 4721157 0 101 4721159 0 65 4721161 0 104 4721163 0 101 4721165 0 106 4721167 0 65 4721169 0 67 4721171 0 55
Re: Debian ISOs on USB stick, was: SOLVED
On 4/3/24 00:30, Thomas Schmitt wrote: Hi, David Christensen wrote: It's a relatively simple experiment to confirm that a USB flash drive with d-i changes after the first boot. This could still be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998 where Lenovo BIOS and/or MS-Windows altered the USB stick. Same for finding which bytes change. I fail to find this particular info in Date: Tue, 2 Apr 2024 14:46:42 -0700 From: David Christensen Message-ID: If we have the exact ISO name (i.e. URL from where it stems) and the byte address of the alteration, xorriso can find the affected file, if any. In case of bug #1056998 it was the EFI partition image /boot/grub/efi.img. Mounting the altered and unaltered image files showed changes in the FAT filesystem which point to the culprits Lenovo and Microsoft. The other plausible way of altering the ISO image on the stick would be adding a new partition. The MBR partition table is part of the Debian ISO and thus part of the checksummed area. Even if all other alterations happen after the end of the checksummed ISO image, the changed partition table will cause the Debian checksum to become invalid. (I am not aware that Debian installer changes the table. If it does indeed then this might be worth a new bug discussion.) Have a nice day :) Thomas 2024-04-03 03:29:18 root@laalaa /samba/dpchrist/iso/debian/11.3.0 # cmp --verbose debian-11.3.0-amd64-netinst.iso /dev/sdb 2083201 0 377 2083202 0 377 2083203 0 377 2085249 0 377 2085250 0 377 2085251 0 377 2085409 0 102 2085410 0 40 2085412 0 111 2085414 0 156 2085416 0 146 2085418 0 157 2085420 0 17 2085422 0 162 2085423 0 162 2085425 0 155 2085427 0 141 2085429 0 164 2085431 0 151 2085433 0 157 2085437 0 156 2085441 0 1 2085442 0 123 2085444 0 171 2085446 0 163 2085448 0 164 2085450 0 145 2085452 0 17 2085454 0 162 2085455 0 155 2085457 0 40 2085459 0 126 2085461 0 157 2085463 0 154 2085465 0 165 2085469 0 155 2085471 0 145 2085473 0 123 2085474 0 131 2085475 0 123 2085476 0 124 2085477 0 105 2085478 0 115 2085479 0 176 2085480 0 61 2085481 0 40 2085482 0 40 2085483 0 40 2085484 0 26 2085486 0 167 2085487 0 174 2085488 0 277 2085489 0 235 2085490 0 124 2085491 0 235 2085492 0 124 2085495 0 175 2085496 0 277 2085497 0 235 2085498 0 124 2085500 0 5 4719105 0 56 4719106 0 40 4719107 0 40 4719108 0 40 4719109 0 40 4719110 0 40 4719111 0 40 4719112 0 40 4719113 0 40 4719114 0 40 4719115 0 40 4719116 0 20 4719118 0 167 4719119 0 174 4719120 0 277 4719121 0 235 4719122 0 124 4719123 0 235 4719124 0 124 4719127 0 175 4719128 0 277 4719129 0 235 4719130 0 124 4719132 0 5 4719137 0 56 4719138 0 56 4719139 0 40 4719140 0 40 4719141 0 40 4719142 0 40 4719143 0 40 4719144 0 40 4719145 0 40 4719146 0 40 4719147 0 40 4719148 0 20 4719150 0 167 4719151 0 174 4719152 0 277 4719153 0 235 4719154 0 124 4719155 0 235 4719156 0 124 4719159 0 175 4719160 0 277 4719161 0 235 4719162 0 124 4719169 0 102 4719170 0 107 4719172 0 165 4719174 0 151 4719176 0 144 4719180 0 17 4719182 0 377 4719183 0 377 4719184 0 377 4719185 0 377 4719186 0 377 4719187 0 377 4719188 0 377 4719189 0 377 4719190 0 377 4719191 0 377 4719192 0 377 4719193 0 377 4719194 0 377 4719197 0 377 4719198 0 377 4719199 0 377 4719200 0 377 4719201 0 1 4719202 0 111 4719204 0 156 4719206 0 144 4719208 0 145 4719210 0 170 4719212 0 17 4719214 0 377 4719215 0 145 4719217 0 162 4719219 0 126 4719221 0 157 4719223 0 154 4719225 0 165 4719229 0 155 4719231 0 145 4719233 0 111 4719234 0 116 4719235 0 104 4719236 0 105 4719237 0 130 4719238 0 105 4719239 0 176 4719240 0 61 4719241 0 40 4719242 0 40 4719243 0 40 4719244 0 40 4719246 0 171 4719247 0 174 4719248 0 277 4719249 0 235 4719250 0 124 4719251 0 235 4719252 0 124 4719255 0 175 4719256 0 277 4719257 0 235 4719258 0 124 4719259 0 1 4719260 0 5 4719261 0 114 4721153 0 173 4721155 0 71 4721157 0 101 4721159 0 65 4721161 0 104 4721163 0 101 4721165 0 106 4721167 0 65 4721169 0 67 4721171 0 55 4721173 0 71 4721175 0 102 4721177 0 63 4721179 0 61 4721181 0 55 4721183 0 64 4721185 0 71 4721187 0 62 4721189 0 105 4721191 0 55 4721193 0 102 4721195 0 66 4721197 0 105
Debian ISOs on USB stick, was: SOLVED
Hi, David Christensen wrote: > It's a relatively simple experiment to confirm that a USB flash drive with > d-i changes after the first boot. This could still be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998 where Lenovo BIOS and/or MS-Windows altered the USB stick. > Same for finding which bytes change. I fail to find this particular info in Date: Tue, 2 Apr 2024 14:46:42 -0700 From: David Christensen Message-ID: If we have the exact ISO name (i.e. URL from where it stems) and the byte address of the alteration, xorriso can find the affected file, if any. In case of bug #1056998 it was the EFI partition image /boot/grub/efi.img. Mounting the altered and unaltered image files showed changes in the FAT filesystem which point to the culprits Lenovo and Microsoft. The other plausible way of altering the ISO image on the stick would be adding a new partition. The MBR partition table is part of the Debian ISO and thus part of the checksummed area. Even if all other alterations happen after the end of the checksummed ISO image, the changed partition table will cause the Debian checksum to become invalid. (I am not aware that Debian installer changes the table. If it does indeed then this might be worth a new bug discussion.) Have a nice day :) Thomas
Re: Debian ISOs on USB stick, was: SOLVED
On 4/2/24 08:56, Thomas Schmitt wrote: Hi, David Christensen wrote: the Debian installer modifies the contents of the USB flash drive when it runs. Do you mean inside the range of the ISO image or outside by creating a new partition ? songbird wrote: if it is an iso image copied to the USB stick it should not be modified if you haven't somehow told the installer to install the system to that USB stick (somehow). There are other parties which feel entitled to operate on the EFI System Partition of a USB stick. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998 we found that Lenovo Thinkpad firmware created directories for storing an empty file named "/efi/Lenovo/BIOS/SelfHealing.fd" and that MS-Windows created a 12-byte file named "/System Volume Information/WPSettings.dat" when it had contact with the USB stick. i guess if you wanted to be really sure you could mount it read-only. I think it's the installer which mounts the ISO 9660 filesystem. Whatever, the Linux kernel has no regular means to alter an ISO 9660 filesystem. Neither kernel nor Debain installer will be so daring to operate with byte level commands on that filesystem. But the FAT filesystem in file /boot/grub/efi.img of the ISO 9660 filesystem in debian-12.*-amd64-netinst.iso is advertised by the partition table of the image and thus attracts vermin. Have a nice day :) Thomas Please see my reply to songbird. It's a relatively simple experiment to confirm that a USB flash drive with d-i changes after the first boot. Same for finding which bytes change. The challenge is figuring out what performed the change(s) and why. I assumed it was d-i, but no longer own 64-bit BIOS-only computers to confirm. David
Debian ISOs on USB stick, was: SOLVED
Hi, David Christensen wrote: > > the Debian installer modifies the contents of the USB flash drive when > > it runs. Do you mean inside the range of the ISO image or outside by creating a new partition ? songbird wrote: > if it is an iso image copied to the USB stick it should not > be modified if you haven't somehow told the installer to > install the system to that USB stick (somehow). There are other parties which feel entitled to operate on the EFI System Partition of a USB stick. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998 we found that Lenovo Thinkpad firmware created directories for storing an empty file named "/efi/Lenovo/BIOS/SelfHealing.fd" and that MS-Windows created a 12-byte file named "/System Volume Information/WPSettings.dat" when it had contact with the USB stick. > i guess if you wanted to be really sure you could mount it read-only. I think it's the installer which mounts the ISO 9660 filesystem. Whatever, the Linux kernel has no regular means to alter an ISO 9660 filesystem. Neither kernel nor Debain installer will be so daring to operate with byte level commands on that filesystem. But the FAT filesystem in file /boot/grub/efi.img of the ISO 9660 filesystem in debian-12.*-amd64-netinst.iso is advertised by the partition table of the image and thus attracts vermin. Have a nice day :) Thomas
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I filed bug report 1068122. I feel fine, despite my concern over my data. Heartfelt thanks for all the advice!
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sun 31 Mar 2024 at 09:42:37 (+0300), Antti-Pekka Känsälä wrote: > I'm mounting and unmounting through the stick icon's menu on Xfce desktop. > Maybe a fancy file chooser dialogue stays around analyzing the directory, > as you suspect? But I'm worried my Gmail in Firefox is capable of stealing > files off my USB stick. I've no answer for that, particularly in view of Max's reply to my previous post. I've always copied files to and from USB sticks, floppy disks, CDs, etc), using the hard disk as a staging area. That habit developed thirty years ago on account of (other's) experience with Windows, and the "stickiness" of its file choosers. This could lead to problems when you attempted to renavigate to files, but hadn't got the same devices plugged in as previously. That's not much help to you because by doing that, you'd merely be exposing your hard drive instead for analysis, to Firefox, or worse, possibly to Gmail. I run two instances of Firefox as a matter of course. One user's instance is used for banking and other administrative tasks. The other user's is for everything else. The latter is unable to read any of the former's files. (Some people use different machines to the same end.) Cheers, David.
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I'm mounting and unmounting through the stick icon's menu on Xfce desktop. Maybe a fancy file chooser dialogue stays around analyzing the directory, as you suspect? But I'm worried my Gmail in Firefox is capable of stealing files off my USB stick.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 31/03/2024 11:46, David Wright wrote: Double-clicking on the directory mounts it and displays the files in it. Opening a text file displays it. At least for a small file, FF does not hold the file open, so I can immediately unmount the stick. Gmail may do something more fancy - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file - https://developer.mozilla.org/en-US/docs/Web/API/File_System_API I am not surprised that the device is busy for some interval of time.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sat 30 Mar 2024 at 21:06:27 (+0200), Antti-Pekka Känsälä wrote: > I was able to replicate this, by trying to send gmail to myself in Firefox, > attaching a binary on a mounted USB stick. Did you mount the stick yourself as a user (ie there's an fstab entry for it), or as root, or does an automounter mount it for you? > After the attachment supposedly > was uploaded, I tried to unmount the stick, but it blocks. "lsof | grep -i > KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted > for about a minute, then the drive unmounted by itself. This is the behaviour I see, where (1) inserting a stick creates a mountpoint and (2) that mountpoint is referenced in /etc/fstab: After typing Ctrl-O in Firefox, I navigate to /media/foo (the mountpoint that was created). Double-clicking on the directory mounts it and displays the files in it. Opening a text file displays it. At least for a small file, FF does not hold the file open, so I can immediately unmount the stick. That may differ if, for example, a mail MUA or MTA is taking a lot of time to process an attached file. So I suspect you may be relying on an automounter to mount the stick, and you have to wait for a period of inactivity to time out before it decides you've probably finished with it. Cheers, David.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 3/30/24 08:17, Antti-Pekka Känsälä wrote: What could be the deal, when Firefox tries to stop me from unmounting a stick, after I've accessed files on it through Firefox? I worry about my stick security. Thanks. Linux knows what files are open on each file system. If you try to unmount a file system with open files or eject a mounted USB drive with open files, Linux will refuse and your desktop environment will display a suitable error dialog. This is a feature, not a bug. The solution is to close all the files on the file system, and then unmount it. David
Re: Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I'd just like to add that I have seen the problem despite reinstalls with Debian stable minor versions. Thanks!
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sat, Mar 30, 2024 at 07:32:16PM +0200, Antti-Pekka Känsälä wrote:
> Yes, closing Firefox does allow the stick to unmount cleanly, but I still
> worry.
To get an idea of what's going on, you can use "lsof":
tomas@trotzki:~$ lsof /dev/sda1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash3982 tomas cwdDIR8,1 40962 /boot
hexdump 4056 tomas0r REG8,1 33464584 28
/boot/initrd.img-5.10.0-26-amd64
hexdump 4074 tomas0r REG8,1 7044672 27
/boot/vmlinuz-5.10.0-26-amd64
There are three processes accessing my /dev/sda1 ("aka" /boot). I put
them there to have something to show :-)
Cheers
--
t
signature.asc
Description: PGP signature
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I can replicate this, by trying to send Gmail to myself in Firefox, attaching a binary on a mounted USB stick. After the attachment supposedly was uploaded, I tried to unmount the stick, but it blocked. "lsof | grep -i KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted for about a minute, then the drive unmounted by itself.
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I was able to replicate this, by trying to send gmail to myself in Firefox, attaching a binary on a mounted USB stick. After the attachment supposedly was uploaded, I tried to unmount the stick, but it blocks. "lsof | grep -i KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted for about a minute, then the drive unmounted by itself.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sat, 30 Mar 2024 17:17:52 +0200 Antti-Pekka Känsälä wrote: > What could be the deal, when Firefox tries to stop me from unmounting > a stick, after I've accessed files on it through Firefox? I worry > about my stick security. Thanks. It sounds like Firefox has a file open on the stick. To check this, run something like lsof | grep -i offsite where offsite is in the path to the stick. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sat, Mar 30, 2024 at 1:19 PM gene heskett wrote: > > On 3/30/24 11:36, Antti-Pekka Känsälä wrote: > > What could be the deal, when Firefox tries to stop me from unmounting a > > stick, after I've accessed files on it through Firefox? I worry about > > my stick security. Thanks. > > Since this is normally a root operation, I'm confused. Likely what it > means is that you have an open write path from firefox to the stick that > has not been properly closed. I get into a similar state working with > u-sd's using mc to edit something I have used mc to cd to, and forget to > cd back out of the u-sd before I eject the card to take it to its proper > home in a pi clone. Possibly fixed by stopping firefox first? The other thing I try with this is to run something like: $ mount|grep sda2 The "sda2" can be replaced with whatever else is involved. That filters out a hopefully small(er) list to show if something is unusually mounted. Running "mount" alone opens up the whole list. Going that route helped me in chroot a couple days ago. An unbelievable number of /proc, /sys, /dev, and /dev/pts mount points appeared. I only manually mounted them once each. Manually umount'ing each point until none were left fixed whatever trouble that seemed to inflict on apt-get. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
Yes, closing Firefox does allow the stick to unmount cleanly, but I still worry.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 3/30/24 11:36, Antti-Pekka Känsälä wrote: What could be the deal, when Firefox tries to stop me from unmounting a stick, after I've accessed files on it through Firefox? I worry about my stick security. Thanks. Since this is normally a root operation, I'm confused. Likely what it means is that you have an open write path from firefox to the stick that has not been properly closed. I get into a similar state working with u-sd's using mc to edit something I have used mc to cd to, and forget to cd back out of the u-sd before I eject the card to take it to its proper home in a pi clone. Possibly fixed by stopping firefox first? Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
What could be the deal, when Firefox tries to stop me from unmounting a stick, after I've accessed files on it through Firefox? I worry about my stick security. Thanks.
Re: Debugging an USB array issue
On 3/16/24 12:27, Max Nikulin wrote: On 16/03/2024 00:45, Marc SCHAEFER wrote: On Fri, Mar 15, 2024 at 01:30:08PM -0400, Dan Ritter wrote: I have never had long-term happiness with multiple disks connected via USB. However: I have a similar disk array running 24h/24h for the last three years on a Debian buster with no problem. I am going to upgrade this system soon, so if there is something bad with bullseye's kernel I would love to learn about it :) You may search https://bugs.debian.org for known issues. If it is really a software issue rather than a hardware one I would try at least bookworm-backports kernel package. Further steps may be git bisect game with custom builds of vanilla kernel. It would be tedious since 4 hours is required for each iteration. From my point of view some failure of USB to SATA converter is more probable. And if its not a startech, probable. I have several startech's in service for years. And have NOT had to replace any of them. Ignore that faint knocking on wood sound. :o)> Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Debugging an USB array issue
On 16/03/2024 00:45, Marc SCHAEFER wrote: On Fri, Mar 15, 2024 at 01:30:08PM -0400, Dan Ritter wrote: I have never had long-term happiness with multiple disks connected via USB. However: I have a similar disk array running 24h/24h for the last three years on a Debian buster with no problem. I am going to upgrade this system soon, so if there is something bad with bullseye's kernel I would love to learn about it :) You may search https://bugs.debian.org for known issues. If it is really a software issue rather than a hardware one I would try at least bookworm-backports kernel package. Further steps may be git bisect game with custom builds of vanilla kernel. It would be tedious since 4 hours is required for each iteration. From my point of view some failure of USB to SATA converter is more probable.
Re: Debugging an USB array issue
On Fri, Mar 15, 2024 at 08:24:04PM +0100, Marc SCHAEFER wrote: > Hello, > > On Fri, Mar 15, 2024 at 06:54:38PM +0100, to...@tuxteam.de wrote: > > I may be stating the obvious, but have you made sure the USB hub > > is providing enough power to keep your disks happy? > > It's a 60W external power supply, for 4 disks. Thanks, that seems to settle that :-) Cheers -- t signature.asc Description: PGP signature
Re: Debugging an USB array issue
Hello, On Fri, Mar 15, 2024 at 06:54:38PM +0100, to...@tuxteam.de wrote: > I may be stating the obvious, but have you made sure the USB hub > is providing enough power to keep your disks happy? It's a 60W external power supply, for 4 disks.
Re: Debugging an USB array issue
On Fri, Mar 15, 2024 at 05:32:30PM +0100, Marc SCHAEFER wrote: > Hello, > > on a Debian bullseye uptodate system [1], I experiment frequent (every > 3-4 hours on heavy load) disk disconnections from a md RAID10 array with > 4 drives connected to an USB 1M adapter [2]. > > Errors do not look like a timeout, but like a DMA error [3]. I may be stating the obvious, but have you made sure the USB hub is providing enough power to keep your disks happy? Cheers -- t signature.asc Description: PGP signature
Re: Debugging an USB array issue
Marc SCHAEFER wrote: > on a Debian bullseye uptodate system [1], I experiment frequent (every > 3-4 hours on heavy load) disk disconnections from a md RAID10 array with > 4 drives connected to an USB 1M adapter [2]. > > Errors do not look like a timeout, but like a DMA error [3]. > > Immediately after, the disk reappears as a new drive name and can be > re-added quickly to the md RAID array (I am doing those tests with a > read-only mounted filesystem for obvious reasons). > > Initially, I was wondering if it was maybe a disk doing a too long > recovery procedure, but it is to be noted that it's not always the same > disk which has an error, and smartctl -a shows no recorded errors for > any of the 4 drives [4]. The drives are connected to a SATA-to-USB > enclosure [6]. > > This is on a 3.1 USB PCI-Express card [5]. > > I already applied this work-around (which does not seem to apply to a > non-idle system): >echo -1 > /sys/module/usbcore/parameters/autosuspend > > What would be your recommandations? I have thought about downgrading to > a slower port (it should not be much different with 5000M), changing the > cable, or maybe it's the enclosure? I have never had long-term happiness with multiple disks connected via USB. I strongly recommend that you find a 4 or 8 disk SATA/SAS PCIe card -- an LSI 2008, for example -- and connect through that, instead. US prices are $40-45 new. Add $15 for an 8087-to-4xSATA cable, you will have happiness for less than $75. -dsr-
Re: Debugging an USB array issue
Hello, On Fri, Mar 15, 2024 at 01:30:08PM -0400, Dan Ritter wrote: > I have never had long-term happiness with multiple disks > connected via USB. I strongly recommend that you find a 4 or 8 > disk SATA/SAS PCIe card -- an LSI 2008, for example -- and connect > through that, instead. US prices are $40-45 new. Add $15 for an 8087-to-4xSATA > cable, you will have happiness for less than $75. Interesting. I will keep the idea in mind. I also had a prejudice against USB in the beginning. However: I have a similar disk array running 24h/24h for the last three years on a Debian buster with no problem. I am going to upgrade this system soon, so if there is something bad with bullseye's kernel I would love to learn about it :)
Debugging an USB array issue
Hello, on a Debian bullseye uptodate system [1], I experiment frequent (every 3-4 hours on heavy load) disk disconnections from a md RAID10 array with 4 drives connected to an USB 1M adapter [2]. Errors do not look like a timeout, but like a DMA error [3]. Immediately after, the disk reappears as a new drive name and can be re-added quickly to the md RAID array (I am doing those tests with a read-only mounted filesystem for obvious reasons). Initially, I was wondering if it was maybe a disk doing a too long recovery procedure, but it is to be noted that it's not always the same disk which has an error, and smartctl -a shows no recorded errors for any of the 4 drives [4]. The drives are connected to a SATA-to-USB enclosure [6]. This is on a 3.1 USB PCI-Express card [5]. I already applied this work-around (which does not seem to apply to a non-idle system): echo -1 > /sys/module/usbcore/parameters/autosuspend What would be your recommandations? I have thought about downgrading to a slower port (it should not be much different with 5000M), changing the cable, or maybe it's the enclosure? Or is this a known issue (maybe with the xhci_hd driver) and I should try another driver? Thank you for any idea or pointer. [1] Linux video 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 GNU/Linux [2] /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 1M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 1M |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 1M |__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=uas, 1M |__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=uas, 1M |__ Port 4: Dev 10, If 0, Class=Mass Storage, Driver=uas, 1M |__ Port 2: Dev 7, If 0, Class=Mass Storage, Driver=uas, 1M |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M [3] Mar 15 17:08:06 video kernel: [ 6607.383180] xhci_hcd :01:00.0: WARN Set TR Deq Ptr cmd invalid because of stream ID configuration Mar 15 17:08:06 video kernel: [ 6607.386754] DMAR: DRHD: handling fault status reg 3 Mar 15 17:08:06 video kernel: [ 6607.386762] DMAR: [DMA Write] Request device [01:00.0] PASID fault addr f98be000 [fault reason 05] PTE Write access is not set Mar 15 17:08:06 video kernel: [ 6607.386774] sd 18:0:0:0: [sde] tag#5 data cmplt err -75 uas-tag 1 inflight: CMD Mar 15 17:08:06 video kernel: [ 6607.386780] sd 18:0:0:0: [sde] tag#5 CDB: Read(16) 88 00 00 00 00 01 5e 1d 88 00 00 00 01 00 00 00 Mar 15 17:08:06 video kernel: [ 6607.479406] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? Mar 15 17:08:06 video kernel: [ 6607.479708] xhci_hcd :01:00.0: WARN Set TR deq ptr command for freed stream ID 38885 Mar 15 17:08:06 video kernel: [ 6607.510551] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? [ ... many ... ] Mar 15 17:08:13 video kernel: [ 6614.443826] sd 18:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN Mar 15 17:08:13 video kernel: [ 6614.443829] sd 18:0:0:0: [sde] tag#2 CDB: ATA command pass through(12)/Blank a1 08 2e d0 01 00 4f c2 00 b0 00 00 Mar 15 17:08:13 video kernel: [ 6614.457969] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? Mar 15 17:08:13 video kernel: [ 6614.458274] xhci_hcd :01:00.0: WARN Set TR deq ptr command for freed stream ID 38885 [ ... many ... ] Mar 15 17:08:25 video kernel: [ 6626.497696] sd 18:0:0:0: [sde] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=19s Mar 15 17:08:25 video kernel: [ 6626.497725] sd 18:0:0:0: [sde] tag#5 Sense Key : Illegal Request [current] Mar 15 17:08:25 video kernel: [ 6626.497731] sd 18:0:0:0: [sde] tag#5 Add. Sense: Invalid command operation code Mar 15 17:08:25 video kernel: [ 6626.497739] sd 18:0:0:0: [sde] tag#5 CDB: Read(16) 88 00 00 00 00 01 5e 1d 88 00 00 00 01 00 00 00 Mar 15 17:08:25 video kernel: [ 6626.497746] blk_update_request: critical target error, dev sde, sector 5873960960 op 0x0:(READ) flags 0x0 phys_seg 32 prio class 0 Mar 15 17:08:25 video kernel: [ 6626.497755] md/raid10:md0: sde: rescheduling sector 11747394560 Mar 15 17:08:25 video kernel: [ 6626.497801] usb 3-1.1.4: stat urb: no pending cmd for uas-tag 3 Mar 15 17:08:25 video kernel: [ 6626.497807] md/raid10:md0: sdd: redirecting sector 11747394560 to another mirror Mar 15 17:08:25 video kernel: [ 6626.519426] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? Mar 15 17:08:25 video kernel: [ 6626.519719] xhci_hcd :01:00.0: WARN Set TR deq ptr command for freed stream ID 38885 Mar 15 17:08:25 video kernel: [ 6626.550583] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? Mar 15 17:08:25 video kernel: [ 6626.550875] xhci_hcd :01:00.0: WARN Set TR deq ptr command for fr
Resolu: Boot USB Potable Asus K551L
Il y a une autre option dans le boot pour activer le boot usb. Cordialement Le 28/02/2024 à 11:43, Informatique BILLARD a écrit : Bonjour je souhaite au minimum tester linux en lice sur ce portable et je n'arrive pas à sélectionner l'usb comme source de boot. J'ai pris une version live de Linux Mate basée sur debian LMDE copiée sur une clé avec dd ifof Sur le portable j'ai désactivé SECURE BOOT et activé Launch CSM Mais dans le boot option priority je ne vois pas le support USB. Au redémarrage du PC j'appui sur F2 ce qui me permet de sélectionner le point de démarrage et n'apparait que windows ou le DVD. Merci par avance. cordialement François-Marie
Boot USB Potable Asus K551L
Bonjour je souhaite au minimum tester linux en lice sur ce portable et je n'arrive pas à sélectionner l'usb comme source de boot. J'ai pris une version live de Linux Mate basée sur debian LMDE copiée sur une clé avec dd ifof Sur le portable j'ai désactivé SECURE BOOT et activé Launch CSM Mais dans le boot option priority je ne vois pas le support USB. Au redémarrage du PC j'appui sur F2 ce qui me permet de sélectionner le point de démarrage et n'apparait que windows ou le DVD. Merci par avance. cordialement François-Marie
Re: Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop
10,916 V looks a bit odd to me. After your comments, I looking forward about the battery voltage and I found this: https://www.linkedin.com/pulse/how-choose-laptop-battery-king-sener/ "Voltage is closely related to the number of cells in the battery - typically a 10.8V battery has 6 cells and a 14.4V battery has 8 cells." https://superuser.com/questions/33207/laptop-battery-is-voltage-really-important-to-respect https://superuser.com/a/406492 "The first stage is adapter which is nearly 5 V higher than the battery rating voltage to charge it faster to the full. Now the second stage is the motherboard or processor which typically runs at 5 V and for that you have voltage regulator inside." At 98%, the voltage here is: battery present: yes rechargeable:yes state: charging warning-level: none energy: 36,0417 Wh energy-empty:0 Wh energy-full: 36,3858 Wh energy-full-design: 59,94 Wh energy-rate: 1,8537 W voltage: 12,734 V charge-cycles: N/A time to full:11,1 minutes percentage: 99% capacity:60,7037% technology: lithium-ion icon-name: 'battery-full-charging-symbolic' I found that this battery I bought in 2019. However, it is pretty good yet! -- Marcelo
Re: Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop
Is it possible that the USB ports do not supply power once the laptop is running on battery? Does the NumLock LED of the keyboard go out? On Thu, 2024-02-22 at 13:49 -0300, Marcelo Laia wrote: > Dear Debian Users, > > Thank you all for the invaluable assistance provided. Unfortunately, the > issue has resurfaced today. I don't believe it's related to the age of the > hardware, although my Inspiron 5547-A20 is from 2014, as indicated below: > > Inspiron 5547 01 OCT. 2014 > > Some hardware details: > > - BIOS: >- Vendor: Dell Inc. >- Version: A13 >- Date: 05/27/2019 > - CPU: >- Product: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz > - Memory: >- Size: 16GB > > Today, the battery still had 66% charge when this strange problem occurred. > It's worth mentioning that in all these days, between my last post here on > the list and today, I always use the battery until it reaches between 20-10%, > at which point I plug in the charger and let it charge until it reaches > 95-100%. > > I ran the following commands: > > With the power cable plugged into the power grid, i.e., the battery is > charging: > > :~$ sudo lsusb -t > > /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M > |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M > |__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M > |__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M > |__ Port 006: Dev 004, 12M > |__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, > Driver=rtsx_usb, 480M > |__ Port 008: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M > |__ Port 008: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M > /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M > |__ Port 002: Dev 007, If 0, Class=Human Interface Device, > Driver=usbhid, 1.5M > /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M > :~$ > > :~$ ls /sys/bus/usb/drivers/usb/ > 1-1 1-1.5 1-1.6 1-1.7 1-1.8 2-2 bind module uevent unbind usb1 > usb2 usb3 > :~$ > > After unplugging the power cable, i.e., the battery is discharging: > > After a few seconds, the screen brightness is set to zero. The mouse remains > active, and I can use it for a few more seconds, when it also becomes > disabled. From then on, only the touchpad and internal keyboard are > functional. > > :~$ sudo lsusb -t > > /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M > |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M > |__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M > |__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M > |__ Port 006: Dev 004, 12M > |__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, > Driver=rtsx_usb, 480M > |__ Port 008: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M > |__ Port 008: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M > /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M > /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M > :~$ > > ~$ ls /sys/bus/usb/drivers/usb/ > 1-1 1-1.5 1-1.6 1-1.7 1-1.8 bind module uevent unbind usb1 usb2 > usb3 > :~$ > > :~$ echo '2-2' | sudo tee /sys/bus/usb/drivers/usb/bind > 2-2 > tee: /sys/bus/usb/drivers/usb/bind: No device > :~$ > > :~$ upower --dump > Device: /org/freedesktop/UPower/devices/line_power_ACAD >native-path: ACAD >power supply: yes >updated: qui 22 fev 2024 13:23:50 (182 seconds ago) >has history: no >has statistics: no >line-power > warning-level: none > online: no > icon-name: 'ac-adapter-symbolic' > > Device: /org/freedesktop/UPower/devices/battery_BAT1 >native-path: BAT1 >vendor: SANYO >model:DELL WYT3M94Q >serial: 0038 >power supply: yes >updated: qui 22 fev 2024 13:26:31 (21 seconds ago) >has history: yes >has statistics: yes >battery > present: yes > rechargeable:yes > state: discharging > warning-level: none > energy: 23,9982 Wh > energy-empty:0 Wh > energy-full: 36,4857 Wh > energy-full-design: 59,94 Wh > energy-rate: 30,0588 W > voltage: 10,916 V > charge-cycles: N/A > time to empty: 47,9 minutes
Re: Booten vanaf USB duurt steeds langer
On Thu, Feb 22, 2024 at 09:48:17AM +0100, Paul van der Vlis wrote: > Op 20-02-2024 om 09:31 schreef Paul van der Vlis: > > Hallo, > > > > Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat > > dit steeds trager wordt, op dezelfde machine: > > > > Debian10: 18 seconden > > Debian11: 60 seconden > > Debian12: ruim 120 seconden > > > > Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan > > reuze hard aan het knipperen. Het gaat verder allemaal wel goed. > > > > Op een snellere machine is het wel wat sneller, maar het blijft > > onacceptabel traag. > > > > Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een > > log. Maar omdat er geen tijden bij staan zegt het me weinig over wat nu > > zo lang duurt. Dmesg geeft wel tijden, maar ik kom er niet uit. > > > > Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian > > installer of livestick, dat gaat wel goed. Maar als ik echt Debian > > installeer op een USB device start het traag, dezelfde SSD aan SATA gaat > > wel goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar > > dat lijkt ook niet het probleem. > > > > Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? > > Ik heb in elk geval een work-arround. Dit probleem blijkt niet te spelen in > UEFI modus. Dat is wel interesante informatie. (aanname: nog steeds dezelfde computer) Eerder las ik het originele bericht als "Die is doorvoersnelheid van de USB-controller aan het meten". Met de nieuwe informatie is mijn kijk: "De UEFI bootloader weet beter hoe data achter de USB-controller naar binnen te halen" op de situatie. > Groet, > Paul Groeten Geert Stappers -- Silence is hard to parse
Re: Booten vanaf USB steeds trager
Hoi Geert en anderen, Op 21-02-2024 om 22:35 schreef Geert Stappers: On Wed, Feb 21, 2024 at 04:02:59PM +0100, Paul van der Vlis wrote: Op 20-02-2024 om 21:02 schreef Geert Stappers: On Tue, Feb 20, 2024 at 09:31:02AM +0100, Paul van der Vlis wrote: Hallo, Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat dit steeds trager wordt, op dezelfde machine: Debian10: 18 seconden Debian11: 60 seconden Debian12: ruim 120 seconden zestig gedeeld door achttien is dik drie ruim honderdtwing gedeeld door zes is net geen twee Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan reuze hard aan het knipperen. Het gaat verder allemaal wel goed. Op een snellere machine is het wel wat sneller, maar het blijft onacceptabel traag. Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een log. Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang duurt. Dmesg geeft wel tijden, maar ik kom er niet uit. Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian installer of livestick, dat gaat wel goed. Maar als ik echt Debian installeer op een USB device start het traag, dezelfde SSD aan SATA gaat wel goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat lijkt ook niet het probleem. Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? Ja, ik heb wel een idee. En dat idee wil ik ruilen voor de output van `ls -l /boot` op de getestde versies. Dit is op Debian 10: -- knip -- -rw-r--r-- 1 root root 52343097 jun 3 2021 initrd.img-4.19.0-16-amd64 -- knip -- -rw-r--r-- 1 root root 5287168 mrt 19 2021 vmlinuz-4.19.0-16-amd64 52 miljoen plus 5 miljoen is 57 miljoen. Dit is op Debian 11: -- knip -- -rw-r--r-- 1 root root 57863143 21 feb 15:58 initrd.img-5.10.0-28-amd64 -- knip -- drwx-- 2 root root12288 19 feb 21:24 lost+found -rw-r--r-- 1 root root 7039552 31 jan 22:14 vmlinuz-5.10.0-28-amd64 57m + 7m = 64m 64/57=1,12En 1,12 is echt geen factor drie. Dit is op Debian 12: -- knip -- -rw-r--r-- 1 root root 87651238 19 feb 17:48 initrd.img-6.1.0-15-amd64 -- knip -- drwx-- 2 root root12288 19 feb 16:22 lost+found -rw-r--r-- 1 root root 8140672 9 dec 16:48 vmlinuz-6.1.0-15-amd64 87m + 8m = 95m 95/64 is ongeveer anderhalf. Die anderhalf komt wel in de buurt van factor twee. Terug naar Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? Ja, ik heb wel een idee. Het idee is de kernel en initrd kleiner maken. Of de laad-snelheid groter. Het lijkt er haast op dat dit met een heel lage snelheid gebeurd. Maar wat ook heel goed kan is dat er iets in de initramfs zit wat veel tijd kost. Maar blijkbaar alleen in legacy-mode van het bios, niet bij UEFI. De bijvangst van de `ls -l /boot` is dat "de snelste" geen 'lost+found' heeft. Over verschil in disk partities is nog geen informatie gegeven. Er zijn inderdaad meer verschillen. De twee trage hebben LVM en encryptie en een aparte /boot. Ik had de tijd gemeten tot aan de paswoord prompt van de encryptie. Of bij de oudste tot de berichten van het opstarten van de services begonnen. Nou, ik hoop dat je een goed tip hebt. De initrd is wat groter inderdaad, maar 87MB is niet zo heel groot, met USB3 is dat zo over toch? Groet, Paul Groeten Geert Stappers Verzoek: Meer nieuwsgierigheid, minder mening en nog minder verwachtingen Wellicht waren het wat frustraties... Het ging om iets wat klaar moest, simpel leek, maar onverwachte problemen gaf. En dan ook nog meerdere van dit soort dingen tegelijk. Doe ons allemaal een plezier en ga voor meer nieuwsgierigheid. Stel vragen als "Waar kijk ik tegen aan?", "Hoe het verder te onderzoeken?", "Welk aspect van dichtbij bekijken?". Ik had het beter kunnen formuleren. En ik was er graag dieper in gedoken, maar niet genoeg tijd. Laat meningen op de achtergrond. Verwoord "steeds trager" als "duurt steeds langer". Je bedoeld: een positievere insteek. Mocht je wel een mening hebben, laat dan jouw ego dan aan jouw karma vragen waar die mening "for the greater good" te ventileren. Verwachtingen zijn helemaal van je zelf. Daar moet ik dan zelf ook het meeste mee doen. Zo als geen verwachtingen hebben. Tja, ik heb wel verwachtingen (want ook maar een mens). En ben dan teleurgesteld als het anders gaat. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop
On Thu 22 Feb 2024 at 13:49:54 (-0300), Marcelo Laia wrote: > Inspiron 5547 01 OCT. 2014 > > Some hardware details: > > - BIOS: > - Vendor: Dell Inc. > - Version: A13 > - Date: 05/27/2019 > - CPU: > - Product: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz > - Memory: > - Size: 16GB [ … ] > After unplugging the power cable, i.e., the battery is discharging: > > After a few seconds, the screen brightness is set to zero. The mouse > remains active, and I can use it for a few more seconds, when it > also becomes disabled. From then on, only the touchpad and internal > keyboard are functional. [ … ] > Any other suggestions? It seems to me that it's not related to > power, however, what is the specific list for energy-related issues? My advice would be to prepare for a day when you see nothing from the moment you switch it on. Here's a log of what happened with my Dell D430 laptop, purchased in 2008 as a stop-gap, acquired by me in 2009. First the battery packs: 2014-02-12 Large battery started to go bad. Charging light started constantly flashing a pattern: four yellows and a longer green. Apart from that, everything works ok: the battery stays at five lights, and the acpi variables all show sensible values. However, the battery discharges much more quickly than it should, particularly early on, so some cells probably don't work properly. 2015-03-29 Started to switch itself off when the power cable was disconnected. It appears that the battery is not actually connected to the computer when this happens. 2015-03-31 The large battery finally gave up. When the charge button is pressed, only LEDS 1, 3 and 5 light up, but flashing. Otherwise, dead. Disposed of the large battery in Best Buy's foyer and started using the small one. And the screen: 2011-10-21 Started to switch itself off unaccountably every so often. No freeze, no kernel panic, but just like holding down the power switch. It will have been running a while, and usually it happens when the machine or lid is moved. 2017-01-22 After a day or two of slight flickering in brightness, the screen blanked out a few times during the day. The machine was still running, and so X could be quit and restarted, and rebooted too. The screen would come back, but often disappear almost immediately, even while the Dell splash screen was being displayed at switch-on. It went away entirely the same day. 2018-06-19 After being depowered for a week, the battery capacity had fallen to 2%. However, on AC the screen started working again, though it just flickered a little all the time. Took the opportunity to demote Internal HDD to below USB and Optical Drive in the BIOS. Got about three minutes before it reverted. 2020-04-16 Started to crash, and eventually failed to boot. Obviously difficult to diagnose when there's no display at power-on, so scrapped. If you're wondering why I kept it so long, I could use an external monitor to display its X server screen, but neither the BIOS nor the console would work that way, so I had to type blind until I got into X. With a 30 second countdown, I could operate the Grub screen blind. I also managed to install buster in text mode by copying what I typed while installing on another PC at the same time. (I might have been able to clone jessie into the other partition, but that would have then required two dist-upgrades.) Cheers, David.
Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop
On Thu, 22 Feb 2024 13:49:54 -0300 Marcelo Laia wrote: > Thank you all for the invaluable assistance provided. Unfortunately, > the issue has resurfaced today. I don't believe it's related to the > age of the hardware, although my Inspiron 5547-A20 is from 2014, as > indicated below: A stab in the dark: I take it that you ran the upower --dump command while the battery was discharging. 10,916 V looks a bit odd to me. What does a dump show when the battery is fully charged? I wonder if that voltage is too low to support the laptop. My two ancient Lenovos (2011 and 2012) are both showing much better values than that. The difference between the energy-full and energy-full-design values, and the capacity both lead me to wonder if it isn't time to buy a new battery (or maybe a new or refurbished laptop). -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop
Dear Debian Users, Thank you all for the invaluable assistance provided. Unfortunately, the issue has resurfaced today. I don't believe it's related to the age of the hardware, although my Inspiron 5547-A20 is from 2014, as indicated below: Inspiron 5547 01 OCT. 2014 Some hardware details: - BIOS: - Vendor: Dell Inc. - Version: A13 - Date: 05/27/2019 - CPU: - Product: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz - Memory: - Size: 16GB Today, the battery still had 66% charge when this strange problem occurred. It's worth mentioning that in all these days, between my last post here on the list and today, I always use the battery until it reaches between 20-10%, at which point I plug in the charger and let it charge until it reaches 95-100%. I ran the following commands: With the power cable plugged into the power grid, i.e., the battery is charging: :~$ sudo lsusb -t /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 006: Dev 004, 12M |__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M |__ Port 008: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 008: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 002: Dev 007, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M :~$ :~$ ls /sys/bus/usb/drivers/usb/ 1-1 1-1.5 1-1.6 1-1.7 1-1.8 2-2 bind module uevent unbind usb1 usb2 usb3 :~$ After unplugging the power cable, i.e., the battery is discharging: After a few seconds, the screen brightness is set to zero. The mouse remains active, and I can use it for a few more seconds, when it also becomes disabled. From then on, only the touchpad and internal keyboard are functional. :~$ sudo lsusb -t /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 006: Dev 004, 12M |__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M |__ Port 008: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 008: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M :~$ ~$ ls /sys/bus/usb/drivers/usb/ 1-1 1-1.5 1-1.6 1-1.7 1-1.8 bind module uevent unbind usb1 usb2 usb3 :~$ :~$ echo '2-2' | sudo tee /sys/bus/usb/drivers/usb/bind 2-2 tee: /sys/bus/usb/drivers/usb/bind: No device :~$ :~$ upower --dump Device: /org/freedesktop/UPower/devices/line_power_ACAD native-path: ACAD power supply: yes updated: qui 22 fev 2024 13:23:50 (182 seconds ago) has history: no has statistics: no line-power warning-level: none online: no icon-name: 'ac-adapter-symbolic' Device: /org/freedesktop/UPower/devices/battery_BAT1 native-path: BAT1 vendor: SANYO model:DELL WYT3M94Q serial: 0038 power supply: yes updated: qui 22 fev 2024 13:26:31 (21 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable:yes state: discharging warning-level: none energy: 23,9982 Wh energy-empty:0 Wh energy-full: 36,4857 Wh energy-full-design: 59,94 Wh energy-rate: 30,0588 W voltage: 10,916 V charge-cycles: N/A time to empty: 47,9 minutes percentage: 65% capacity:60,8704% technology: lithium-ion icon-name: 'battery-full-symbolic' History (charge): 1708619191 65,000 discharging 1708619161 66,000 discharging 1708619101 67,000 discharging History (rate): 1708619101 30,059 discharging Device: /org/freedesktop/UPower/devices/DisplayDevice power supply: yes updated: qui 22 fev 2024 13:26:31 (21 seconds ago) has history: no has statistics: no battery present: yes state: discharging warning-level: none energy: 23,9982 Wh energy-full: 36,4857 Wh energy-rate: 30,0588 W charge-cycles: N/A time to empty: 47,9 minutes percentage
Re: Booten vanaf USB steeds trager
Ik lees Geert zijn reactie en dacht toen aan hoe ik zelf eerder mijn kernels moest verkleinen? dat was met modules=dep in /etc/initramfs-tools/conf.d/module
Re: Booten vanaf USB steeds trager
Hoi allen, Op 20-02-2024 om 09:31 schreef Paul van der Vlis: Hallo, Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat dit steeds trager wordt, op dezelfde machine: Debian10: 18 seconden Debian11: 60 seconden Debian12: ruim 120 seconden Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan reuze hard aan het knipperen. Het gaat verder allemaal wel goed. Op een snellere machine is het wel wat sneller, maar het blijft onacceptabel traag. Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een log. Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang duurt. Dmesg geeft wel tijden, maar ik kom er niet uit. Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian installer of livestick, dat gaat wel goed. Maar als ik echt Debian installeer op een USB device start het traag, dezelfde SSD aan SATA gaat wel goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat lijkt ook niet het probleem. Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? Ik heb in elk geval een work-arround. Dit probleem blijkt niet te spelen in UEFI modus. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Booten vanaf USB steeds trager
On Wed, Feb 21, 2024 at 04:02:59PM +0100, Paul van der Vlis wrote: > Op 20-02-2024 om 21:02 schreef Geert Stappers: > > On Tue, Feb 20, 2024 at 09:31:02AM +0100, Paul van der Vlis wrote: > > > Hallo, > > > > > > Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat > > > dit > > > steeds trager wordt, op dezelfde machine: > > > > > > Debian10: 18 seconden > > > Debian11: 60 seconden > > > Debian12: ruim 120 seconden zestig gedeeld door achttien is dik drie ruim honderdtwing gedeeld door zes is net geen twee > > > Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan > > > reuze > > > hard aan het knipperen. Het gaat verder allemaal wel goed. > > > > > > Op een snellere machine is het wel wat sneller, maar het blijft > > > onacceptabel > > > traag. > > > > > > Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een > > > log. > > > Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang > > > duurt. Dmesg geeft wel tijden, maar ik kom er niet uit. > > > > > > Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian > > > installer of livestick, dat gaat wel goed. Maar als ik echt Debian > > > installeer op een USB device start het traag, dezelfde SSD aan SATA gaat > > > wel > > > goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat > > > lijkt ook niet het probleem. > > > > > > Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? > > > > Ja, ik heb wel een idee. > > En dat idee wil ik ruilen voor de output van `ls -l /boot` > > op de getestde versies. > > Dit is op Debian 10: > -- knip -- > -rw-r--r-- 1 root root 52343097 jun 3 2021 initrd.img-4.19.0-16-amd64 > -- knip -- > -rw-r--r-- 1 root root 5287168 mrt 19 2021 vmlinuz-4.19.0-16-amd64 52 miljoen plus 5 miljoen is 57 miljoen. > Dit is op Debian 11: > -- knip -- > -rw-r--r-- 1 root root 57863143 21 feb 15:58 initrd.img-5.10.0-28-amd64 > -- knip -- > drwx-- 2 root root12288 19 feb 21:24 lost+found > -rw-r--r-- 1 root root 7039552 31 jan 22:14 vmlinuz-5.10.0-28-amd64 57m + 7m = 64m 64/57=1,12En 1,12 is echt geen factor drie. > Dit is op Debian 12: > -- knip -- > -rw-r--r-- 1 root root 87651238 19 feb 17:48 initrd.img-6.1.0-15-amd64 > -- knip -- > drwx-- 2 root root12288 19 feb 16:22 lost+found > -rw-r--r-- 1 root root 8140672 9 dec 16:48 vmlinuz-6.1.0-15-amd64 87m + 8m = 95m 95/64 is ongeveer anderhalf. Die anderhalf komt wel in de buurt van factor twee. Terug naar > > > Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? > > > > Ja, ik heb wel een idee. Het idee is de kernel en initrd kleiner maken. De bijvangst van de `ls -l /boot` is dat "de snelste" geen 'lost+found' heeft. Over verschil in disk partities is nog geen informatie gegeven. > Nou, ik hoop dat je een goed tip hebt. De initrd is wat groter inderdaad, > maar 87MB is niet zo heel groot, met USB3 is dat zo over toch? > Groet, > Paul > Groeten Geert Stappers Verzoek: Meer nieuwsgierigheid, minder mening en nog minder verwachtingen Doe ons allemaal een plezier en ga voor meer nieuwsgierigheid. Stel vragen als "Waar kijk ik tegen aan?", "Hoe het verder te onderzoeken?", "Welk aspect van dichtbij bekijken?". Laat meningen op de achtergrond. Verwoord "steeds trager" als "duurt steeds langer". Mocht je wel een mening hebben, laat dan jouw ego dan aan jouw karma vragen waar die mening "for the greater good" te ventileren. Verwachtingen zijn helemaal van je zelf. Daar moet ik dan zelf ook het meeste mee doen. Zo als geen verwachtingen hebben. -- Silence is hard to parse
Re: Booten vanaf USB steeds trager
On Wed, 21 Feb 2024 15:42:36 +0100 Paul van der Vlis wrote: > > Ik heb ook zoiets gehad, tijdens het booten geeft-ie aan dat-ie de > > root device niet kan vinden en dat duurt dan een tijdje. IIRC helpt > > een > > > > update-initramfs -u > > Dit had ik al geprobeerd, maar hielp niet. Ik bedacht me later dat dat met md devices is. Als de mdadm.conf niet overeenkomt met wat er in de initramdisk zit dan gaat-ie md127, md126 etc aanmaken en dan krijg je dat. Nooit uitgezocht waarom. En dan helpt de update-initramfs -u wel uiteraard. > > console=serial0,115200 console=tty1 root=PARTUUID=3fc93f64-02 > > rootfstype=ext4 fsck.repair=yes rootwait > > Dit is geen Pi, dus ook geen cmdline.txt Het gaat niet zozeer om de RPi, maar om de kernel opties die de kernel meekrijgt als-ie vanaf USB boot R. -- richard lucassen http://contact.xaq.nl/
Re: Booten vanaf USB steeds trager
Hoi Geert en anderen, Op 20-02-2024 om 21:02 schreef Geert Stappers: On Tue, Feb 20, 2024 at 09:31:02AM +0100, Paul van der Vlis wrote: Hallo, Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat dit steeds trager wordt, op dezelfde machine: Debian10: 18 seconden Debian11: 60 seconden Debian12: ruim 120 seconden Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan reuze hard aan het knipperen. Het gaat verder allemaal wel goed. Op een snellere machine is het wel wat sneller, maar het blijft onacceptabel traag. Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een log. Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang duurt. Dmesg geeft wel tijden, maar ik kom er niet uit. Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian installer of livestick, dat gaat wel goed. Maar als ik echt Debian installeer op een USB device start het traag, dezelfde SSD aan SATA gaat wel goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat lijkt ook niet het probleem. Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? Ja, ik heb wel een idee. En dat idee wil ik ruilen voor de output van `ls -l /boot` op de getestde versies. Dit is op Debian 10: -rw-r--r-- 1 root root 206143 okt 18 2020 config-4.19.0-12-amd64 -rw-r--r-- 1 root root 206269 nov 28 2020 config-4.19.0-13-amd64 -rw-r--r-- 1 root root 206242 mrt 19 2021 config-4.19.0-16-amd64 -rw-r--r-- 1 root root 206118 mrt 15 2019 config-4.19.0-4-amd64 -rw-r--r-- 1 root root 206361 nov 11 2019 config-4.19.0-6-amd64 drwxr-xr-x 5 root root 4096 jun 3 2021 grub -rw-r--r-- 1 root root 51780082 nov 30 2020 initrd.img-4.19.0-12-amd64 -rw-r--r-- 1 root root 51874209 dec 28 2020 initrd.img-4.19.0-13-amd64 -rw-r--r-- 1 root root 52343097 jun 3 2021 initrd.img-4.19.0-16-amd64 -rw-r--r-- 1 root root 25616128 okt 29 2019 initrd.img-4.19.0-4-amd64 -rw-r--r-- 1 root root 51705982 nov 30 2020 initrd.img-4.19.0-6-amd64 -rw-r--r-- 1 root root 182704 jun 25 2015 memtest86+.bin -rw-r--r-- 1 root root 184840 jun 25 2015 memtest86+_multiboot.bin -rw-r--r-- 1 root root 3415048 okt 18 2020 System.map-4.19.0-12-amd64 -rw-r--r-- 1 root root 3419998 nov 28 2020 System.map-4.19.0-13-amd64 -rw-r--r-- 1 root root 3421023 mrt 19 2021 System.map-4.19.0-16-amd64 -rw-r--r-- 1 root root 3365519 mrt 15 2019 System.map-4.19.0-4-amd64 -rw-r--r-- 1 root root 3410671 nov 11 2019 System.map-4.19.0-6-amd64 -rw-r--r-- 1 root root 5278960 okt 18 2020 vmlinuz-4.19.0-12-amd64 -rw-r--r-- 1 root root 5283056 nov 28 2020 vmlinuz-4.19.0-13-amd64 -rw-r--r-- 1 root root 5287168 mrt 19 2021 vmlinuz-4.19.0-16-amd64 -rw-r--r-- 1 root root 5213424 mrt 15 2019 vmlinuz-4.19.0-4-amd64 -rw-r--r-- 1 root root 5270768 nov 11 2019 vmlinuz-4.19.0-6-amd64 Dit is op Debian 11: -rw-r--r-- 1 root root 236286 2 sep 2022 config-5.10.0-18-amd64 -rw-r--r-- 1 root root 236364 31 jan 22:14 config-5.10.0-28-amd64 drwxr-xr-x 5 root root 1024 21 feb 15:58 grub -rw-r--r-- 1 root root 50620656 19 feb 21:39 initrd.img-5.10.0-18-amd64 -rw-r--r-- 1 root root 57863143 21 feb 15:58 initrd.img-5.10.0-28-amd64 drwx-- 2 root root12288 19 feb 21:24 lost+found -rw-r--r-- 1 root root 83 2 sep 2022 System.map-5.10.0-18-amd64 -rw-r--r-- 1 root root 83 31 jan 22:14 System.map-5.10.0-28-amd64 -rw-r--r-- 1 root root 6962016 2 sep 2022 vmlinuz-5.10.0-18-amd64 -rw-r--r-- 1 root root 7039552 31 jan 22:14 vmlinuz-5.10.0-28-amd64 Dit is op Debian 12: -rw-r--r-- 1 root root 259455 9 dec 16:48 config-6.1.0-15-amd64 drwxr-xr-x 5 root root 1024 19 feb 16:50 grub -rw-r--r-- 1 root root 87651238 19 feb 17:48 initrd.img-6.1.0-15-amd64 drwx-- 2 root root12288 19 feb 16:22 lost+found -rw-r--r-- 1 root root 83 9 dec 16:48 System.map-6.1.0-15-amd64 -rw-r--r-- 1 root root 8140672 9 dec 16:48 vmlinuz-6.1.0-15-amd64 Nou, ik hoop dat je een goed tip hebt. De initrd is wat groter inderdaad, maar 87MB is niet zo heel groot, met USB3 is dat zo over toch? Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Booten vanaf USB steeds trager
Hoi Richard en anderen,
Op 20-02-2024 om 12:27 schreef Richard Lucassen:
On Tue, 20 Feb 2024 09:31:02 +0100
Paul van der Vlis wrote:
Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op
dat dit steeds trager wordt, op dezelfde machine:
Debian10: 18 seconden
Debian11: 60 seconden
Debian12: ruim 120 seconden
Ik heb ook zoiets gehad, tijdens het booten geeft-ie aan dat-ie de root
device niet kan vinden en dat duurt dan een tijdje. IIRC helpt een
update-initramfs -u
Dit had ik al geprobeerd, maar hielp niet.
dan, maar zeker weet ik dat niet ('t is alweer een tijdje terug). Met
een monitor erop kun je die meldingen zien. Ik sloop trouwens altijd de
"quiet" optie uit /etc/default/grub (en daarna update-grub). Heb je wel
"rootwait" als kerneloptie meegegeven? Volgens mij moet dat ook. Dit
staat in de cmdline.txt file op mijn Raspberry Pi:
console=serial0,115200 console=tty1 root=PARTUUID=3fc93f64-02
rootfstype=ext4 fsck.repair=yes rootwait
Dit is geen Pi, dus ook geen cmdline.txt
Ben geen guru op dat gebied trouwens.
Ik ook niet...
Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/
Re: Booten vanaf USB steeds trager
On Tue, Feb 20, 2024 at 09:31:02AM +0100, Paul van der Vlis wrote: > Hallo, > > Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat dit > steeds trager wordt, op dezelfde machine: > > Debian10: 18 seconden > Debian11: 60 seconden > Debian12: ruim 120 seconden > > Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan reuze > hard aan het knipperen. Het gaat verder allemaal wel goed. > > Op een snellere machine is het wel wat sneller, maar het blijft onacceptabel > traag. > > Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een log. > Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang > duurt. Dmesg geeft wel tijden, maar ik kom er niet uit. > > Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian > installer of livestick, dat gaat wel goed. Maar als ik echt Debian > installeer op een USB device start het traag, dezelfde SSD aan SATA gaat wel > goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat > lijkt ook niet het probleem. > > Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? Ja, ik heb wel een idee. En dat idee wil ik ruilen voor de output van `ls -l /boot` op de getestde versies. > Groet, > Paul Groeten Geert Stappers -- Silence is hard to parse
Re: Booten vanaf USB steeds trager
On Tue, 20 Feb 2024 09:31:02 +0100
Paul van der Vlis wrote:
> Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op
> dat dit steeds trager wordt, op dezelfde machine:
>
> Debian10: 18 seconden
> Debian11: 60 seconden
> Debian12: ruim 120 seconden
Ik heb ook zoiets gehad, tijdens het booten geeft-ie aan dat-ie de root
device niet kan vinden en dat duurt dan een tijdje. IIRC helpt een
update-initramfs -u
dan, maar zeker weet ik dat niet ('t is alweer een tijdje terug). Met
een monitor erop kun je die meldingen zien. Ik sloop trouwens altijd de
"quiet" optie uit /etc/default/grub (en daarna update-grub). Heb je wel
"rootwait" als kerneloptie meegegeven? Volgens mij moet dat ook. Dit
staat in de cmdline.txt file op mijn Raspberry Pi:
console=serial0,115200 console=tty1 root=PARTUUID=3fc93f64-02
rootfstype=ext4 fsck.repair=yes rootwait
Ben geen guru op dat gebied trouwens.
--
richard lucassen
http://contact.xaq.nl/
Booten vanaf USB steeds trager
Hallo, Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat dit steeds trager wordt, op dezelfde machine: Debian10: 18 seconden Debian11: 60 seconden Debian12: ruim 120 seconden Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan reuze hard aan het knipperen. Het gaat verder allemaal wel goed. Op een snellere machine is het wel wat sneller, maar het blijft onacceptabel traag. Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een log. Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang duurt. Dmesg geeft wel tijden, maar ik kom er niet uit. Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian installer of livestick, dat gaat wel goed. Maar als ik echt Debian installeer op een USB device start het traag, dezelfde SSD aan SATA gaat wel goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat lijkt ook niet het probleem. Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg? Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop
On 15/02/2024 12:39, David Wright wrote: I would go further than tomas, and suggest that the battery might be suspect, or the charging circuit of course. (None of my three laptops works without AC power.) How old is it? Battery health may be estimated from output of upower --dump by comparison energy-full-design, energy-full, and other values. I still believe it is excessively aggressive power settings in GNOME or in firmware (BIOS) setup. Maybe it is result of shooting own foot by tools like powertop or tlp. Anyway it is rather wrong settings than wrong behavior. There is a chance that the issue is with USB controller driver. Likely it is better to ask the same question in a user group more specific to power management.
Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop
On Wed 14 Feb 2024 at 20:09:09 (-0300), Marcelo Laia wrote: > Unfortunately, the issue has worsened. Today, I observed that upon unplugging > the power cable, within one or two seconds, the screen dims (brightness is > set to zero), and both the external mouse and keyboard (USB) stop working. > Even if I try to use the keyboard or mouse, they do not reactivate. Only the > laptop's internal touchpad and keyboard continue to function. When I > reconnect the power cable, both the external mouse and keyboard resume > working automatically. However, I need to manually adjust the screen > brightness. I have not installed the usbguard package. Could there be another > underlying cause? I would go further than tomas, and suggest that the battery might be suspect, or the charging circuit of course. (None of my three laptops works without AC power.) How old is it? Cheers, David.
Re: Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop
Dear Debian community, Thank you for your insights. Unfortunately, the issue has worsened. Today, I observed that upon unplugging the power cable, within one or two seconds, the screen dims (brightness is set to zero), and both the external mouse and keyboard (USB) stop working. Even if I try to use the keyboard or mouse, they do not reactivate. Only the laptop's internal touchpad and keyboard continue to function. When I reconnect the power cable, both the external mouse and keyboard resume working automatically. However, I need to manually adjust the screen brightness. I have not installed the usbguard package. Could there be another underlying cause? Best regards, -- Marcelo
Re: Problema puerto usb-c
Lo mando a la lista. El 2024-02-11 a las 20:13 +0100, JA CM escribió: > Gracias por la ayuda camaleón, te contesto a las cuestiones que me planteas > y te comento otras: > Es la única versión de Kernel que tengo 6.1.0-17-amd64, estoy pendiente > de actualizar a la 6.1.0-17-amd64 pero por algún error de configuración no > lo hace directamente. Tengo que mirarlo pero eso es otro cantar. Hum... no sé por qué yo tengo 3 versiones guardadas: root@noc11:~# dpkg -l | grep -i image ii linux-base 4.9 all Linux image base package ii linux-image-6.1.0-15-amd64 6.1.66-1amd64 Linux 6.1 for 64-bit PCs (signed) ii linux-image-6.1.0-17-amd64 6.1.69-1amd64 Linux 6.1 for 64-bit PCs (signed) ii linux-image-6.1.0-18-amd64 6.1.76-1amd64 Linux 6.1 for 64-bit PCs (signed) ii linux-image-amd646.1.76-1amd64 Linux for 64-bit PCs (meta-package) ¿Has instalado el sistema hace poco? :-? > No tengo adaptador usb-c a usb 3.0 convencional, mañana me acercaré a > una tienda de informática local a por uno. Merece la pena que tengas uno, pero comprueba antes que el chipset del adaptador sea compatible con linux, no vaya a ser que añadamos otro problema :-) > No he podido conectar otro dispositivo porque no tengo ninguno con esa > salida. Lo que sé es que el puerto funciona, porque en Windows sí que > trabaja. Si funcionaba la cámara en linux, el puerto funciona. Seguramente se deba a un problema con el controlador de linux para USB-C (el kernel, en este caso). > ___ > *usb 6-1 current rate 16000 is different from the runtime rate 48000*. > Por lo que he buscado al respecto esto está relacionado con la frecuencia > del sonido de la cámara. > - > *xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of > current TD ep_index 2 comp_code 13* > También está relacionado con la tarjeta de sonido, buscando en internet lo > explicaban y me hizo darme cuenta que el :03:00.0 me indicaba la > tarjeta de sonido que tengo que es la STRIX RAID DLX de ASUS como puede > verse en la captura de la salida lsUSB > - > En cuanto a los enlaces que me das, te lo agradezco. Los había visto en las > búsquedas y seguidos pero no me han conducido a la solución. No obstante > muchas gracias. > Añado un enlace más a pastebin con la salida de usb-devices donde se puede > ver el driver usado por cada uno de los puertos.. > https://pastebin.com/gbxai0rs Por lo que he leído en los foros, parece un problema generalizado con el puerto USB-C y el modelo de cámara web. Saludos, -- Camaleón
Re: Problema puerto usb-c
El 2024-02-10 a las 19:40 +0100, JA CM escribió: > Buenos días > Tengo una StremCam de Logitec con conector USB-C que hasta hace poco me > funcionaba correctamente pero que ha dejado de hacerlo de una manera > extraña. Que algo deje de funcionar sin más es extraño :-? Lo único que puede haber cambiado es la versión del kernel, pero en Debian estable los cambios del kernel son muy leves entre versiones, sólo actualizan parches de seguridad que no suelen añadir o quitar funcionalidades. Si aún mantienes alguna versión anterior, prueba a iniciar el sistema con otro kernel más antiguo (normalmente el sistema mantiene 2 o 3 núcleos cuando sale alguna actualización). > El SO es un Debian 12 y el Kernel es 6.1.0-17-amd. Tiene arranque dual con > Windows 10 (con fast boot desactivado y en Windows la cámara va bien). La > placa base es una ASUS PRIME X299-A y sólo tiene un puerto USB-C ¿Has probado a conectar la cámara a otro puerto USB (con adaptador)? ¿Has probado a conectar otro dispositivo al puerto USB-C? > Cuando arranco el sistema me detecta sin problemas el dispositivo: > * la salida lsusb y v4lw-ctl --list-devices es: > [image: lsusb.png][image: v412-list.png] > A pesar de esto, en los logs del núcleo (kern.log) me aparece varias veces > el mensaje siguiente: > usb 6-1 *current rate 16000 is different from the runtime rate 48000*. > Si ejecuto el programa de cámaras Cheese en los logs del nucleo me aparecen > multitud de veces los dos mensajes siguientes > 2024-02-10T14:25:19.003426+01:00 debian kernel: [ 2749.691059] *xhci_hcd > :03:00.0: ERROR* Transfer event TRB DMA ptr not part of current TD > ep_index 2 comp_code 13 > 2024-02-10T14:25:19.003427+01:00 debian kernel: [ 2749.691061] xhci_hcd > :03:00.0: Looking for event-dma fffc5a20 trb-start > fffc5130 trb-end fffc5130 seg-start fffc5000> seg-end > fffc5ff0 (...) > Si es guvcview quien arranca la cámara el kernel lanza lo siguiente > 2024-02-10T14:25:41.313584+01:00 debian kernel: [ 2772.000990] *uvcvideo > 6-1:1.1: Failed to query *(130) UVC probe control : -110 (exp. 26). > 2024-02-10T14:25:46.433585+01:00 debian kernel: [ 2777.117761] *uvcvideo > 6-1:1.1: Failed to set UVC probe control : -110 (exp. 26)*. > 2024-02-10T14:25:53.980089+01:00 debian kernel: [ 2784.667935] *DMAR: DRHD*: > handling fault status reg 2 > 2024-02-10T14:25:53.980100+01:00 debian kernel: [ 2784.667944] DMAR: [DMA > Write NO_PASID] Request device [03:00.0] fault addr 0xffe2a000 [fault reason > 0x05] PTE Write access is not set > 2024-02-10T14:25:53.980596+01:00 debian kernel: [ 2784.668452] *xhci_hcd > :03:00.0: WARN* Event TRB for slot 1 ep 0 with no TDs queued? > 2024-02-10T14:25:53.981078+01:00 debian kernel: [ 2784.668949] DMAR: *DRHD: > handling fault status reg 102* > 2024-02-10T14:25:53.981082+01:00 debian kernel: [ 2784.668953] *DMAR: [DMA > Read NO_PASID] *Request device [03:00.0] fault addr 0xffe2d000 [fault reason > 0x06] PTE Read access is not set > El caso es que después de esto, ya deja de aparecer la cámara al ejecutar > lsusb y v4lw-ctl con lo que dev/video0 tampoco existe y no hay cámara. > Además, en los log de núcleo tengo mensajes de intentos de reset del puerto > y de error como los siguientes sin llegar en ningún momento a reconocer la > cámara: (...) > Estoy buscando información por los temas marcados en negrita pero aún no he > llegado a nada concluyente. He descargado y recargado el módulo con > modprobe -rv usbhid ; sudo modprobe -v usbhid > pero tampoco he conseguido nada. Comentar también que recientemente y para > poder instalar el paquete "info" de ayuda de GNU tuve que corregir un error > y es que el archivo /etc/enviroment contenía: JAVA_HOME= > "/usr/lib/jvm/java-17-openjdk-amd64/" y para permitir la instalación tenía > que ser JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64/ > Ahora voy a anular el usbcore.autosuspend pero sin esperanzas, por eso les > escribo, si bien continúo buscando. > > Muchas gracias por adelantado y un saludo. Dejo también en pastebin los > siguientes archivos: > > * https://pastebin.com/1T2grDLQ con errores del kernel > * https://pastebin.com/98VY0B44 con dpkg.log > * https://pastebin.com/sdrJmK06 con history.log de apt Gracias por los paste, muy útiles y completos, así da gusto :-) Por los mensajes que recibes del kernel, he localizado algunos problemas similiares, mira a ver si te algo de lo que comentan te sirve: USB-Controller crashes after increasing webcam resolution https://bbs.archlinux.org/viewtopic.php?id=262432 Logitech BRIO webcam fails with "xhci_hcd :02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873439 Saludos, -- Camaleón
Problema puerto usb-c
Buenos días Tengo una StremCam de Logitec con conector USB-C que hasta hace poco me funcionaba correctamente pero que ha dejado de hacerlo de una manera extraña. El SO es un Debian 12 y el Kernel es 6.1.0-17-amd. Tiene arranque dual con Windows 10 (con fast boot desactivado y en Windows la cámara va bien). La placa base es una ASUS PRIME X299-A y sólo tiene un puerto USB-C Cuando arranco el sistema me detecta sin problemas el dispositivo: * la salida lsusb y v4lw-ctl --list-devices es: [image: lsusb.png][image: v412-list.png] A pesar de esto, en los logs del núcleo (kern.log) me aparece varias veces el mensaje siguiente: usb 6-1 *current rate 16000 is different from the runtime rate 48000*. Si ejecuto el programa de cámaras Cheese en los logs del nucleo me aparecen multitud de veces los dos mensajes siguientes 2024-02-10T14:25:19.003426+01:00 debian kernel: [ 2749.691059] *xhci_hcd :03:00.0: ERROR* Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 2024-02-10T14:25:19.003427+01:00 debian kernel: [ 2749.691061] xhci_hcd :03:00.0: Looking for event-dma fffc5a20 trb-start fffc5130 trb-end fffc5130 seg-start fffc5000 seg-end fffc5ff0 Si es guvcview quien arranca la cámara el kernel lanza lo siguiente 2024-02-10T14:25:41.313584+01:00 debian kernel: [ 2772.000990] *uvcvideo 6-1:1.1: Failed to query *(130) UVC probe control : -110 (exp. 26). 2024-02-10T14:25:46.433585+01:00 debian kernel: [ 2777.117761] *uvcvideo 6-1:1.1: Failed to set UVC probe control : -110 (exp. 26)*. 2024-02-10T14:25:53.980089+01:00 debian kernel: [ 2784.667935] *DMAR: DRHD*: handling fault status reg 2 2024-02-10T14:25:53.980100+01:00 debian kernel: [ 2784.667944] DMAR: [DMA Write NO_PASID] Request device [03:00.0] fault addr 0xffe2a000 [fault reason 0x05] PTE Write access is not set 2024-02-10T14:25:53.980596+01:00 debian kernel: [ 2784.668452] *xhci_hcd :03:00.0: WARN* Event TRB for slot 1 ep 0 with no TDs queued? 2024-02-10T14:25:53.981078+01:00 debian kernel: [ 2784.668949] DMAR: *DRHD: handling fault status reg 102* 2024-02-10T14:25:53.981082+01:00 debian kernel: [ 2784.668953] *DMAR: [DMA Read NO_PASID] *Request device [03:00.0] fault addr 0xffe2d000 [fault reason 0x06] PTE Read access is not set El caso es que después de esto, ya deja de aparecer la cámara al ejecutar lsusb y v4lw-ctl con lo que dev/video0 tampoco existe y no hay cámara. Además, en los log de núcleo tengo mensajes de intentos de reset del puerto y de error como los siguientes sin llegar en ningún momento a reconocer la cámara: 2024-02-10T14:26:08.321680+01:00 debian kernel: [ 2799.007414] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd 2024-02-10T14:26:13.569591+01:00 debian kernel: [ 2804.257167] usb 6-1: *device descriptor read/8, error -110* 2024-02-10T14:26:13.677672+01:00 debian kernel: [ 2804.361604] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd 2024-02-10T14:26:29.185640+01:00 debian kernel: [ 2819.870020] usb 6-1: device descriptor read/8, error -110 2024-02-10T14:26:29.497667+01:00 debian kernel: [ 2820.182922] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd 2024-02-10T14:26:34.561590+01:00 debian kernel: [ 2825.249296] usb 6-1: device descriptor read/8, error -110 2024-02-10T14:26:34.669672+01:00 debian kernel: [ 2825.353701] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd 2024-02-10T14:26:50.177640+01:00 debian kernel: [ 2840.862151] usb 6-1: device descriptor read/8, error -110 2024-02-10T14:26:50.489680+01:00 debian kernel: [ 2841.175072] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd 2024-02-10T14:26:55.553589+01:00 debian kernel: [ 2846.241524] usb 6-1: device descriptor read/8, error -110 2024-02-10T14:26:55.661675+01:00 debian kernel: [ 2846.345808] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd 2024-02-10T14:27:11.169655+01:00 debian kernel: [ 2861.854227] usb 6-1: device descriptor read/8, error -110 2024-02-10T14:27:11.485661+01:00 debian kernel: [ 2862.171067] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd 2024-02-10T14:27:16.549585+01:00 debian kernel: [ 2867.237473] usb 6-1: device descriptor read/8, error -110 2024-02-10T14:27:16.657664+01:00 debian kernel: [ 2867.341915] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd 2024-02-10T14:27:32.161641+01:00 debian kernel: [ 2882.846322] usb 6-1: device descriptor read/8, error -110 2024-02-10T14:27:32.293588+01:00 debian kernel: [ 2882.978077] usb 6-1: USB disconnect, device number 2 2024-02-10T14:27:32.549559+01:00 debian kernel: [ 2883.234688] usb 6-1: new SuperSpeed USB device number 3 using xhci_hcd 2024-02-10T14:27:37.793640+01:00 debian kernel: [ 2888.478316] usb 6-1: device descriptor read/8, error -110 2024-02-10T14:27:37.901629+01:00 debian kernel: [ 2888.585993] usb 6-1: new SuperSpeed USB device number 3 using xhci_hcd 2024-02-10T14:27:53.409639+01:00 debian kernel: [ 2904.094357] usb 6-1: device
Re: Things I don't touch with a 3.048m barge pole: USB storage(WasRe: Unidentified subject!)
On 2/10/24 00:54, David Christensen wrote: On 2/9/24 04:53, gene heskett wrote: Interesting report from gdisk however: GPT fdisk (gdisk) version 1.0.9 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! *** Warning! Secondary partition table overlaps the last partition by 33 blocks! You will need to delete this partition or resize it in another utility. Command (? for help): Command (? for help): p Disk /dev/sdm: 409600 sectors, 1.9 TiB Model: SSD 3.0 Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 3230045D-589D-4601-8C4D-E9C4684B9657 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 409566 Partitions will be aligned on 64-sector boundaries Total free space is 30 sectors (15.0 KiB) Number Start (sector) End (sector) Size Code Name 1 64 409599 1.9 TiB 0700 Microsoft basic data Command (? for help): q What do we make of that? Some sort of NTFS? Do these commands produce any clues or error messages? # fdisk -l /dev/sdm # tail /var/log/messages # dmesg | tail They suggested an exfat format ootb, which matches most sd cards. Thanks David, Take care. David . Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!)
On 2/9/24 04:53, gene heskett wrote: Interesting report from gdisk however: GPT fdisk (gdisk) version 1.0.9 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! *** Warning! Secondary partition table overlaps the last partition by 33 blocks! You will need to delete this partition or resize it in another utility. Command (? for help): Command (? for help): p Disk /dev/sdm: 409600 sectors, 1.9 TiB Model: SSD 3.0 Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 3230045D-589D-4601-8C4D-E9C4684B9657 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 409566 Partitions will be aligned on 64-sector boundaries Total free space is 30 sectors (15.0 KiB) Number Start (sector) End (sector) Size Code Name 1 64 409599 1.9 TiB 0700 Microsoft basic data Command (? for help): q What do we make of that? Some sort of NTFS? Do these commands produce any clues or error messages? # fdisk -l /dev/sdm # tail /var/log/messages # dmesg | tail David
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!)
On 2/8/24 15:43, Andy Smith wrote: Hello, On Thu, Feb 08, 2024 at 02:20:59PM -0500, Jeffrey Walton wrote: On Thu, Feb 8, 2024 at 11:57 AM Ralph Aichinger wrote: How does a breaking USB disk differ from a breaking SATA disk? I may be mistaken, but I believe AS is talking about USB thumb drives, SDcards and the like. I don't think he's talking about external SSD's and NVME's over USB. But I don't want to put words in his mouth. I really do mean all forms of USB that come over a USB port. I wouldn't have much issue with taking a USB drive out of its caddy to get the SATA drive from inside, except that it would have to be an amazingly good deal to make it worth voiding the warranty, so I generally wouldn't bother. If I need directly attached storage I'd much rather explore options like SAS and eSATA, or even networked storage, before I would ever consider USB for a permanent installation. Thanks, Andy OTOH. I have a couple sata-II SSD's, a kingston 256G and an adata 120G plugged into the usb-3 ports of what was an rpi3b with usb2, rigged it up first in 2016 IIRC, but swapped the rpi3b for an rpi4b in Feb 2020. I can build linuxcnc from master in around an hour, and a 4.19.120 or so kernal for the pi in a little less. And was doing that linuxcnc thing 4 to 8 times a week for several years but have stopped that with armhf since it may be dropped in favor of arm64 which isn't as good for latency, but is good enough to run linuxcnc w/o making the machine stutter from lack of data. I have had one failure, the adapter for the 120G adata, wasn't a startech, is now for around 5 years. That's beats the performance of spinning rust like a white mouthed mule. I'd had Spinning rust failures have totaled around around a dozen in triple that time frame. I built my first linux box with a 30G drive in 1998. 26 years ago. I've paid the window tax once, buying a lappy in 2002 to run a road map gps thing as I did a decade and change worth of consulting since I retired, but that lappy got its windows replaced in 2 weeks by mandrake when I found the windose xp install could not run the radio in it but mandrake could. Long found the out bin, bad ac adapter. but I got most of a decade out of it. Kept me company from the passengers seat for around 20k miles though. If these $23 drives pass the A. M. test, they will get mounted in adapters I'll have to design and print, plugged into a 8 port usb3 hub, plugged into a usb3 port of an bpi-m5, making a drive cage into a 12TB with 6 of these I bought into an amanda backup server I may hide in the bookshelves surrounding me. Headless, probably running it all on a 5v5a psu. There is a 5v8a psu being rowed across the big pond just in case. My scope watching the 5 volt line will determine the need. If they pass the test. That is YTBD. Interesting report from gdisk however: GPT fdisk (gdisk) version 1.0.9 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! *** Warning! Secondary partition table overlaps the last partition by 33 blocks! You will need to delete this partition or resize it in another utility. Command (? for help): Command (? for help): p Disk /dev/sdm: 409600 sectors, 1.9 TiB Model: SSD 3.0 Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 3230045D-589D-4601-8C4D-E9C4684B9657 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 409566 Partitions will be aligned on 64-sector boundaries Total free space is 30 sectors (15.0 KiB) Number Start (sector)End (sector) Size Code Name 1 64 409599 1.9 TiB 0700 Microsoft basic data Command (? for help): q What do we make of that? Some sort of NTFS? Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!)
On 2/8/24 11:15, Gremlin wrote: On 2/8/24 10:36, Andy Smith wrote: Hello, On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: [629241.074187] scsi host37: usb-storage 1-2:1.0 USB storage is for phones and cameras etc, not for serious computing. Many people will disagree with that statement and say they use it all the time and it is fine. They will keep saying that until it isn't fine, and then they'll be in a world of hurt. LOL, So my main desktop a raspberry pi 4 is not serious computing? Or is it that my name server, web server email server which is a raspberry pi 4 not serious computing? They both boot to USB SSDs and only have USB SSD drives, so they are not serious computing? The desktop RPI has an NVME drive as the boot drive connected by you guessed it USB. I learned not to go there a long time ago and have seen plenty of reminders along the way from others' misfortunes to not ever go there again myself. Well, most of what you attributed to me came from an earlier post. I'd never call a pi4b inadequate. Its running an 11x54 lathe just like a wintel box can. All the other stuff that makes a desktop computer, web browsing, the office suites, web server, you name it, it Just Works. Not as fast, but it works as advertised. And does all that on a 5x5 psu, with an AOC monitors whose label claim it uses 10 watts. I don't even shut them off. . Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
Hi all, Am 08.02.2024 um 21:38 schrieb Andy Smith: Hello, On Thu, Feb 08, 2024 at 05:40:54PM +0100, Ralph Aichinger wrote: On Thu, 2024-02-08 at 15:36 +, Andy Smith wrote: I learned not to go there a long time ago and have seen plenty of reminders along the way from others' misfortunes to not ever go there again myself. How does a breaking USB disk differ from a breaking SATA disk? My own experience is that it's often harder to notice and diagnose -- because on top of the actual storage and its "native" interface such as SATA or NVMe/PCIe, you have the whole stack of USB things. And misbehaving USB devices usually result in first working on the USB end -- try different port, port directly on mainboard, or a powered hub, watch out for native USB 3 or 3.0 Gen 1 -- we can see this on this mailing list, too. Then, USB storage is usually a single device single, if it breaks, it's data is lost, whereas SATA/SAS/NVMe can more easily be integrated into redundancy providing systems. On top of all that, my own, admittedly anecdotal, experience is that USB/Firewire-to-IDE/SATA adapters and their power supplies are more fragile than actual disks. Most of the external hard disks I ever used have been replaced because of their enclosures or power supplies failing. So, I tend to agree with Andy, and I also don't notice any moving goalposts in his statements... In my experience it happens more often and also brings with it frequent issues of poor performance and other reliability issues like just dropping off the USB bus. There is almost always a better way. For home users / small office environments, that leaves the problem of how to do backups -- USB drives are the most appealing storage system for such purposes, but also seem to be less reliable than the primary storage. What do you do? Throw more of the USB disks onto the problem? Or is "public" cloud the solution? Whatever you do, even purely personal storage requirements become a bit of a nightmare when you start thinking about how to make sure your photos and videos are around when your kids are grown up... Cheers, Arno Thanks, Andy -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On 2/8/24 16:28, Andy Smith wrote: Hello, On Thu, Feb 08, 2024 at 04:22:49PM -0500, Gremlin wrote: On Thu, Feb 08, 2024 at 08:43:17PM +, Andy Smith wrote: I really do mean all forms of USB that come over a USB port. That line was meant to read I really do mean all forms of storage that come over a USB port. Changing the goal post now are we. Erm no, it was a simple mistaken repetition of the word "USB" that I only noticed when I read it back. It would be clearly very difficult to refuse to use any kind of USB device at all! I have been consistently talking about storage devices. You have been very clear that you do not agree though, so let's just agree to disagree. Thanks, Andy You back pedal really well don't you! Where did you learn that?
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
Hello, On Thu, Feb 08, 2024 at 04:22:49PM -0500, Gremlin wrote: > On Thu, Feb 08, 2024 at 08:43:17PM +, Andy Smith wrote: > > I really do mean all forms of USB that come over a USB port. > > That line was meant to read > > I really do mean all forms of storage that come over a USB port. > > Changing the goal post now are we. Erm no, it was a simple mistaken repetition of the word "USB" that I only noticed when I read it back. It would be clearly very difficult to refuse to use any kind of USB device at all! I have been consistently talking about storage devices. You have been very clear that you do not agree though, so let's just agree to disagree. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On 2/8/24 16:16, Andy Smith wrote: On Thu, Feb 08, 2024 at 03:56:19PM -0500, Gremlin wrote: On 2/8/24 15:43, Andy Smith wrote: I wouldn't have much issue with taking a USB drive out of its caddy to get the SATA drive from inside, except that it would have to be an amazingly good deal to make it worth voiding the warranty, so I generally wouldn't bother. Why would it void the warranty? I put it in the caddy I mean the USB drives that come as a sealed unit that you can sometimes find a lot cheaper than the same model SATA drive that is actually inside them. Some people do enjoy taking those apart to get the SATA drive out. Thanks, Andy On Thu, Feb 08, 2024 at 08:43:17PM +, Andy Smith wrote: > I really do mean all forms of USB that come over a USB port. That line was meant to read I really do mean all forms of storage that come over a USB port. Thanks, Andy Changing the goal post now are we.
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
Hello, On Thu, Feb 08, 2024 at 04:00:01PM -0500, Gremlin wrote: > I have been using USB attached HDDs and SSDs for 10 years now and > have never had one unexpectedly go off line. Your postings > suggest you don't know what your talking about. Okay then. Despite this uncharitable comment, I do still wish you what I consider to be continued good fortune! Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On Thu, Feb 08, 2024 at 03:56:19PM -0500, Gremlin wrote: > On 2/8/24 15:43, Andy Smith wrote: > > I wouldn't have much issue with taking a USB drive out of its caddy > > to get the SATA drive from inside, except that it would have to be > > an amazingly good deal to make it worth voiding the warranty, so I > > generally wouldn't bother. > > Why would it void the warranty? I put it in the caddy I mean the USB drives that come as a sealed unit that you can sometimes find a lot cheaper than the same model SATA drive that is actually inside them. Some people do enjoy taking those apart to get the SATA drive out. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On 2/8/24 15:35, Andy Smith wrote: Hello, On Fri, Feb 09, 2024 at 12:23:45AM +0700, Max Nikulin wrote: On 08/02/2024 22:36, Andy Smith wrote: On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: [629241.074187] scsi host37: usb-storage 1-2:1.0 USB storage is for phones and cameras etc, not for serious computing. Do you mean that a proper backup drive should use uas (USB Attached Storage) instead of usb-storage driver? No, I just mean I advise to never ever use storage that comes to you via a USB port for anything you care about. I might consider it okay for temporary shifting of data about, but I would never use it as part of a permanent setup without fully expecting one day to find it just not working. But then that is also how I feel about any storage device. It's just worse when USB is added to the mix. I have been using USB attached HDDs and SSDs for 10 years now and have never had one unexpectedly go off line. Your postings suggest you don't know what your talking about.
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On 2/8/24 15:43, Andy Smith wrote: Hello, On Thu, Feb 08, 2024 at 02:20:59PM -0500, Jeffrey Walton wrote: On Thu, Feb 8, 2024 at 11:57 AM Ralph Aichinger wrote: How does a breaking USB disk differ from a breaking SATA disk? I may be mistaken, but I believe AS is talking about USB thumb drives, SDcards and the like. I don't think he's talking about external SSD's and NVME's over USB. But I don't want to put words in his mouth. I really do mean all forms of USB that come over a USB port. I wouldn't have much issue with taking a USB drive out of its caddy to get the SATA drive from inside, except that it would have to be an amazingly good deal to make it worth voiding the warranty, so I generally wouldn't bother. Why would it void the warranty? I put it in the caddy If I need directly attached storage I'd much rather explore options like SAS and eSATA, or even networked storage, before I would ever consider USB for a permanent installation. You need to start thinking outside the box.
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On Thu, Feb 08, 2024 at 08:43:17PM +, Andy Smith wrote: > I really do mean all forms of USB that come over a USB port. That line was meant to read I really do mean all forms of storage that come over a USB port. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
Hello, On Thu, Feb 08, 2024 at 02:20:59PM -0500, Jeffrey Walton wrote: > On Thu, Feb 8, 2024 at 11:57 AM Ralph Aichinger wrote: > > How does a breaking USB disk differ from a breaking SATA disk? > > I may be mistaken, but I believe AS is talking about USB thumb drives, > SDcards and the like. I don't think he's talking about external SSD's > and NVME's over USB. But I don't want to put words in his mouth. I really do mean all forms of USB that come over a USB port. I wouldn't have much issue with taking a USB drive out of its caddy to get the SATA drive from inside, except that it would have to be an amazingly good deal to make it worth voiding the warranty, so I generally wouldn't bother. If I need directly attached storage I'd much rather explore options like SAS and eSATA, or even networked storage, before I would ever consider USB for a permanent installation. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
Hello, On Thu, Feb 08, 2024 at 05:40:54PM +0100, Ralph Aichinger wrote: > On Thu, 2024-02-08 at 15:36 +, Andy Smith wrote: > > I learned not to go there a long time ago and have seen plenty of > > reminders along the way from others' misfortunes to not ever go > > there again myself. > > How does a breaking USB disk differ from a breaking SATA disk? In my experience it happens more often and also brings with it frequent issues of poor performance and other reliability issues like just dropping off the USB bus. There is almost always a better way. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
Hello, On Fri, Feb 09, 2024 at 12:23:45AM +0700, Max Nikulin wrote: > On 08/02/2024 22:36, Andy Smith wrote: > > On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: > > > [629241.074187] scsi host37: usb-storage 1-2:1.0 > > > > USB storage is for phones and cameras etc, not for serious > > computing. > > Do you mean that a proper backup drive should use uas (USB Attached Storage) > instead of usb-storage driver? No, I just mean I advise to never ever use storage that comes to you via a USB port for anything you care about. I might consider it okay for temporary shifting of data about, but I would never use it as part of a permanent setup without fully expecting one day to find it just not working. But then that is also how I feel about any storage device. It's just worse when USB is added to the mix. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On Thu, Feb 8, 2024 at 11:57 AM Ralph Aichinger wrote: > > On Thu, 2024-02-08 at 15:36 +, Andy Smith wrote: > > USB storage is for phones and cameras etc, not for serious > > computing. Many people will disagree with that statement and say > > they use it all the time and it is fine. > > I am clearly in the latter camp. This mail is delivered via a Raspberry > Pi 4 that has a 500G USB SSD. Before the Pi4 I used a Pi3 and a Pi2 (I > think) with USB disks (first rotating, then SSD). Probably for 5 years > or so. Never had a problem (unlike with the SD cards I used before, SD > cards always died on me from to many writes after a few months). > > > They will keep saying that > > until it isn't fine, and then they'll be in a world of hurt. > > This is the same with any hard disk or SSD. If you buy the most > expensive "enterprise" disk, with SAS or whatever, it still can > break on the next day, taking all your data with you. > > Actually with USB disks, sometimes you can remove the USB > controller, replace it in case of breakage, giving you more > or less the same reliability as any "normal" disk. > I've never had USB controllers break, though, so I do not > care. I just take backups as with any other disk. > > > I learned not to go there a long time ago and have seen plenty of > > reminders along the way from others' misfortunes to not ever go > > there again myself. > > How does a breaking USB disk differ from a breaking SATA disk? I may be mistaken, but I believe AS is talking about USB thumb drives, SDcards and the like. I don't think he's talking about external SSD's and NVME's over USB. But I don't want to put words in his mouth. My experience with SDcards and thumb drives is along the lines of AS's. I own a lot of dev boards (dating back to the early 2010's) for testing, and I could go through a storage device, like an SDcard, in about 6 months. But I would also add a swap file to the installation because the dev boards were so resource constrained. You simply can't run a C++ compiler on a Beagleboard with 256MB of RAM. The swap file, even with a low swappiness, would eat up SDcards and thumb drives. Jeff
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On 08/02/2024 22:36, Andy Smith wrote: On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: [629241.074187] scsi host37: usb-storage 1-2:1.0 USB storage is for phones and cameras etc, not for serious computing. Do you mean that a proper backup drive should use uas (USB Attached Storage) instead of usb-storage driver?
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
On Thu, 2024-02-08 at 15:36 +, Andy Smith wrote: > USB storage is for phones and cameras etc, not for serious > computing. Many people will disagree with that statement and say > they use it all the time and it is fine. I am clearly in the latter camp. This mail is delivered via a Raspberry Pi 4 that has a 500G USB SSD. Before the Pi4 I used a Pi3 and a Pi2 (I think) with USB disks (first rotating, then SSD). Probably for 5 years or so. Never had a problem (unlike with the SD cards I used before, SD cards always died on me from to many writes after a few months). > They will keep saying that > until it isn't fine, and then they'll be in a world of hurt. This is the same with any hard disk or SSD. If you buy the most expensive "enterprise" disk, with SAS or whatever, it still can break on the next day, taking all your data with you. Actually with USB disks, sometimes you can remove the USB controller, replace it in case of breakage, giving you more or less the same reliability as any "normal" disk. I've never had USB controllers break, though, so I do not care. I just take backups as with any other disk. > I learned not to go there a long time ago and have seen plenty of > reminders along the way from others' misfortunes to not ever go > there again myself. How does a breaking USB disk differ from a breaking SATA disk? /ralph
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!)
Hi, On Thu, Feb 08, 2024 at 11:14:24AM -0500, Gremlin wrote: > On 2/8/24 10:36, Andy Smith wrote: > > USB storage is for phones and cameras etc, not for serious > > computing. Many people will disagree with that statement and say > > they use it all the time and it is fine. They will keep saying that > > until it isn't fine, and then they'll be in a world of hurt. > > > > LOL, So my main desktop a raspberry pi 4 is not serious computing? Or is it > that my name server, web server email server which is a raspberry pi 4 not > serious computing? Not in my opinion, no¹, but I don't mind at all if you don't agree and I also wish you the best of ongoing luck! Thanks, Andy ¹ Of course, sometimes you just have a device that only has USB and there's no way around it. If I have to go there, I try to make it serious by preparing for the storage of those devices to just disappear one day and take steps to minimise the downtime lost to that. -- https://bitfolk.com/ -- No-nonsense VPS hosting
