temp64 | is there a way to figure out what's causing a "target is busy" error to appear when trying to unmount a device? | 18:22 |
---|---|---|
temp64 | I know I can use lsof to check if there are any file descriptors open on /dev/<whatever> | 18:22 |
temp64 | but I have no idea how to prevent a /media/tmpfs/file associated with /dev/loop0 from stopping umount /media/tmpfs | 18:24 |
___used | those are 2 questions? | 18:25 |
___used | you can open the /media/tmpfs/file itself on a fdesc and leave it open in a shell script, that will stop umounting | 18:26 |
nemo | sounds to me like something inside the device is being mounted itself | 18:28 |
___used | lsof will show it | 18:28 |
___used | also fuser -vn might help | 18:28 |
nemo | like... let's say you shoved in an SD card, then, doubeclicked in an ISO in, oh, MATE... that would cause a double mount I think... | 18:28 |
nemo | would have to test that one | 18:28 |
nemo | anyway. fix seems simple enough, unmount the inner mount before unmounting the outer one ☺ | 18:29 |
nemo | and figure out what's mounting that inner one first | 18:29 |
temp64 | I mean, /media/tmpfs is tmpfs, /media/tmpfs/file is 8GB worth of 0s that got slapped onto /dev/loop0 via losetup | 18:30 |
temp64 | lsof +f -- /media/tmpfs outputs nothing | 18:30 |
temp64 | umount /media/tmpfs fails | 18:30 |
nemo | temp64: you didn't mention losetup until now... | 18:31 |
temp64 | if I didn't know I mounted the /media/tmpfs/file on a loop device, I'd have no idea how to unmount it | 18:31 |
nemo | so... losetup --detach /dev/loop0 ? | 18:31 |
temp64 | sorry :| | 18:31 |
temp64 | yeah, but is there a way to automatically detect that there is some /dev/loop magic going on? | 18:32 |
nemo | well. losetup -D probably would work better as long as nothing else is using it | 18:32 |
temp64 | (under this particular path that is) | 18:33 |
nemo | for a question that vaguely worded, kind of impossible to answer | 18:33 |
nemo | but... losetup -j ? | 18:33 |
___used | lsof -f is not right... | 18:33 |
nemo | just guessing at what you mean though | 18:34 |
nemo | home/nemo# losetup -l | 18:35 |
nemo | NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC | 18:35 |
temp64 | oh, that could work | 18:35 |
nemo | /dev/loop0 0 0 0 1 /home/nemo/Downloads/devuan_beowulf_3.1.1_amd64_minimal-live.iso 0 512 | 18:35 |
nemo | after right clicking on an iso and choosing disc mounter in MATE | 18:35 |
nemo | which, in MATE shows up as a nice little eject icon in the file manager | 18:35 |
temp64 | yeah, that was it, thanks | 18:37 |
nemo | is dædalus essentially stable now? | 18:39 |
nemo | hmm better question... is there a list of stabilisation blockers somewhere in an issue tracker that I could look at, to see if I care about any of them? | 18:40 |
nemo | hm. I tried to figure that out for myself, but https://bugs.devuan.org/cgi/pkgreport.cgi?which=tag&data=daedalus returns nothing, surprisingly | 18:49 |
nemo | https://bugs.devuan.org/cgi/pkgreport.cgi?status=open has some stuff, some of which looks dædalus related 689 - although that one isn't actually open, last comment confirms a fix, so I guess no one closed the bug yet | 18:52 |
nemo | hm. that bug is really old. n/m | 18:52 |
nemo | yeah... I have no idea how to find a blocker list | 18:53 |
Xenguy | lsof and fuser | 19:08 |
* Xenguy skips the details of the convo... | 19:08 | |
temp64 | does -o sync have any effect on tmpfs? | 19:37 |
temp64 | like, does the concept of pending I/O even apply in this case? | 19:38 |
temp64 | I wonder if it would sometimes fail to unmount right after writing a bunch of GBs to it | 19:39 |
nemo | oh yay. he's back | 20:11 |
nemo | or not | 20:11 |
nemo | and back again | 20:16 |
nemo | fsmithred: I was trying to figure out if the remaining dædalus blockers are ones I would personally be worried about, but was having a hard time finding that list.. https://bugs.devuan.org/cgi/pkgreport.cgi?which=tag&data=daedalus returned nothing, which was my first guess | 20:16 |
nemo | so. figured I'd ask you when you got back | 20:16 |
* nemo sighs | 20:17 | |
nemo | maybe he's testing dædalus ☺ | 20:17 |
rustyaxe | wait.. yall dont run /testing on your workstations? :( | 20:23 |
fsmithred_ | nemo | 20:26 |
fsmithred_ | sorry for bad connection | 20:27 |
fsmithred_ | looks like you didn't get any of what I said | 20:27 |
fsmithred_ | I think three of the blockers were my packages and they got moved into daedalus | 20:27 |
fsmithred_ | snapshot, installer and desktop-base were on the list | 20:27 |
fsmithred_ | I forget what the fourth one was. | 20:27 |
fsmithred_ | was in the meeting notes week before last. | 20:28 |
fsmithred_ | I think | 20:28 |
fsmithred_ | I've been running daedalus on my local build host for months | 20:29 |
fsmithred_ | AFAIK only the docs and isos are not complete. | 20:29 |
fsmithred_ | brb | 20:29 |
fsmithred | nemo, those were not blockers. They were things that needed to be migrated into daedalus after freeze. | 20:37 |
nemo | fsmithred: oh cool. so no blockers | 20:46 |
nemo | fsmithred: so if I switched a production server to dædalus now, it wouldn't be a crazy thing to do. I have an open ticket to update a dozen VMs at work | 20:46 |
fsmithred | I don't know of any | 20:46 |
fsmithred | https://pkgmaster.devuan.org/britney/daedalus/excuses.html | 20:46 |
fsmithred | I'm not sure of what's happening with the things on that list | 20:47 |
nemo | ah. perfect. that's the sort of list I was looking for | 20:47 |
nemo | only one of those I'd care about on these servers, I think, would be base-files ☺ | 20:47 |
fsmithred | new base-files got built last week and is in the rc1 live-isos I made but haven't put in public location yet | 20:49 |
fsmithred | I'm guessing that new installer isos will be built tomorrow (monday) as usual. | 20:50 |
fsmithred | check with rrq in a few hours | 20:50 |
nemo | fsmithred: awesome. well, they gave me a few weeks to do it so. should be fine ☺ | 20:53 |
nemo | people are antsy for new php and tomcat ☺ | 20:54 |
fsmithred | I just checked - newest base-files has been moved to daedalus from daedalus-proposed-updates | 20:54 |
fsmithred | uhh, check tomcat | 20:54 |
rustyaxe | Looks like im about to have fun..rebooting to single user, shrinking /home on lvm/ext4 and growing / | 20:54 |
rustyaxe | /dev/mapper/orc--vg-root 28G 26G 151M 100% / | 20:54 |
rustyaxe | oof. | 20:54 |
fsmithred | ah, it's called tomcat10 and it's in daedalus | 20:55 |
fsmithred | Candidate: 10.1.6-1 | 20:55 |
nemo | fsmithred: yeah. it's that thing debian likes to do with major versions where people are version tied ☺ | 20:56 |
nemo | same w/ java and such | 20:56 |
nemo | rustyaxe: huh. where'd all your space go? /var/cache ? | 20:56 |
nemo | /var/lib/postgresql ? | 20:56 |
rustyaxe | nemo: mostly packages. multiple toolchains will do that.. Didnt catch / being so small when installed on the new laptop, as was in a hurry to get going | 20:58 |
rustyaxe | before i go, i resized the other drive's windows install down to a more reasonable size, slapped an ext4 in the free space and backing up.. Then we can do the needful ;) | 20:59 |
nemo | rustyaxe: one nice thing is that these days resizing / live is actually pretty safe | 21:02 |
nemo | rustyaxe: I've done it to servers before without any issues after shutting everything down except my ssh session | 21:02 |
fsmithred | and exciting | 21:02 |
nemo | 😃 | 21:02 |
nemo | well yes. I did make sure we had a snapshot first | 21:02 |
nemo | but it was easier than going through the boot hassle | 21:02 |
fsmithred | yeah, the server can keep servinmg | 21:02 |
nemo | fsmithred: it was mostly 'cause accessing it in single user or CD was a pain | 21:06 |
nemo | fsmithred: I did schedule downtime just 'cause I figured "what if" | 21:06 |
nemo | but yeah, it probably could have actually kept serving content | 21:06 |
n4dir | don't forget to play the song "so what" in case you think "what if" | 21:07 |
fsmithred | lol | 21:07 |
nemo | heh. well. worst case it all buggered up, I reverted to snapshot, and we did it the tedious way | 21:07 |
nemo | yay for VMs | 21:07 |
rustyaxe | [86753.804356] udevd[777]: specified group 'sgx' unknown | 21:08 |
___used | next you'll want a docker container for it... </kidding> | 21:08 |
n4dir | i got a question not really devuan related: i created an irc account, i automatically log in and identify with sasl, all that works. But the last message of irssi/liberachat is: username is in use by UNKNOW". I do /msg NickServ release, then i can use said username. Anyone can tell me something about it? | 21:08 |
rustyaxe | it appears to be virtualization related | 21:08 |
___used | n4dir: ask in #help, someone auto squats on your nick. Usually nothing can be done. | 21:09 |
n4dir | ___used: "nothing can be done", so my best bet is to create another account? | 21:10 |
___used | change a few letters in your registered nick | 21:10 |
n4dir | i thought if you have a password only you could use it | 21:10 |
rustyaxe | you just have to nicely ask services to rename them (recover command) | 21:11 |
___used | yes but that does not prevent a**h***s from squatting on it for 60 seconds or whatever the enforcement is set to | 21:11 |
n4dir | rename who and how? | 21:11 |
rustyaxe | regain rather | 21:11 |
rustyaxe | Whatever client currently is using the nickname | 21:12 |
___used | you can regain it yourself | 21:12 |
___used | once registered | 21:12 |
rustyaxe | Ya | 21:12 |
n4dir | the command would be? | 21:12 |
rustyaxe | /msg nickserv help | 21:12 |
rustyaxe | you want to look at register and regain commands | 21:12 |
rustyaxe | but good to see it all | 21:12 |
___used | /msg NickServ RELEASE yournick | 21:12 |
___used | /msg NickServ REGAIN yournick | 21:13 |
___used | in that order | 21:13 |
n4dir | will it suffice to run that once, or do i still have to do it each time? | 21:13 |
___used | every time | 21:13 |
n4dir | yeah, well, then not that much is gained. | 21:13 |
___used | just put that in your autologon script. | 21:14 |
___used | with sleep 1 or 2 in between | 21:14 |
n4dir | what is the autologon script? | 21:14 |
___used | irssi? | 21:14 |
n4dir | yup | 21:15 |
___used | https://irssi.org/documentation/manual/automation/ | 21:15 |
___used | really off topic here I think. Also #irssi | 21:16 |
fsmithred | bbl | 21:25 |
rustyaxe | all sorted, back to normal operations | 21:37 |
brgs | 21:q | 22:36 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!