External hard drive not detected in debian 12 live environment
Hello, I have a new external hard drive "Western Digital My Passport Ultra" that doesn't seem to detect in any way when I plug it into a live debian 12 environment. If I run `journalctl -f` or `lsusb` or `lssci` or really anything else I can think of I can't find any evidence that the system itself is detecting the drive at any level. I currently have popOS on the laptop (the point of the live CD is to install debian 12 instead) which does just automatically detect it, mount it, etc. I can't seem to figure out what is different between the systems. I feel like there must be some kernel module or custom software or something which I might need to manually install in the debian version of the kernel, but I can't figure it out. Is anyone here more familiar with this sort of stuff that can help point me in the right direction? Here is some info about the popOS system: ``` $ lsb_release -a No LSB modules are available. Distributor ID: Pop Description:Pop!_OS 21.10 Release:21.10 Codename: impish $ uname -r 5.17.15-76051715-generic ``` Here are some kernel logs when plugging in the drive to the popOS system: ``` Jul 15 13:39:25 pop-os kernel: usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd Jul 15 13:39:25 pop-os kernel: usb 2-1: New USB device found, idVendor=1058, idProduct=260d, bcdDevice=20.07 Jul 15 13:39:25 pop-os kernel: usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Jul 15 13:39:25 pop-os kernel: usb 2-1: Product: My Passport 260D Jul 15 13:39:25 pop-os kernel: usb 2-1: Manufacturer: Western Digital Jul 15 13:39:25 pop-os kernel: usb 2-1: SerialNumber: 57584332443433414C4A5244 Jul 15 13:39:25 pop-os kernel: usb-storage 2-1:1.0: USB Mass Storage device detected Jul 15 13:39:25 pop-os kernel: scsi host1: usb-storage 2-1:1.0 Jul 15 13:39:25 pop-os mtp-probe[2753]: checking bus 2, device 2: "/sys/devices/pci:00/:00:0d.0/usb2/2-1" Jul 15 13:39:25 pop-os mtp-probe[2753]: bus: 2, device: 2 was not an MTP device Jul 15 13:39:25 pop-os mtp-probe[2757]: checking bus 2, device 2: "/sys/devices/pci:00/:00:0d.0/usb2/2-1" Jul 15 13:39:25 pop-os mtp-probe[2757]: bus: 2, device: 2 was not an MTP device Jul 15 13:39:26 pop-os kernel: scsi 1:0:0:0: Direct-Access WD My Passport 260D 2007 PQ: 0 ANSI: 6 Jul 15 13:39:26 pop-os kernel: scsi 1:0:0:1: Enclosure WD SES Device 2007 PQ: 0 ANSI: 6 Jul 15 13:39:26 pop-os kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0 Jul 15 13:39:26 pop-os kernel: scsi 1:0:0:1: Attached scsi generic sg2 type 13 Jul 15 13:39:26 pop-os kernel: sd 1:0:0:0: [sdb] Spinning up disk... Jul 15 13:39:31 pop-os kernel: .ready Jul 15 13:39:31 pop-os kernel: sd 1:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Jul 15 13:39:31 pop-os kernel: sd 1:0:0:0: [sdb] 9767475200 512-byte logical blocks: (5.00 TB/4.55 TiB) Jul 15 13:39:31 pop-os kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks Jul 15 13:39:31 pop-os kernel: sd 1:0:0:0: [sdb] Write Protect is off Jul 15 13:39:31 pop-os kernel: sd 1:0:0:0: [sdb] Mode Sense: 3f 00 10 00 Jul 15 13:39:31 pop-os kernel: sd 1:0:0:0: [sdb] No Caching mode page found Jul 15 13:39:31 pop-os kernel: sd 1:0:0:0: [sdb] Assuming drive cache: write through Jul 15 13:39:31 pop-os kernel: sdb: sdb1 Jul 15 13:39:31 pop-os kernel: sd 1:0:0:0: [sdb] Attached SCSI disk Jul 15 13:39:31 pop-os kernel: scsi 1:0:0:1: Wrong diagnostic page; asked for 1 got 8 Jul 15 13:39:31 pop-os kernel: scsi 1:0:0:1: Failed to get diagnostic page 0x1 Jul 15 13:39:31 pop-os kernel: scsi 1:0:0:1: Failed to bind enclosure -19 Jul 15 13:39:31 pop-os kernel: ses 1:0:0:1: Attached Enclosure device Jul 15 13:39:32 pop-os kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Quota mode: none. ``` Does anyone here know a good place to start to debug this? Thanks for any help! Cheers, Thomas
Re: How to increase hard NOFILE limit in debian 11?
Thanks for the help! That worked well with bash (i.e. if I set both /etc/security/limits.conf and /etc/sysctl.conf, then `ulimit -aH` returns what you'd expect). However, I have a server process and when I check its limits by looking at `/proc/$PID/limits`, the hard limit is not raised there. I have figured out that I can raise it by executing e.g. `prlimit --pid=$PID --nofile=1024:16777216`, but I haven't found a way for it to make it stick across reboots. The process itself is running as root. Is this an issue of the server process itself changing its own hard limit somewhere? Or is there another system change that could help? Thanks again this is great! Cheers, Thomas
How to increase hard NOFILE limit in debian 11?
Hello,
I'm running stock debian 11:
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename: bullseye
$ uname -r
5.10.0-19-cloud-amd64
```
I have the following default hard limit on open files:
```
$ ulimit -Hn
1048576
```
I would like to increase that (and not just for my bash process), but no
matter what I try after searching online, I'm unable to change it. I've
tried changing this in `/etc/security/limits.conf`, in
`/etc/systemd/{system,user}.conf`, and I've tried using `prlimit` to
directly change the limits for the process in question (receiving an
error when doing so).
Does anyone here know how to increase the hard limit on open files for
processes running debian 11? Thanks for any help!
Cheers,
Thomas
How to build linux kernal package
Hello, Here is some system information: $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 9.8 (stretch) Release:9.8 Codename: stretch I'm trying to rebuild the currently installed linux kernal package from source and am running into some issues. I've been reading the debian policy here: https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules I did the following steps: $ apt source linux-image-$(uname -r) $ cd linux-4.9.144 $ DEB_BUILD_OPTIONS="parallel=4" debian/rules build This results in a lot of stuff being printed, but the following is most interesting: make[3]: Leaving directory '/home/twn/src/linux/linux-4.9.144/debian/build/build_amd64_rt_amd64' debian/bin/buildcheck.py debian/build/build_amd64_rt_amd64 amd64 rt amd64 ABI is not completely versioned! Refusing to continue. [ ... I CUT OUT SOME STUFF ... ] debian/rules.real:190: recipe for target 'debian/stamps/build_amd64_rt_amd64' failed make[2]: *** [debian/stamps/build_amd64_rt_amd64] Error 1 make[2]: Leaving directory '/home/twn/src/linux/linux-4.9.144' debian/rules.gen:394: recipe for target 'build-arch_amd64_rt_amd64_real' failed make[1]: *** [build-arch_amd64_rt_amd64_real] Error 2 make[1]: Leaving directory '/home/twn/src/linux/linux-4.9.144' debian/rules:41: recipe for target 'build-arch' failed make: *** [build-arch] Error 2 So I guess I have a few questions: 1. If someone here knows the specific issue with the linux package, what am I doing wrong here? 2. Is there a general procedure e.g. `debian/rules build && debian/rules binary` which _should_ work (in other words if it doesn't work, it's a bug). Or is the specific build procedure package dependent? 3. If the procedure is package dependent, where is it documented? I guess there must be scripts somewhere on some build servers that build this...are they accessible somewhere? Let me know if you'd like more information. Thanks for any help! Cheers, Thomas
Re: How to remove extra files created when building a package?
On 06/29/2017 09:34 PM, Greg Wooledge wrote: > On Thu, Jun 29, 2017 at 09:30:26PM +0200, Thomas Nyberg wrote: >> $ for file in $(find . -name '*.pyc'); do rm -v $file; done >> $ for file in $(find . -name '*.o'); do rm -v $file; done >> $ for file in $(find . -name '*.so'); do rm -v $file; done > > *cringe* No, no, no > > find . -name '*.pyc' -print -delete > > http://mywiki.wooledge.org/BashPitfalls#pf1 > Thanks for the the information. In my case it didn't matter since the file names were all "standard" (I looked at them), but I'll try to remember this going forward. Cheers, Thomas
Re: How to remove extra files created when building a package?
Thanks for all the helpful info! On 06/29/2017 09:15 PM, Sven Joachim wrote: > On 2017-06-29 20:36 +0200, Thomas Nyberg wrote: > > In my experience, if you are serious about changing packages it's always > better to create a git repository, if only temporarily. Ideally clone > the existing one mentioned in the Vcs-Git header, but this might be too > big or too outdated, not even containing the changes from the latest > upload. Or create your own from scratch, e.g. with > "git init; git add .; git commit -a -m 'Initial Import'" . > I see. Yes the easiest would probably be to remember to always initialize a fresh repository. Or I could also just copy the directory itself before messing around (since I don't care much beyond the original version in a simple patch like the one I applied). > > If you have already built the source package, the easiest way is to > throw away the mess in the current directory and unpack afresh. > This is what I would have done, but I'm currently on a pretty bad internet connection. I originally downloaded the package with $ apt-get source thunderbird That produced a few different files in the directory I was in. The one that I messed with was the `icedove-45.8.0/` directory. Is there a way to regenerate the `icedove-45.8.0` in its original state from the others? > > Yes, that is considered a bug. Debian Policy §4.9[1] states the > following about the clean target: > > , > | clean (required) > | > | This must undo any effects that the build and binary targets may > | have had, except that it should leave alone any output files > | created in the parent directory by a run of a binary target. > | > | If a build file is touched at the end of the build target, as > | suggested above, it should be removed as the first action that > | clean performs, so that running build again after an interrupted > | clean doesn't think that everything is already done. > ` > > However, with the rise of packaging helpers like git-buildpackage, > people seemed to have stopped caring about this problem since they > always build the package in a scratch space. And this approach (which, > incidentally, has been used in the RPM world for ages) certainly has its > merits, since it completely sidesteps the problem of backing out any > changes the build process makes to the source tree. > Does it make sense to provide a bug report? I agree with you that it is a bug according to the policy, but if the community is moving away from this process, maybe I'd just be a pain? Thanks again for all the information! Cheers, Thomas
Re: How to remove extra files created when building a package?
Okay it looks like I solved the problem myself, but figured that I should recored it in the list for posterity. The first problem I had (even before the current question), was that I got errors that all started with: "dpkg-source: error: cannot represent change to ..." This seemed to have to do with binary files that were created, but now removed. In this case they were all *.pyc, *.o, *.so files. I removed them by running: $ for file in $(find . -name '*.pyc'); do rm -v $file; done $ for file in $(find . -name '*.o'); do rm -v $file; done $ for file in $(find . -name '*.so'); do rm -v $file; done After that it produced the error output in my last email. At that point I did as it asked. I.e. I executed this: $ dpkg-source --commit I called the commit "trash" and then didn't add a commit message. However this now left the commit applied to the code which I did not want. So then I ran $ quilt delete which deleted that last applied commit (i.e. "trash"). This seems to have put me back where I started (on my own final commit which I actually did want). This seems to work, but it seems odd that it's necessary. Possibly there's something smarter? Cheers, Thomas
How to remove extra files created when building a package?
Hello, I am trying to build the thunderbird package with some modifications. I made the modifications and commited the changes to a local patch, but then during the build (using `debuild -uc -us`) I ran out of space. I ran `debuild clean` and then deleted different things on my computer and then tried to run the build again, but this time it no longer even starts. It immediately complains about files that were changed. It prints out the files that are changed and provides a patch file `/tmp/icedove_45.8.0-3~deb8u1.diff.fG4ELW` and asks if I want to commit the changes with `dpkg-source --commit`. I don't, however, see any way to throw away these changes. How do I do this? If I used git, I would do something like `git stash; git stash drop`. Another approach would be to apply this patch file in reverse, but I'm not sure how to do that. How do I revert these changes? Is there no option for this in `dpkg-source`? I'm posting the entirety of the error printout below. Thanks for any help. Also on another note, would this be considered a bug in the debian packaging? It seems to me really odd that I wouldn't be able to run `debuild clean; debuild` and have it work again. Cheers, Thomas Here is the error printout: $ time debuild -uc -us dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: source package icedove dpkg-buildpackage: source version 1:45.8.0-3~deb8u1 dpkg-buildpackage: source distribution jessie-security dpkg-buildpackage: source changed by Guido Günther dpkg-source --before-build icedove-45.8.0 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory '/home/twn/thunderbird/icedove-45.8.0' dh_auto_clean --builddirectory=obj-thunderbird # needed for thunderbird-l10n rm -rf debian/thunderbird-l10n-build # needed for lightning-l10n rm -rf debian/lightning-l10n-build make[1]: Leaving directory '/home/twn/thunderbird/icedove-45.8.0' dh_clean dpkg-source -b icedove-45.8.0 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building icedove using existing ./icedove_45.8.0.orig-icedove-l10n.tar.xz ./icedove_45.8.0.orig-iceowl-l10n.tar.xz ./icedove_45.8.0.orig.tar.xz dpkg-source: warning: executable mode 0755 of 'build/autoconf/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/build/autoconf/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/build/autoconf/config.sub.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/ipc/chromium/src/third_party/libevent/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/ipc/chromium/src/third_party/libevent/config.sub.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/js/src/ctypes/libffi/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/js/src/ctypes/libffi/config.sub.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/memory/jemalloc/src/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/memory/jemalloc/src/config.sub.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/modules/freetype2/builds/unix/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/modules/freetype2/builds/unix/config.sub.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/nsprpub/build/autoconf/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/nsprpub/build/autoconf/config.sub.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/toolkit/crashreporter/google-breakpad/autotools/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/toolkit/crashreporter/google-breakpad/autotools/config.sub.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/toolkit/crashreporter/google-breakpad/src/third_party/glog/config.guess.dh-orig' will not be represented in diff dpkg-source: warning: executable mode 0755 of 'mozilla/toolkit/crashreporter/google-breakpad/src/third_party/glog/config.sub.dh-orig' will not be represented in diff dpkg-source: info: local changes detected, the modified files are: icedove-45.8.0/build/autoconf/config.guess icedove-45.8.0/build/autoconf/config.guess.dh-orig icedove-45.8.0/mozconfig.default icedove-45.8.0/mozconfig.thunderbird icedove-45.8.0/mozilla/build/autoconf/config.guess icedove-45.8.0/mozilla/build/autoconf/config.guess.dh-orig icedove-45.8.0/mozilla/build/autoconf/config.sub icedov
