this is #debianan IRC-Channel at freenode (freenode IRC service closed 2021-06-01)
0[00:00:12] <rwp> As an alternative... I have had really quite good success with USB WiFi dongles. One of the little button ones are low profile. Free drivers available for them.
1[00:00:13] *** Quits: v01t (~v01t@replaced-ip) (Remote host closed the connection)
4[00:00:52] <rwp> Be careful about shopping for those however. One of the popular ones for Raspberry Pi use is the Edimax and it works with the driver there. But that driver is not in the Linux kernel main yet.
13[00:03:16] <Bjornn> in the process of well debugging, and then desperation, I updated to the latest and greatest kernel which had issue that I mentioned about but otherwise functions well when booted with ethernet
28[00:07:59] <Bjornn> 4.9.0-0.bpo.2-amd64 is what it shows I don't remember how I got to that now, it was so long ago
29[00:08:41] <rwp> That's a backports kernel. It's good too. Let me check to see if it is the latest or not.
30[00:10:11] <Bjornn> the thing opens a half a dozen files at boot and searches for a token one line at a time, it takes 90 seconds or so to boot with it.
47[00:16:13] <crayon> removed from test before 0.24.x was cleared for migration?
48[00:16:20] <SerajewelKS> crayon: which release are you using?
49[00:17:01] <SerajewelKS> sysdig is in stable and unstable, but not testing -- so i assume you are using testing?
50[00:17:08] <crayon> i was on 0.21.0-1 before it was removed
51[00:17:20] <crayon> oh, repo?
52[00:17:30] <crayon> kali-rolling
53[00:17:31] <ryouma> i have confirmed that a partition (sde1) is mounted like /media/8d345dc5-2de8-4d22-8dc1-dd5944dd49c0 for no apparent reason. today it occurred an hour or so after booting. can i turn this thing off? i don't want it mounted.
63[00:19:07] <dpkg> Your distribution may be based on and have software in common with Debian, but it is not Debian. We don't and cannot know what changes were made by your distribution (compare replaced-url
64[00:19:24] <crayon> kali-rolling follows debian test
65[00:19:31] <crayon> im looking to find out why it was removed from testing
70[00:21:36] <SerajewelKS> IIRC, something will get removed from testing if its dependencies become unsatisfiable, but the version in unstable cannot be pushed to testing, for reasons such as the presence of RC bugs
71[00:22:10] <crayon> thanks for your help i appreciate it. should i just compile it myself then?
72[00:22:28] <SerajewelKS> you could. note that the RC bugs might still affect you, especially if they are upstream from debian.
83[00:32:51] <rwp> Cool! However if the graphical didn't start that may bode ill of the onboard graphics driver. May be non-free, may be unavailable.
84[00:33:08] <rwp> But you will have a headless server on the net either way! :-)
85[00:33:34] <j0seph> rwp: the live session started with no problems
86[00:33:42] <j0seph> and i goofed around for a short time with it
87[00:34:04] <rwp> That is good to hear. In that case things should be good to go. The live boot is a good test.
88[00:34:14] <j0seph> I'm installing non-free stuff components with it, just to be on the safe side
89[00:34:26] <j0seph> running those doesn't tend to make me lose sleep
90[00:35:06] <rwp> I am by training and career a vlsi designer and those binary blobs are just part of the design in my opinion.
91[00:35:28] <rwp> Having etched off the passivation layer and microprobed on vlsi circuits I will say it takes a steady hand.
92[00:35:56] <rwp> Anyone who thinks they are going to modify those without access to the original designs and the team of people working them is confused about what they are working with.
93[00:36:17] <watchcat> i'm of the 'avoid when possible, use when necessary' school of blobism.
95[00:37:09] <j0seph> i like to think i'm of the same school, but in reality i don't want to wait and find out. i just like to sit down and get on with my life. which makes me call into question why I used arch for so long..
96[00:37:30] * rwp actually laughs out loud
97[00:38:03] <rwp> I have a couple of good friends who use ArchLinux and sometimes I hear stories...
100[00:39:03] <j0seph> maybe I wanted to be in on that whole "arch linux is a real techie's distro, and anything else easier than it is designed for babies" crowd. then I slowly realised I was spending more time 'tweaking' and 'fixing' my system than I was getting work done and being productive.
206[01:33:11] <trysten> so if I have Mesa 18.2.6 but opengl version 2.1.. am I screwed? Is it true that my laptop won't support opengl3+ until someone does serious driver work?
284[01:55:54] <trysten> liamliamliam: I was ambigious. you can type 'echo test | xclip -i -selection clipboard' and 'xclip -o -selection clipboard' on seperate lines
296[01:58:06] <liamliamliam> yah, i'm goign to try that!
297[01:58:11] <liamliamliam> it's so wierd, i did all that before, and only in buster
298[01:58:13] <liamliamliam> it's not working
299[01:58:23] <trysten> liamliamliam: you can... hmm... I was gonna say you don't need to pay attention to time like that in IRC. Some people can take a long time (like an hour) to respond
300[01:58:37] <trysten> liamliamliam: copy something in firefox then probe with xclip to see if it's in there
301[01:58:55] <trysten> right click-> copy, then xclip -o; xclip -o -selection clipboard
328[02:09:27] <trysten> Your primary is being synced to clipboard and your accidentally selecting stuff when you go back to terminal. After copying something in firefox switch back to the terminal without using the mouse and try again.
329[02:09:52] <liamliamliam> ok!
330[02:10:38] <liamliamliam> nothing, and it's not copying and pasting from libreoffice or anything
331[02:10:55] <trysten> But that wouldn't explain not being able to paste in firefox.. Hm.
332[02:11:11] <trysten> I assume you're not even seeing a paste option in the context menu in firefox
333[02:12:08] <liamliamliam> i have the paste option from right click
388[02:36:27] <agio> trysten: thanks, I think I fixed it
389[02:37:28] <agio> but I have a problem with my X server, its currently consuming 80% of a CPU core and my entire desktop has slowed down to the point of being unusable
390[02:38:13] <agio> I looked into ~/.xsession-errors - and it seems there are alot - but the logs don't have readable timestamps
391[02:38:37] <agio> any ideas how to investigate/debug?
407[02:50:39] <borp> every time I masturbate I get angry and throw my turtle against the wall. is this normal??
408[02:50:58] <Krematorium> Bjornn, i hate when plan goes too well, because it means eventually something big is failing underneath and you are just sit over a TNT barrel
409[02:51:16] *** Quits: pomkat (~pomkat@replaced-ip) (Remote host closed the connection)
410[02:51:22] <trysten> liamliamliam: did you get it working?
411[02:51:27] <Krematorium> (either that, or just wasting a lot of time in something you will have to do again in the future)\
412[02:51:36] <Bjornn> haha. ye. something could explode any minute...
463[03:27:15] <trysten> liamliamliam: that was my bad for not telling you to kill the process. oopth.
464[03:27:30] <trysten> agris: just ask your question
465[03:27:35] <agris> How do i get mariadb-client to use TLSv1.2 instead of TLSv1.1?
466[03:28:03] <liamliamliam> no worries, i figured it out, we did it together and now i know!
467[03:28:13] <liamliamliam> which is way better!
468[03:28:31] <agris> I am trying to connect to a database server that enforces IP security no lower than TLS.v1.2 and for some reason Debian's mysql command keeps failing to connect with an undefined SSL error
487[03:36:12] <trysten> ok it looks like it should be autonegotiating, agris. Try --tls-version on the client or try 'openssl s_client -connect 192.168.1.100:3306 -tls1_2'
488[03:36:28] <agris> however this does not occur on other distrobutions, for example I have another Gentoo workstation with MariaDB-client and it connects fine
489[03:37:40] *** Quits: alexandros_C_ (~quassel@replaced-ip) (Remote host closed the connection)
490[03:37:40] *** Quits: alexandros_c (~quassel@replaced-ip) (Remote host closed the connection)
522[03:50:36] <rwp> agio, Do you have the ability to use a wired connection for the install? That avoids the need to install the wifi driver until later.
534[03:57:28] <rwp> agris, I only partially skimmed the scrollback but I have seen newer mariadb clients require options that are not understood by mysql server. Due to newer development.
535[03:58:21] <rwp> If you are trying to do the same then that is likely the problem. There is probably a way to configure mariadb-client for the downgrade protocol but here I switched to using mysql client and everything worked okay.
536[03:58:29] <agris> rwp, my server is not mysql, it is Server version: 10.1.34-MariaDB Gentoo Linux mariadb-10.1.34
540[03:58:55] <agris> the clients are Debian Stable
541[03:58:59] <rwp> Good to hear it is Mariadb on both ends. Is there a large (or even small) version difference between the client version and server version?
546[04:00:59] <rwp> Seems like Debian Stable is newer than your server version, not much difference in point release numbers, so seems like it should work.
547[04:01:08] <agris> well on my x86_64 Debian stable laptop produces mariadb Ver 15.1 Distrib 10.1.37-MariaDB, for Debian-linux-gnu (x86_64_ using readline 5.2
560[04:06:00] <agris> yes, I could try upgrading the server, but I don't think that would change a whole lot, as they are minor change, and I don't think wireshark is lying
563[04:07:47] <rwp> If it were me, I have victim machines available for testing, I would try downgrading mariadb-client to the exact same 10.1.34 version and seeing if that worked. If so then it is a package difference. Look at the changelogs.
565[04:08:20] <rwp> I wouldn't try the downgrade test on a production machine but a victim system or VM is useful. Can get an older version from replaced-url
577[04:11:10] <agris> if that is the case, 10.1.37 clients can't connect to 10.1.34 servers that is a really odd and unexpected bug indeed
578[04:11:18] <agris> and probably should be reported somewhere
579[04:12:14] <rwp> I wouldn't say unexpected as I am sure in the upstream test matrix they always test the same newest daily build version clients against the same newest daily build version server.
586[04:16:19] <agris> despite the server running minor version 37
587[04:16:36] <agris> also, I see in wireshark it still tries to use TLSv1.1
588[04:17:30] <agris> Gentoo workstations can connect fine using both client minor versions 34 and 37, TLSv1.2 verified by wireshark
589[04:18:12] <yukip> i tried installing a distro to a usb but it won't boot without grub on the primary hdd, persistent storage on a live usb didn't save; ideas?
590[04:18:15] <agris> This is certainly looking like a Debian specific bug
604[04:28:52] <nuxil> i need some advice. let me try explain. im running Kde with multiple monotors "replaced-url
605[04:29:13] <nuxil> i would like to avoid my mouse to move onto the disabled screens. there seems to be no settings for this. so i found out i can use:
606[04:29:24] <nuxil> dotool getmouselocation --shell .to get the mouse position.
610[04:30:17] <nuxil> to set the mouse position i can use: xdotool mousemove X Y
611[04:30:39] <nuxil> but how can i make a loop that checks of the displays are disabled| off ? so i can enable a script that sets restrictions on my mouse?
612[04:30:50] <nuxil> is there some kernel-event thingy i can listen to ?
642[04:45:10] <nuxil> yukip, i dont know how to look for the "monitor" file. i know of /dev/fb0 and that you can have fun with it. echo "\xff\xff\x23\x00" > /dev fb0 at a tty. but other than that. im rather clueless.
796[05:44:02] <danielboston26> I’ve tried those they wrent working
797[05:44:13] <danielboston26> There was another one that was suggested to me
798[05:44:23] <danielboston26> !rufus
799[05:44:24] <dpkg> rufus is a tool that can be used to make bootable USB devices under Windows. It is not recommended for use with Debian CD/DVD images, as it mangles the installer in cruel and unusual ways, resulting in hard to debug problems. Ask me about <hybrid images>, <usb install>, <win32diskimager>.
800[05:44:27] *** Krematorium is now known as Kremator
803[05:45:46] <dpkg> [non-free] a component which contains software that does not comply with the <DFSG>. To add non-free packages to your packages index, ask me about <non-free sources>. To see which non-free packages are installed ask me about <non-free list>.
814[05:56:25] <dpkg> win32diskimager is much more reliable than <unetbootin> for copying ISO images to USB sticks and you can download it from replaced-url
815[05:57:13] <danielboston26> !usb install
816[05:57:14] <dpkg> You can install Debian from a USB stick/thumbdrive/pen drive/key on x86 systems, as long as your system's BIOS can boot from USB. Details are in the Installation Guide, see replaced-url
1328[12:19:42] <SpaceDump> Hello! Anybody familiar with mini-buildd? I've got an issue where my build node timed out while trying to ftp the build result and now it's stuck in that UPLOADING phase..
1407[13:11:46] <n4dir> i see in #linux that you use qemu? I would assume you just use gparted, then mount the new partition via /etc/fstab, like usual.
1408[13:11:53] <n4dir> but am not that sure, to be honest.
1427[13:20:22] <lightblue> hi, I need to run a python script with as a cron task at 7am everyday. In my "crontab -e" I inserted a new line like "0 7 * * * python3 scriptName.py", but it doesn't run.
1428[13:20:23] <martin-_-_> It doesn't show me any bytes only blocks
1464[13:29:01] <abrotman> lightblue: have you checked your system logs to see if it's attempting to run it, or your mailbox to see if it's emailing you an error?
1465[13:29:19] *** Quits: conta (~Thunderbi@replaced-ip) (Remote host closed the connection)
1466[13:29:24] <jelly> lightblue, does it run? Do you have a local delivery agent installed to receive results from cron jobs in mail?
1486[13:33:51] <jelly> abrotman, crontab(5) says: SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner. PATH is set to "/usr/bin:/bin".
1561[13:57:21] *** Quits: neuraload (~marius@replaced-ip) (Quit: This computer has gone to sleep)
1562[13:57:26] <lightblue> I don't know if it has something to do with me using a virtual python environment, I actually activated a virtual environment in the script
1563[13:58:16] <lightblue> but that only happens after the script runs
1564[13:58:24] <blackflow> activated how?
1565[13:58:25] <jelly> it shouldn't matter if it's done inside the script. only if it has to be done in the shell
1566[13:59:08] <lightblue> blackflow, exec() the activate_this.py file in the virtualenv folder
1567[14:00:06] <blackflow> lightblue: I'm not familiar with the method. but if you want a python script be run in a virtualenv, all you need is to use the python bin from that virtualenv directly. /path/to/virtualenv/bin/python /path/to/the/script.py and that's it
1568[14:00:20] <jelly> lightblue, does the shell you're running things successfully from say anything about echo "$VIRTUAL_ENV" ?
1569[14:00:42] *** Quits: kill0 (~kill0@replaced-ip) (Remote host closed the connection)
1570[14:00:47] <jelly> that is, is a virtualenv already active in that shell
1571[14:01:56] <lightblue> blackflow, yes you can do that but not when you need to run it as a cron job, the same goes for a cgi or wsgi script called by a webserver
1572[14:02:19] <blackflow> lightblue: that's not true, you can do it from the cron script too
1573[14:02:29] <blackflow> "activating" virtualenv essentially only adds the virtualenv to the beginning of the PATH (and alters the prompt), so using the python bin from it directly, has the same effect.
1576[14:05:05] <lightblue> blackflow, do you mean I should change the crontab line from python3 xxx to virtualenv/python3 xxx?
1577[14:05:15] <blackflow> cgi/wsgi works essentially the same, but it only depends on how you define which python bin to use. eg. UWSGI has "virtualenv" directive that one has to use, because there's no directive to specify the python binary, it's embedded
1578[14:05:23] <blackflow> lightblue: yes, but use absolute paths of course.
1581[14:06:12] <lightblue> ok, I'll try it now and see if it works
1582[14:06:20] <blackflow> btw, regarding mailing of that output, you need a mailserver running of course, even just to deliver to user's local mailbox. alternatively specify MAILTO env var in the crontab.
1583[14:06:37] <jelly> you could do changes around blindly like that, but perhaps it makes more sense to actually enable logging and verify where mails from cron go.
1584[14:06:38] <blackflow> lightblue: pretty sure it works because I've been doing that for years :)
1585[14:07:06] <blackflow> (alternatively to sending mail to local user mbox, you still need an MTA)
1586[14:07:15] <jelly> right.
1587[14:08:09] <jelly> if you don't have any /usr/sbin/sendmail, dma might be an option
1588[14:08:12] *** Quits: b (coffee@replaced-ip) (Ping timeout: 250 seconds)
1589[14:08:13] <jelly> ,i dma
1590[14:08:14] <judd> Package dma (mail, optional) in stretch/amd64: lightweight mail transport agent. Version: 0.11-1+b1; Size: 49.8k; Installed: 148k; Homepage: replaced-url
1607[14:17:31] <blackflow> lightblue: wait, though, if you're using python from the virtualenv/bin you don't need (and shound't do) the exec() virtualenv thing
1608[14:17:49] <blackflow> *anything in journal....
1609[14:17:54] <lightblue> blackflow, yes that's what I thought...
1614[14:19:48] <lightblue> blackflow, I'm wondering even if I used the global /usr/bin/python3 on a script inside which I used exec() to activate the virtual environment, it should have worked
1615[14:20:50] <lightblue> blackflow, by the way, does cron write log to /var/log/syslog ? I checked there before, didn't see any line, and there's no cron.log in /var/log
1616[14:21:07] <blackflow> lightblue: perhaps you should debug this step by step. run the script from cli using virtualenv's python directly, verify it works. then try it from the crontab. also try something else from teh crontab, like, I don't know, touch /some/file/path to verify it's called and exec'd
1617[14:21:37] <blackflow> lightblue: not by default, like jelly noted, you need to uncomment the cron.* facility in /etc/rsyslog.conf
1619[14:21:57] <blackflow> but eh... the journal should have it all, regardless of rsyslog (I'm assuming you have systemd/journald there?)
1620[14:22:33] <blackflow> journalctl -u cron.service -n 20 should give you last 20 lines of log for the service
1621[14:22:35] <lightblue> blackflow, about the touch /some/file part, I actually did insert a new crontab entry that does that, that entry works and there's /some/file
1624[14:24:56] <blackflow> lightblue: right, so running python must work as well. there's one more thing you can do. redirect all output, inc.. stderr, from that script to a file. * * * * * /path/to/virtualenv/bin/python3 /path/to/script.py > /somefile.log 2>&1
1625[14:25:42] *** Quits: tryte (~tryte@replaced-ip) (Remote host closed the connection)
1626[14:25:59] <blackflow> lightblue: one VERY important thing here. I'm assuming this is a user crontab? you said you ran crontab -e initially. if this is a global crontab, under /etc/cron.d/ then you _need_ to specify the user it runs as, first thing before /path/to/python
1627[14:26:37] <blackflow> (even if the user is root, it has to be there)
1634[14:29:01] <lightblue> in /var/log/syslog I saw one line regarding my script, it says "(username) CMD (full_path_to_venv_python3 full_path_to_script)"
1635[14:29:15] *** Quits: pvdp (~pvdp@replaced-ip) (Remote host closed the connection)
1636[14:29:55] *** Quits: graphene (~graphene@replaced-ip) (Remote host closed the connection)
1637[14:29:57] <lightblue> but the script still doesn't work
1668[14:43:12] <VinAlencc> Hello, guys! How are you? I'd like to ask you something. I'm setting 2 servers as Master/Slave servers and I'm facing one problem. Both are running DNS, DHCP and IPTables rules. Once IPTables rules are allowing my network to access the Internet, it's OK... It's OK up to the moment I remove/delete the rules from Master or if I reboot/poweroff the Master. In theory, Slave's firewall should keep the Internet
1671[14:43:14] <VinAlencc> access to the network, right? But it isn't. What should I do? Btw, DNS and DHCP from Slave are OK. I can DIG my Slave server and get all DNS records.
1672[14:44:08] *** Quits: endstille (~endstille@replaced-ip) (Quit: I'll be back.)
1676[14:46:04] <jelly> VinAlencc, I'm assuming you have some sort of floating ip configuration for the default gateway IP address for the clients. Does it fail over to "slave" system when "master" is down correctly?
1713[14:53:07] <jelly> VinAlencc, so at that point you want a setup that moves the IP address of your router to move from one machine to another when one fails; this is often called a "floating ip"
1714[14:53:09] <blackflow> rocketmagnet: what's at PID 450? are you perchance inside a path that was mounted?
1720[14:53:56] <blackflow> rocketmagnet: what is "it"?
1721[14:53:59] <VinAlencc> jelly: But... in the case of a HA setup, how could I set a gateway to work on both? Something like: master is running, when it fails, slave assumes and run the IPTables rules?
1722[14:54:49] <rocketmagnet> the process
1723[14:54:57] <blackflow> rocketmagnet: oh you asked _how_ to find that out..... well, ps axu | grep 450 for example (or whatever the new PID is instead of 450)
1724[14:55:09] <jelly> VinAlencc, either you make a somewhat complex network config on all the clients, or use a floating ip and make only ONE gw active at a time
1725[14:55:28] <VinAlencc> jelly: Floating IP = IP Alias?
1729[14:56:22] <blackflow> HA gateways are often done with bonded NICs, if one goes down, the kernel starts using the other physical link to send out packets.
1730[14:56:25] <rocketmagnet> blackflow: i don't know what that means
1731[14:56:48] <VinAlencc> blackflow: I will check this one, as well.
1732[14:56:51] <jelly> VinAlencc, might use something like keepalived to manage where the IP address is active
1733[14:57:16] <blackflow> rocketmagnet: ah it's a kernel's journaling thread. it's still writing to sda7
1734[14:57:28] <VinAlencc> jelly: I'll check this one too. Thanks
1736[14:58:02] <rocketmagnet> what a kernel journaling thread ?
1737[14:58:06] <rocketmagnet> and how to stop it
1738[14:58:12] <jelly> blackflow, that does not seem to cover their case of whole machine dying
1739[14:58:25] <blackflow> btw floating IP is not specifically done wiht aliases. a floating IP is alyways one and the same IP that the upstream router starts routing through a different port, on "failover", to, thus, different physical link
1740[14:58:32] <rocketmagnet> i tried to empty my trash and it stuck, can this be the problem ?
1744[14:59:22] <blackflow> rocketmagnet: possibly if there was a megaton of files. you can umount with -l flag, that will umount it immediately but the kernel will _Actually_ release the resource once it becomes ready to do so
1745[14:59:36] *** Quits: MenschZwoNull (~MenschZwo@replaced-ip) (Remote host closed the connection)
1746[14:59:45] <jelly> VinAlencc, there's more than one model to achieve this, and then for each model there might be multiple tools to setup and manage a cluster.
1747[14:59:55] <blackflow> I've noticed that linux kernel often lies about disk activity. a command will return but the kernel will still churn out stuff in the background. this often happens with slower, eg. USB media
1748[14:59:57] <jelly> keepalived is okay for very simple setups
1782[15:05:18] <blackflow> no that will only add up activity and make everything longer, esp. if there was a large amount of files that du has to sum up. df is better, as that was a mounted filesystem
1787[15:08:13] <jelly> rocketmagnet, oh, and if the filesystem is _mounted_ with discard option, the kernel might be issuing lots of TRIM commands on the fly to the ssd, and that might actually make things slower than they would have been without discard
1788[15:08:59] <jelly> some people avoid using that as mount options, and only run fstrim command manually or via timer/cron jobs every week or every month
1798[15:14:54] <rocketmagnet> where is the trash folder? when using df i only see the process of / and i've everything on / so i don't realy know when it's going to be finshed
1799[15:16:39] *** Quits: lovezrs_ (~Mutter@replaced-ip) (Remote host closed the connection)
1809[15:20:19] <rocketmagnet> that will take days ..
1810[15:20:38] <rocketmagnet> it's a brand new sdd hd... why is this stuff so slow - it's a delete operation ...
1811[15:21:39] <blackflow> rocketmagnet: 1) which ssd model? 2) are you using trim/discard in mount options (fstab)? 3) how much are you deleting (in GB and # of files)?
1817[15:23:20] <blackflow> rocketmagnet: install "iotop" package, then run "iotop" and hit "a" for cumulative mode, the thread should be listed there and you can see the speed at which it runs
1819[15:23:34] <rocketmagnet> i buyed a new ssd (kingston) only for my projects and copied all the data (ALOT) from one ssd to the new one and then deleted the old content
1820[15:23:40] <blackflow> wasn't sure before if iotop did kernel threads too so I had to check
1825[15:25:21] <blackflow> btw if you delete from "Trash", which is purely a construct of your desktop environment, eg gnome, it's quite possible the thing is doing who know what else for each file deleted. that's quite likely with hogs like gnome and its dbus powered gvfs nonsense....
1826[15:25:55] <jelly> if there's cpu usaing it might show in normal "top"
1844[15:31:05] <blackflow> methinks we have a bit of a XY situation here and a red herring wrt that initial question about blocked umount. it seems to me there's nothing going on there at all.
1850[15:31:57] <blackflow> rocketmagnet: umoount _what_ exactly? what command?
1851[15:32:05] <jelly> rocketmagnet, which mountpoint is the affected filesystem using?
1852[15:32:11] *** Quits: lovezrs (~Mutter@replaced-ip) (Remote host closed the connection)
1853[15:32:16] <rocketmagnet> umount /dev/dfa7
1854[15:32:19] <rocketmagnet> sda7
1855[15:32:29] <jelly> and where is /dev/sda7 mounted at?
1856[15:32:36] <rocketmagnet> now it worked
1857[15:32:46] <rocketmagnet> strange
1858[15:33:43] <blackflow> rocketmagnet: where was that mounted? it's not strange that umounts block initially as the kernel as to finish with that device first, but usually that's cleared up quite fast (in seconds)
1859[15:33:48] <blackflow> *has to
1860[15:34:03] <rocketmagnet> it was mounter to /media/user/data
1884[15:47:40] <lightblue> My problem has been solved. I debugged my code and found a silenced exception which caused the script not run. It's not cron's problem. Thank you for you help, especially to blackflow and jelly, thanks.
1923[16:13:36] <dpkg> [popcon] the Debian Popularity contest, the basis for what packages appear on the first few CDs/DVDs etc (by rank). Install the popularity-contest package to participate. See the results at replaced-url
1959[16:29:47] <simpledat> I have the latest bios version. But why did it not install intel-microcode by default? I have non-free in sources.list and I use debian stretch.
1961[16:30:38] <dvs> because non-free packages are not installed by default?
1962[16:31:13] <simpledat> dvs: For Ubuntu it does?
1963[16:31:25] <joepublic> !ubuntu
1964[16:31:25] <dpkg> Ubuntu is based on Debian, but it is not Debian. Only Debian is supported on #debian. Use #ubuntu on chat.freenode.net instead. Even if the channel happens to be less helpful, support for distributions other than Debian is offtopic on #debian. See also <based on debian> and <ubuntuirc>.
1965[16:31:55] <joepublic> takeaway: Ubuntu is not Debian
1966[16:32:22] <simpledat> You mean that debian doesnt bother about peoples security in the same way as Ubuntu does?
1967[16:32:52] <joepublic> I mean that Ubuntu does not bother about software freedom as Debian does.
1968[16:33:20] <petn-randall> simpledat: If you have the latest BIOS by a manufacturer that cares, you'll have the latest microcode.
1969[16:33:27] <Urchin> Ubuntu can be pretty sucky at fixing bugs
1971[16:33:42] <simpledat> joepublic: But intel-microcode is important for security?
1972[16:33:55] <petn-randall> simpledat: That's a wild claim for now.
1973[16:34:01] *** debhelper sets mode: +l 1457
1974[16:34:19] <simpledat> petn-randall: Please check this replaced-url
1975[16:34:20] <joepublic> simpledat, that doesn't make the intel microcode packages non-free, you see.
1976[16:34:58] <simpledat> Yes I have the latest BIOS version
1977[16:34:59] <joepublic> if they are so important for security, then lobby intel to release them under a free license. Griping to me sure won't help.
1978[16:35:34] <simpledat> petn-randall: How is that then I get this line? /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
1989[16:36:59] <dpkg> Edit /etc/apt/sources.list, ensure that the two main Debian mirror lines end with "main contrib non-free" rather than just "main", then «apt-get update». But bear in mind that you'll be installing <non-free> software. These may have onerous terms; check the licenses. See also <sources.list>.
1990[16:37:23] <simpledat> petn-randall: I have been told by people they already have microcode installed by default with non-free sources and they are running Ubuntu.
1991[16:37:38] <joepublic> Reminder: Ubuntu does not bother about software freedom as Debian does.
1992[16:37:43] <petn-randall> this ^
1993[16:37:48] <jelly> simpledat: yes, ubuntu has different priorities from debian
1994[16:37:59] <simpledat> joepublic: Freedom is also to be secure.
1995[16:38:07] <simpledat> ^
1996[16:38:11] <joepublic> simpledat, take it up with the fsf.
1997[16:38:12] <petn-randall> Ubuntu only offers security support for 10% of their packages, so there's always a trade-off.
1998[16:38:50] <simpledat> So how do I fix my issue here?
2011[16:42:05] <petn-randall> Note that several of those CPU bugs have different ways to circumvent them. The most secure setting usually comes with a heft performance penalty, and is also not the default one.
2012[16:42:10] <jelly> so you need firmware, and then other software on top (both kernel and userspace, I think) can use the new instructions to help with mitigation
2013[16:43:21] <petn-randall> *hefty
2014[16:43:48] <jelly> simpledat: fixing some of those issues in requires support in userspace as well. /sys/devices/system/cpu/vulnerabilities/ only shows whether the kernel has any mitigation in place. Userspace might still be affected.
2016[16:44:54] <jelly> and even then, all the fixes might not actually be there in Debian's kernel, but only in 4.14 and above from upstream.
2017[16:45:03] <simpledat> Im confused. So if intel-microcode would fix the issue with spec_store_bypass, why are then petn-randall telling me that "my mobo manufacturer doesn't care then."
2022[16:45:46] <joepublic> simpledat, because the motherboard bios has the job of loading the firmware onto the processor. You only need to do it at the OS level if the bios loads an old version.
2023[16:46:42] <simpledat> joepublic: as I told, I use the latest bios version. So you dont understand how my bios would load an old version anyway?
2024[16:46:59] <simpledat> So I dont understand*
2025[16:47:07] <jelly> simpledat: your latest bios apparently does not have the fixes from latest intel microcode.
2031[16:49:45] <simpledat> jelly: How do you update your bios anyway? Do you download the .CAP file and then upload it to a USB. Then reboot and install it in bios?
2033[16:49:59] <joepublic> The motherboard manufacturer sharing your belief that microcode is the holy grail of features--"it should do"--is not a safe nor sane assumption.
2034[16:50:30] <jelly> simpledat: that's really vendor and model dependent.
2041[16:52:33] <joepublic> I have a "Made In China" brand motherboard in this workstation that doesn't even have an identifiable manufacturer, much less a known/supported way to obtain updated bios.
2067[17:00:02] <jelly> simpledat: you can't; most of these issues involve one piece of software gaining information from another piece of software running on the same CPU. You can't know whether something is truly fixed, you can find one exploit, test that is works before, and test that it does not work after a patch.
2074[17:03:09] <jelly> simpledat: you have to give the answer to that one. It doesn't matter _to me_. If you're a strong proponent of FSF Way of Life it might matter to you.
2075[17:03:47] <simpledat> jelly: Can you explain? I dont understand, what do you mean by FSF for example?
2076[17:03:58] <joepublic> I don't know of any fsf-friendly way to update microcode. Every bios update I have ever seen comes with a non-free license.
2077[17:04:09] <joepublic> As does the microcode itself.
2078[17:04:23] *** Quits: P1ersson (~P1ersson@replaced-ip) (Quit: Älska inte din nästa, älska den du har)
2079[17:04:26] <jelly> simpledat: I mean, what's stopping you from installing the damn package and rebooting, and looking if it fixed things?
2080[17:04:33] <LtL> why would /etc/modprobe.d/intel-microcode-blacklist.conf blacklist microcode?
2089[17:05:55] <simpledat> jelly: I was just suprised that it was not already fixed. What about users that dont know that they should install intel-microcode for example? I just want to feel secure by using Debian.
2100[17:08:08] <dpkg> DFSG is the Debian Free Software Guidelines, which are explained at replaced-url
2101[17:08:30] <joepublic> just chiming in, if automatic installation of non-free microcode is what you are looking for, you might try intel clear linux. clearlinux.org
2103[17:09:06] <jelly> simpledat: it's a set of core values, that explains in part why debian will not ship non-free bits by default, ever, no matter how useful they may be
2104[17:09:07] <Dagger2> GNU\colossus: your gateway is not even in your /64. how do you expect that to work?
2105[17:09:14] <simpledat> petn-randall: I want something that keep me secure. I always do apt-get update && apt-get upgrade on every boot up. But I cant keep tracking exactly what packges to install manually to keep me secure. Do you understand?
2106[17:09:15] <petn-randall> ... or simply add non-free and install the package.
2107[17:09:33] <petn-randall> simpledat: non-free microcode is an exception.
2108[17:09:47] <jelly> simpledat: Debian will not keep you secure if that means installing non-free software
2109[17:09:57] <jelly> some other distros will.
2110[17:10:03] <petn-randall> simpledat: If your BIOS manufacturer does their job, you don't need to install non-free microcode.
2111[17:10:10] <simpledat> petn-randall: Well even if I add non-free. I still gonna have to track all risks that I take. And I have to know what packages to install to prevent it.
2112[17:10:16] <GNU\colossus> Dagger2, hrm. darned compressed notation, I see what you mean :>
2113[17:10:53] <jelly> simpledat: but you can make those decisions yourself, and on some other distros they are made for you from the start.
2114[17:11:03] <petn-randall> simpledat: It's *one* package. And you'll "have to track all risks that I take" no matter if it's installed by default or not.
2115[17:11:34] <joepublic> simpledat, instead of keeping up with the universe yourself, you might check /sys/devices/system/cpu/vulnerabilities
2116[17:11:44] <jelly> simpledat: if you pick a distro that installs intel-microcode by default, it will still be the very same microcode
2117[17:11:45] <GNU\colossus> Dagger2, I can use `ip -6 r add ...` to set up a route to my gw over that interface, and after that route's been configured, also set it as my default gw. is that _supposed_ to work? (because it does in practice.)
2118[17:11:45] <simpledat> jelly: Well it seems that Ubuntu for example is more user friendly for normal users.
2119[17:11:53] <petn-randall> simpledat: You seem to obsess over CPU bugs. They're a local, very theoretical problem. There are much worse bugs out there that have much more practical application.
2120[17:11:55] <jelly> simpledat: oh for sure
2121[17:12:26] <joepublic> I would agree that Ubuntu seems more user friendly for average uses.
2122[17:12:28] <GNU\colossus> (my /64 subnet and gw were provided that way by the ISP)
2124[17:12:49] <simpledat> petn-randall: Im not CPU bugs expert, But when I saw spec_store_bypass:Vulnerable, then I feelt something is not right here.
2125[17:12:50] <joepublic> Mint--another free/non-free mix--seems even friendlier
2126[17:13:14] <jelly> simpledat: ubuntu prioritizes user friendliness and hardware compatibility above software freedom.
2128[17:13:27] <petn-randall> simpledat: Feelings won't get you far in the security world. If you want to *know*, read up on how this CPU bug affects you, if at all.
2130[17:13:56] <Dagger2> GNU\colossus: it looks like your on-link prefix is actually 2001:4ba0:ffff::/48, which would be very screwed up but this particular screwup is for some reason very common
2131[17:14:10] <simpledat> My issue is, I really like Debian most of them all. And I dont want to go back to Windows
2132[17:14:11] <Dagger2> server hosts seem to love configuring the wrong size prefix and then lying to you about it
2134[17:14:46] <simpledat> petn-randall: I mean, why have this CPU bugs at all? Right? Who wants them even?
2135[17:14:52] <joepublic> simpledat, cpu bugs will be solved two places; the kernel, and the microcode. if you have both installed, then you have cpu bugs covered, be they present or future.
2136[17:14:53] <jelly> simpledat: then you need to accept debian won't ever install intel-microcode by default, so you have to do it yourself
2138[17:15:17] <GNU\colossus> Dagger2, can you explain to me how you know (or arrive at that conclusion from) that, from the data I provided?
2139[17:15:39] <jelly> joepublic: except for those that happen between any two pieces of code running at the same time and affect userspace to userspace
2140[17:15:49] <GNU\colossus> (it's the first time I'm configuring ipv6 for myself, as you can probably already tell ;))
2141[17:16:05] <jelly> which is most the spectre-like and some of the meltdown-like ones
2142[17:16:19] <jelly> IIRC
2143[17:16:43] <joepublic> and iirc, spectre1 and 2 and meltdown are mitigated in the kernel, not in each individual user application... right?
2144[17:16:57] <jelly> joepublic: and there, fixes in kernel merely mean userspace won't get to peek at the kernel
2145[17:17:26] <Dagger2> GNU\colossus: well, it's a guess, but both your IP and your gateway are in the same /48. they're in different /56s, and thus of course different /64s
2146[17:17:27] <joepublic> well, that's what mitigation means. otherwise you are just "deciding to use a different program" which is hardly a fix or mitigation
2147[17:17:40] <GNU\colossus> Dagger2, understood
2148[17:17:45] *** Quits: blueingress (~pp_of_mm@replaced-ip) (Remote host closed the connection)
2149[17:17:52] <jelly> joepublic: some of those they do little to nothing about userspace still being able to peek at other userspace
2150[17:18:11] <joepublic> meaning that there are vulnerabilities not mitigated.
2151[17:18:21] <jelly> they're the SAME vulnerabilities
2154[17:18:47] *** Joins: conta (~Thunderbi@replaced-ip)
2155[17:19:01] <simpledat> So the only reason why I see this line is because my motherboard manufactor didnt solve it? That has actually nothing to do with intel-microcode on Debian? or am I wrong? /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
2156[17:19:29] <jelly> simpledat: you're possibly wrong, we don't know until you install and test it
2158[17:19:42] <joepublic> simpledat, cpu bugs will be solved two--no THREE--places; the kernel, and the microcode. AND software updates... if you have both NO all THREE installed, then you have cpu bugs covered, be they present or future.
2162[17:20:48] <joepublic> so that would amount to using linux, installing the microcode if you want those fixes also, and keeping apt current and upgraded.
2163[17:20:51] <simpledat> jelly: Well what petn-randall told me, is that my motherboard manufactor doesnt care?
2164[17:20:55] <jelly> for example: google internally recompiled and rebuilt _all_ of their possibly affected userspace for one or both first spectre variants
2179[17:24:42] <joepublic> qemu yells at me to turn off hyperthreading despite other l1tf mitigations on my kvm server
2180[17:24:53] <simpledat> My question is, could spec_store_bypass be fixed by bios or only by installing intel-microcode? Because if it could be fixed by BIOS then I believe it should be fixed.
2184[17:25:14] <petn-randall> simpledat: 1) How would going back to Windows help? MS doesn't patch the CPU bugs, either. 2) Again, *READ*. One CPU bug only affects hyperthreading CPUs running VMs. If you don't have a i7 and run VMs, the bug is irrelevant to you.
2186[17:25:57] <joepublic> simpledat, bios installs microcode. updated bios might/should include updated microcode. for cases where bios does not fix it, debian provides a way to install the microcode at the os level. it's the same microcode no matter how it gets on the cpu
2187[17:25:58] <petn-randall> simpledat: BIOS ships microcode, so everything that can be fixed by installing the intel-microcode package can also be fixed by the BIOS manufacturer.
2188[17:26:00] <jelly> simpledat: both bios and intel-microcode bring you the same thing -- updates to microcode. Which one is newer, and which one helps mitigation, depends on intel and your mobo vendor
2189[17:26:16] <joepublic> it seems great minds think alike and so do we
2192[17:26:51] <jelly> afterwards, even when you read: /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
2193[17:26:58] <jelly> that doesn't mean you're safe.
2200[17:27:55] <jelly> simpledat: because OS vendors are pragmatic and will not enable a "fix" that slows down your machine by 20 or 50% by default
2201[17:28:46] <simpledat> joepublic: So how do you make sure that you are safe then? Latest BIOS, intel-microcode installed. What else do you have to dO?
2202[17:28:49] <petn-randall> (I mentioned that 45 minutes ago)
2203[17:29:00] <jelly> instead, they may tell you to use "prctl" and "seccomp" on a process-by-process basis based on which process and service deal with more sensitive data
2205[17:30:13] <petn-randall> simpledat: You'll never be "safe". There's a constant race between software/hardware bugs, and mitigations/fixes, and how much performance or comfort you willing to sacrifice for the sake of security.
2208[17:30:31] <simpledat> jelly: If you are talking about intel-microcode that slows down your machine? Ubuntu does it. And I think most people prefer secure system then 20-50% higher performance.
2209[17:30:33] <jelly> simpledat: basically, either hire an admin, or waste 1-2 years learning it security, and read 1-5 hours of new info each week and try to deal with it the best you can
2210[17:30:50] *** Quits: MenschZwoNull__ (~MenschZwo@replaced-ip) (Remote host closed the connection)
2212[17:31:19] <petn-randall> simpledat: Still a wild claim
2213[17:31:47] <jelly> simpledat: no. New intel-microcode helps the CPU stop and think about security, but only when asked for it. Each OS and each user app have to specifically use that, and not all do.
2222[17:33:27] <simpledat> jelly: I respect people that are learning about security and have time to do it. Thats why I ask you here how to fix this and feel less worried about it. :)
2224[17:33:42] <jelly> PaddyF: disabling hyperthreading, which is one viable mitigation against L1TF, loses 0-50% performance. For my make -j4 kernel build on an i5-660, that means 33% loss.
2226[17:34:23] <jelly> PaddyF: or one can buy code from smarter people who do better mitigations
2227[17:34:36] *** Quits: Labu (~Labu@replaced-ip) (Ping timeout: 246 seconds)
2228[17:34:45] *** Quits: MenschZwoNull (~MenschZwo@replaced-ip) (Remote host closed the connection)
2229[17:34:51] <simpledat> jelly: as I told, Im not that much into CPU bugs. As I thought it should be a easy fix for manufactor and debian devs.
2230[17:34:53] <jelly> or sell your hardware and buy amd which is _slightly_ more safe
2231[17:35:20] <GNU\colossus> Dagger2, turns out my ISP's documentation suggests manually setting up the gw address by using two "up" stanzas that call /sbin/ip
2232[17:35:25] <petn-randall> simpledat: For all CPU bugs to work, you need a malicious process running *on* *your* machine. If you think about it, you've already got a problem then, CPU bugs or not.
2233[17:35:47] <jelly> simpledat: issues like these will appear for years.
2238[17:37:32] <jelly> I'd say if you're paranoid enough to care about this kind of bugs, run web browsers on separate machine on separate network.
2239[17:37:47] <petn-randall> jelly: They turned down the timer resolution in browsers to make those attacks impractical.
2240[17:37:50] <simpledat> petn-randall: I believe if you have less CPU bugs or whatever. You are safer to go, less problems.
2241[17:38:16] <petn-randall> simpledat: Sure, but with limited ressources, your time/money is better spent elsewhere.
2242[17:38:19] <jelly> simpledat: there are worse security issues that are less talked about.
2243[17:38:51] <simpledat> jelly: What security issues for example? Curious..
2244[17:39:00] <jelly> teaching your friends and family not to leave personally identifiable info about you and them on Facebook.
2245[17:39:08] <petn-randall> simpledat: Any remote code execution bug in the software you run.
2246[17:40:02] <petn-randall> simpledat: *all* CPU bugs only allow to locally read information they're not allowed to. Period. That doesn't rate them high on the severity scale.
2354[18:16:08] *** Quits: dvs (~Herbert@replaced-ip) (Remote host closed the connection)
2355[18:16:19] <nkuttler> !debian-next
2356[18:16:19] <dpkg> #debian-next is the channel for testing/unstable support on the OFTC network (irc.oftc.net), *not* on freenode. If you get "Cannot join #debian-next (Channel is invite only)." it means you did not read it's on irc.oftc.net.
2357[18:16:26] <nkuttler> !oftc
2358[18:16:26] <dpkg> OFTC is the Open and Free Technology Community, a support/collaboration service. They have an IRC network: irc.oftc.net. You may be connected to OFTC's network. replaced-url
2359[18:16:30] <joepublic> yeah without reading comprehension debian-next is pretty much useless
2395[18:22:14] <ekleog> basically, backporting to stable is done by 1. reading the changelog scanning for critical bugfixes, and 2. monitoring CVE listings, if I understood the answers correctly
2402[18:23:27] <blackflow> ekleog: I wouldn't give too much attention to such updates. of course the more (of bug/security fix) the merrier, but... they shouldn't be at or near the top of the security onion priority list.
2406[18:24:30] <ekleog> blackflow: I was actually in a debate with a friend about the update process of debian and whether it was a good thing for [some use case]
2407[18:24:31] <joepublic> To summarize, so far the answers are "only CVEs get in", "also bugfixes but i dunno what counts", and "don't worry about it".
2408[18:24:54] <nkuttler> joepublic: feel free to give better answers
2416[18:27:15] <blackflow> joepublic: if that "don't worry about it" was in reply to my statement, I never said that. I said don't give TOO much attention to it. why? because there's a vast pool of unknow or known-but-unfixed (security) bugs everywhere.
2417[18:27:35] <blackflow> for teh linux kernel for example, the average time between introducing and fixing one is several YEARS......
2418[18:28:17] <joepublic> blackflow, no, I understand your point about longstanding bugs. I am talking about speculation over what might be the policy vs. what is the actual policy.
2419[18:28:18] <blackflow> there's an industry and market for zero days which only means trading publicly unknown stuff is... profitable. thus, updates (which are fixes to known vulns) should not be top priority for the security process.
2420[18:28:39] *** Quits: Zvmdyv (~Zvmdyv@replaced-ip) (Remote host closed the connection)
2426[18:30:51] *** Quits: ixc (~x@replaced-ip) (Quit: Lost terminal)
2427[18:31:14] <joepublic> The reasons listed on the following page are the best canonical (non-speculation) source I can find on short notice: replaced-url
2428[18:31:15] <olric> how to use x apllication in crontab ?
2429[18:31:53] <nkuttler> olric: set the DISPLAY variable
2447[18:34:03] <nifker> joepublic: it does not exist ...
2448[18:34:03] <blackflow> olric: no, you set DISPLAY=":0.0" at the top of the crontab file as any other env var
2449[18:34:18] <nifker> joepublic: kde says its missing
2450[18:34:29] <nix64bit> i want to find large files in directories in my home, is this correct? It seems very slow? du -a /home/peter | sort -n -r | head -n 5
2474[18:39:36] <Cerebr0> Hi there ! I'm trying to install npm, followed everything and i got nodejs installed, but no tracks of npm at all... Anyone got an idea ?
2475[18:40:04] <blackflow> though I'm not convinced setting DISPLAY is the only thing required. I think you need to run it as the user who is logged into a session (beacuse of the way DM sets up device permissions)
2476[18:40:33] <nkuttler> yes, of course, the user needs access to the display
2477[18:40:49] *** Quits: scream (~scream@replaced-ip) (Remote host closed the connection)
2504[18:51:16] <dpkg> Sure, testing might be shinier than stable, but are you prepared to be continually updating your system? Things that worked today will break tomorrow. Configuration file formats will change and you'll have to fold your changes in yet again. Testing is a moving target and if you'd rather work *with* your computer than working *on* your computer, you might not want that. See <testing security>.
2505[18:51:16] <kaste_> I have a grueling upgrade from stretch behind me and figure, why not get the next one out of the way as well
2506[18:51:29] <petn-randall> kaste_: buster is not even released yet.
2507[18:51:37] <kaste_> it's testing, no?
2508[18:51:42] <kaste_> I am not going for sid
2509[18:51:52] <petn-randall> kaste_: So unless you want to beta-test an unreleased suite, stick with stable.
2512[18:52:35] <petn-randall> kaste_: Did you read the factoid above?
2513[18:53:07] <kaste_> Trust me, I ran testing for years. I know what it means
2514[18:53:18] <joepublic> kaste_, during the upgrade you will have the stretch packages + the buster packages all at once. at the close of the operation you won't have so much.
2515[18:53:21] <kaste_> I know why that is not recommended and why you advise against it
2516[18:53:25] <petn-randall> kaste_: Then you wouldn't be asking that question, I think.
2526[18:56:00] <kaste_> petn-randall: I know they existed back then, yes I also used it for most tasks. I don't specifically remember using full-upgrade
2527[18:56:13] <kaste_> It could be that I didn't notive because that was on rather big machines
2597[19:11:30] <jelly> but hey, welcome to buster! If you have further issues, there's a separate channel
2598[19:11:33] <SPF> hmm, every time I install debian and afterwards remove the install usb pendrive it cannot find /dev/sdb1 and I have to recover and manually update grub config :(
2599[19:11:40] <jelly> !debian-next
2600[19:11:40] <dpkg> #debian-next is the channel for testing/unstable support on the OFTC network (irc.oftc.net), *not* on freenode. If you get "Cannot join #debian-next (Channel is invite only)." it means you did not read it's on irc.oftc.net.
2601[19:11:58] <kaste_> thanks
2602[19:11:58] <petn-randall> SPF: Sounds like you've used unetbootin or rufus to create the USB installation stick.
2603[19:12:42] <SPF> petn-randall: no, I use cp
2604[19:13:18] *** Quits: chiluk_ (~quassel@replaced-ip) (Remote host closed the connection)
2620[19:24:16] <kaste_> There is one thing left, that I already had on stretch
2621[19:24:43] <kaste_> dante won't start on boot. It keeps complaining it can't bind to the ipv6. When I then start it after boot, everything is dandy
2648[19:33:17] <SanchoPensa> I have just inserted an USB stick and partitioned and formatted it with gparted.
2649[19:33:17] <SanchoPensa> Now Gparted does still recognize it, but the system doesn't and Gparted would not mount it any longer either, the mount option is greyed out, but it recons the stick with all the metadate correctly. What am I missing?
2662[19:38:22] <Trollstoi> SanchoPensa: it's not the stick that's getting mounted, it's the partitions on it (classically a single fat32 partition, nowadays sometimes exfat, too)
2664[19:39:38] <Trollstoi> SanchoPensa: did you create partitions? Also, partition scheme is typically mbr for pendrives (doesn't mean others cannot work)
2670[19:40:51] <rwp> SanchoPensa, You partitioned a USB stick? Did you create a file system (using mkfs) so that it had a file system to be able to mount it?
2673[19:42:29] <SanchoPensa> Trollstoi: rwp: yes, I did create a partition and I formatted it to fat 32
2674[19:43:34] <rwp> I suggest mounting it from the command line and then looking at the errors it produces. And also looking in the system log for behind the scenes kernel messages.
2675[19:43:54] <rwp> The error messages it produces will say what is happening.
2676[19:43:56] <zophyx> i never really loved my mother, so i write computer proigrams to hide my pain,my disappointment is evident in many open source code balls
2681[19:44:57] <rwp> Also when you remove and insert it again the system log will report what partitions are found on it. Or you can 'cat /proc/partitions' and look.
2699[19:51:18] *** PaddyF is now known as PaddyTEST
2700[19:51:33] <SanchoPensa> actually with a correclty mounted Stick, you would just be able to copy that .iso, it is really so simple, dd takes for ever...
2722[19:55:05] <SanchoPensa> petn-randall: yes it is indeed!
2723[19:55:09] <rwp> They do the same thing. However I am surprised that dd would be significantly slower than cp. I think that means dd hasn't been given a large enough block size.
2724[19:55:23] <kre10s> SanchoPensa: use a larger block size
2752[20:01:14] <SanchoPensa> watchcat: :D yep. will do.
2753[20:01:25] <watchcat> you don't have to reformat.
2754[20:01:49] <blackflow> 27 years later, we _still_ can't force interrupt processes in D state.....
2755[20:01:53] <rwp> The iso image contains the format. When it is copied over the device it will carry the format with it. Any formatting you do before that will be overwritten.
2781[20:05:40] <blackflow> SanchoPensa: with smaller block sizes there's more fsync going on but that also means better latency and less chance for uninterruptible states
2784[20:06:52] <rwp> But basically a disk is considered "high speed I/O" and therefore not interruptable. But USB nand is actually very slow to write. Even though it uses the high-speed disk system.
2785[20:07:00] <SanchoPensa> my problem is actually a whole different one: my linux broke during boottime for some reason, that I could not figure out yet. So I reinstalled it, I have a separate home partition, so no harm done, right? or so I thouhgt. This ancient piece is so ancient, that debian wouldn't recon the graphics adapter any longer.
2794[20:07:56] <rwp> It annoys me when working support for hardware is dropped. I have had that hit me too.
2795[20:08:02] <SanchoPensa> So now I am creating a debian 6 stick, and will then upgrade three times, as the tinkering wif dat nvidia drivers gives me a hell of a bore...
2798[20:08:22] <rwp> However sometimes it is simply moved into a different package. Look around and you might find a package named "legacy" or something containing the driver you need.
2799[20:08:56] <SanchoPensa> rwp: ya it isn't actually dropped, it DID work with a stable version, only the reinstall didn't, so support is basically there, but the drivers don't ship any longer...
2801[20:10:33] *** Quits: electro33 (uid613@replaced-ip) (Quit: Connection closed for inactivity)
2802[20:10:34] <diogenes_> SanchoPensa, what about nouveau?
2803[20:10:38] <SanchoPensa> you basically CAN repair that system, but it requires a lot of tinkering; setting some non-free repos, uninstalling the good for nothing driver, and then reinstalling a suitable one, while the trick is basically the FINDING OUT wich one it is, and where to get it...
2804[20:10:47] <SanchoPensa> diogenes_: what is that?
2811[20:12:26] *** Quits: conta (~Thunderbi@replaced-ip) (Quit: conta)
2812[20:13:07] <SanchoPensa> oh. ok. well, the legacy ones basically work pretty fine, and I ahven't made all too good experiences with open source drivers...
2813[20:13:13] <SanchoPensa> but let's see.
2814[20:13:23] <SanchoPensa> in a day or so, I will know. :D
2815[20:14:02] <diogenes_> SanchoPensa, there is nothing to know about them, they come included in the kernel when you do a fresh install
2816[20:14:03] <rwp> The nouveau driver for nvidia has improved a lot in recent times. I am using it now instead of the nvidia driver.
2817[20:14:14] <diogenes_> by default your nvidia card runs nouveau
2818[20:14:32] <diogenes_> rwp, ++ i'm using nouveau and im happy with it
2819[20:14:38] <diogenes_> no need for proprietary crap
2824[20:16:06] <SanchoPensa> well, first of all, this cp procedure has to finish, and when it eventually does, as described, I will install, and then upgrade right away.
2825[20:16:08] <joepublic> "good for nothing" and "freedom respecting" would be just opinions, except that the second proves the first false.
2827[20:17:05] <SanchoPensa> joepublic: you got me wrong there, buddy, i have an all black screen, that is, what I meant good for nothing, meaning only in context with my machin, that was not a general assertion..
2828[20:17:40] <joepublic> just pointing out it's good for something, even if not something useful or functional. No offense meant.
2829[20:17:49] <watchcat> depending on the write-speed of the usbstick, 4+ gb can take a while.
2831[20:18:25] <diogenes_> eif it's ntfs then it could take hours
2832[20:18:26] <watchcat> you downloaded the dvd?
2833[20:18:43] *** Quits: donofrio (~donofrio@replaced-ip) (Remote host closed the connection)
2834[20:19:06] <Trollstoi> SanchoPensa: that's not mint debian, but afaik AVLinux (@ bandshed.net) has some *scripts* that ideally take care of identifying an nvidia card and getting the drivers
2837[20:20:02] <medfly> Hi #debian. My friend maintained a piece of software. debian has some patches to it. I'd like to merge them into a new release. Can I implicitly do that without licensing issues?
2838[20:20:15] <SanchoPensa> Trollstoi: nice! I basically know, how to do that manually, but really... sudo apt-get dist-upgrade is so much less effort...
2839[20:20:44] <medfly> i.e. have them under the original license
2846[20:27:26] <rwp> Hi medfly! Contacting the maintainer is best. This might be a wishlist bug report and then discussion. Thank you for helping Debian!
2887[20:42:17] <joepublic> Had I been microsoft in the times when they were being sued for including a browser with their operating system, I think I would have bought an island, named it "republic of microsoft does not care" or something, and said "you want our products? respect our laws which say you get a browser with the os instead of having to download one." they had the money and market position at the time to do that.
2888[20:42:17] *** Quits: clay (~clay@replaced-ip) (Remote host closed the connection)
2939[21:23:36] <jelly> SanchoPensa: packages often have specific code to make them upgradeable from eg. 7 to 8, that gets removed after 8. Do NOT skip releases. Do not skip reading each release notes.
2998[21:35:40] <joepublic> hweaving, no, it's the dual goals of 1. giving people the best information, and 2. considering not making more work for volunteers who support debian by giving out dumb advice
2999[21:36:09] <hweaving> I thought you meant you had a specific case
3000[21:36:44] <joepublic> yes, but the case was a while ago. people have jumped out of planes without parachutes in the past and lived but it's deadly bad advice to say "yeah you can do that." Which jelly is reminding me.
3001[21:36:49] <jelly> not crossgrading, asking about going from debian 6 to 9 directly
3002[21:37:12] <hweaving> I do have a specific case so I'll ask if I may -- if I'm attempting to do "apt-get --download-only install dpkg:amd64 tar:amd64 apt:amd64" to prepare crossgrading those packages, why would it complain about unmet dependencies? (e.g. Depends: libc6:amd64 but it is not going to be installed)
3004[21:37:47] <hweaving> I thought the intent of "--download-only" was that it would set up the package files so I could batch-install them later, but I'm not getting any packages at all.
3005[21:38:01] <jelly> apt-get install always checks for dependencies, even if it stops after "--download-only"
3012[21:39:52] *** Quits: rattlebattle79 (~steinar@replaced-ip) (Remote host closed the connection)
3013[21:40:04] <hweaving> Hm, I'll have to figure out why the dependencies weren't going to be installed
3014[21:40:23] <rant> is there any simple graphical way to print a document mirrored? I know there is a switch for lpr to do this, and you could of course convert to ps and mirror the docmentbefore printing..but I see no simple option in the print dialog for it. "Reverse Portrait
3015[21:40:30] <rant> orientation doesnt seem to do it
3016[21:42:10] <hweaving> Is there a way to basically force all dependency packages to be included in the --install-only command?
3031[21:51:35] <agio> hi, I was wondering if there is command to make a directory (for mounting external disks to) as root, but the tell mkdir or whatever, that the owner of this directory should be some regular, non-root user?
3040[21:58:08] <agio> digdilem: what about with sudo? the chown won't success, unless you prefix it with sudo, becuase its run by the regular shell; sudo mkdir -pv /the/dir && sudo chown -v user: !$
3042[21:58:36] <digdilem> agio, this is debian, sudo isn't on by default. I assume you act as root
3043[21:58:56] *** Quits: nehemiah (~nehemiah@replaced-ip) (Remote host closed the connection)
3044[21:58:59] *** Quits: xcm (~xcm@replaced-ip) (Remote host closed the connection)
3045[21:59:42] <digdilem> if this particular thing is common for you, you might want to write a script that takes three arguments which will make calling it with sudo easier
3106[22:28:05] *** Quits: mihi (~mihi@replaced-ip) (Remote host closed the connection)
3107[22:28:59] *** Quits: kapil____ (uid36151@replaced-ip) (Quit: Connection closed for inactivity)
3108[22:29:07] <n4dir> you might want to do "echo mv ..." first, to see that the glob * matches correctly.
3109[22:30:37] <rwp> I prefer 'rename' for such things. FTW! Works great.
3110[22:30:48] <hweaving> OK it looks like one workaround is "apt-get download" rather than "apt-get --download-only install"
3111[22:30:54] <rwp> hweaving, Are you trying to cross-upgrade from a running 32-bit system to a 64-bit system?
3112[22:30:58] <hweaving> so this way I can at least grab the packages without it freaking out over the dependencies
3113[22:31:04] <hweaving> rwp: why yes I am insane
3114[22:31:11] * rwp laughs
3115[22:31:12] <hweaving> I did, however, back it up first :p
3116[22:31:33] *** Quits: dastier (~dastier@replaced-ip) (Remote host closed the connection)
3117[22:31:38] <rwp> People have done it before, in a variety of different ways, all uniquely different. There is no path. You have to cut your own trail. But it is possible.
3118[22:32:31] <rwp> I always have LVM on my systems. Therefore my path is to create new LVs and install a 64-bit system there using debootstrap. Then boot it. Then mount up the data partitions.
3120[22:33:00] <rwp> Other people have converted to multi-arch first. Then installed a 64-bit kernel. Rebooted to it. Then installed 64-bit userland. Then removed 32-bit userland.
3122[22:33:28] <rwp> I am sure you found several blog articles posted on the net from people chronicalling their adventure through it?
3123[22:33:36] <hweaving> I'm currently running a 64-bit kernel but that's all I've upgraded. I couldn't do the normal dpkg/apt/tar crossgrade so I'm having to do that manually
3131[22:35:27] <rwp> There may be confusion because there is also an older 32-bit userland available too, IIRC, fuzzy memory about it, and that may be the wrong one for you and it will be conflicting.
3135[22:35:58] <agio> I've just installed debian minimal, and when I press | , a ~ gets printed into the terminal. I ran dpkg-reconfigure keyboard-configuration, and tried changing the keyboard model to generic 101, and the problem still occurs, any ideas?
3154[22:42:04] <rwp> hweaving, Just as a hint... The debian-installer makes a great rescue system if you get into a bind and can't boot anymore. Can boot debian-installer, Advanced, Rescue, and rescue boot a system.
3155[22:42:20] <rwp> Hopefully you won't need that rescue path though. :-)
3156[22:42:23] <agio> rwp: I connected another keyboard via USB, same problem
3160[22:42:56] <rwp> You might try: setxkbmap -model pc104 -layout us
3161[22:43:08] <rwp> and optionall setxkbmap -model pc104 -layout us -option compose:menu -option terminate:ctrl_alt_bksp if you like me like those options.
3162[22:43:29] <agio> im in a miniminal install, linux terminal and shell only
3164[22:43:35] <hweaving> rwp: thanks, the issue seems to be that dpkg -i was willing to install apt without the required packages necessary to configure
3165[22:43:36] <agio> no wifi
3166[22:43:47] <rwp> That also resets xset settings. Therefore my startup is the above followed by some more custom xmodmap twiddling followed by xset r rate 275 45 to speed up autorepeat for me.
3167[22:44:04] <n4dir> agio: as in "no gui at all" ?
3172[22:44:50] <rwp> No problem. That's my usual environment anyway.
3173[22:44:53] <agio> just debian standard tasksel
3174[22:45:04] <n4dir> shooting from the hip: you could try either "dpkg-reconfigure console-data" or same for console-setup (rather the former)
3175[22:45:04] <jhutchins> agio: That sounds more like a locale configuration issue than a hardware issue.
3176[22:45:27] <n4dir> just was wondering what are the right words for what jhutchins said.
3177[22:45:34] <agio> jhutchins: so what fixes that? dpkg-reconfigure tzdata?
3178[22:45:46] <jhutchins> agio: British vs American keyboards have special characters on different keys.
3179[22:45:47] <rwp> typo there. tzdata is timezone data.
3180[22:45:55] <jhutchins> !locale
3181[22:45:56] <dpkg> A locale is a set of rules for presenting information to humans according to local conventions (date format, thousands separators, language, etc.). Ask me about <locales> to establish on a Debian system. replaced-url
3182[22:46:16] <rwp> I don't think locale is the control for input though. That is mostly for output. AFAIK.
3190[22:49:11] <rwp> Given the problems you are describing I would load the default kernel map first then try other things second.
3191[22:49:27] <rwp> (I use that with dumpkeys to sed change some things for me at boot time.)
3192[22:50:13] <rwp> loadkeys is in the 'kbd' package.
3193[22:50:13] <areyouloco> !locales
3194[22:50:14] <dpkg> Use 'dpkg-reconfigure locales' to get it up and running. This generates <locale> definitions and also edits /etc/default/locale which sets the $LANG environment variable at login time. Use "LANG=C command" to change the output language for a one off command, ask me about <localised errors>. See also <mac locales>. replaced-url
3195[22:50:15] <agio> looking at man loadkeys, but I don't understand what a "kernel map" is?
3196[22:50:49] <rwp> The kernel map is the data map from keyboard scan codes to characters.
3197[22:51:23] <rwp> xmodmap will have some description of the key codes replaced-url
3200[22:51:46] <agio> thanks, so is that what `dpkg-reconfigure keybord-configuration" modifies?
3201[22:52:22] <rwp> For example a PC-104 returns decimal 101 value for hitting the keyboard (not keypad) Backspace key. Linux maps that to the US-ASCII DEL character.
3212[22:55:31] <rwp> Hmm... I have kbd installed but do not have keyboard-configuration installed.
3213[22:55:37] <agio> rwp: so the sequence looks like this: human/user presses <DEL> key, keyboard generates decimal 101 char, sends to kernel over PCI, kernel maps it to ASCII DEL, terminal driver emits that from /dev/tty1, and finally shell get it at command line?
3214[22:55:51] <rwp> Basically yes.
3215[22:55:59] <rwp> However there is no PCI involved in the keyboard path.
3216[22:56:24] *** Quits: blitzed (~blitzed@replaced-ip) (Remote host closed the connection)
3217[22:56:28] <rwp> Originally in the IBM 5150 (ibm pc) it was the large DIN connector. Then changed to the PS/2 connector. Now USB almost everywhere.
3218[22:56:33] <agio> I meant if its connected over PCI bus?
3260[23:04:54] <rwp> I should say this in -offtopic but was in in a hotel trying to get a copy of my passport. They had locked up the keyboards but left the mouse open. I was able to cut and paste using a tab location bar as an editor space only by using mouse cut and paste. Painful. But got me a copy of my passport late one night.
3271[23:09:49] <rwp> I don't know your goal with that system agio. Is it just temporarily offline now due to lack of an available network connection? Or are you trying to keep it offline as a project goal?
3272[23:10:37] <rwp> The apt-offline thing is useful for unconnected systems such as a C&C mill controller in a garage shop that is not on a network. For example.
3273[23:11:03] *** Quits: krytarik (~krytarik@replaced-ip) (Quit: 전 이만 갑니다)
3275[23:11:35] <agio> its a laptop, im trying to get a full debian install DE, wifi - everything. but i've literally just completed netinstall (wifi not working due to no-firmware) , im in a bash/linux terminal , and my keyboard doesn't workd
3277[23:12:35] <n4dir> i always get confused what exactly to do, but i seem to recall there is also /etc/default/keyboard (or ../keymaps).
3278[23:12:44] <agio> rwp: ah, so apt-offline is how you would get package updates to an offline system?
3279[23:12:54] <rwp> Yes. Exactly!
3280[23:13:00] <jhutchins> GDM will give you mouse functions on a terminal.
3281[23:13:00] <n4dir> loadkeys should work too though.
3282[23:13:15] <deb76556> my laptop ran out of battery overnight. now when I try to boot it it tells me "no bootable device". I can mount the hard drive from a live CD, so what could the problem be?
3283[23:13:20] <deb76556> or rather how can I get it to boot again?
3284[23:13:21] <rwp> I worry very little about the network security of a C&C mill controller when it is not ever connected to a network. :-)
3285[23:13:35] <n4dir> jhutchins: gpm?
3286[23:13:36] <jhutchins> !fixgrub
3287[23:13:36] <dpkg> To reinstall <GRUB> boot to your Debian install disk/live CD, switch to the other console (Alt-F2), mount your root filesystem (mount -t ext4 /dev/whatever /target ; mount --bind /dev /target/dev ; mount -t proc none /target/proc ; mount -t sysfs none /target/sys), chroot into it (chroot /target), run "mount /boot/efi" on EFI and "update-grub && grub-install /dev/whatever". See also <rescue mode>, <dual boot guide>, <supergrub>.
3290[23:14:02] <dpkg> Debian-Installer has a recovery ('rescue') mode, which can be used to reinstall the GRUB or LILO boot loaders. See section 8.7 of the <install guide> ("Recovering a Broken System") for more details: replaced-url
3291[23:14:10] <deb76556> jhutchins: I did all that except for the grub-install step. what dev should it use?
3303[23:16:09] <digdilem> deb76556, yes, could easily be a bios issue
3304[23:16:13] <agio> rwp: I was able to scan output of dmesg, and found this line: "input: AT Translated keyboard set 2 as /devices/platform/i8042/serio0/input/input0"
3305[23:16:22] <rwp> Definitely possible. Older machines have probably drained the CR2032 battery.
3306[23:16:23] <deb76556> I'm in the bios settings at the moment, but I can boot into a live CD to check what grub-install says
3307[23:16:33] <deb76556> I think it's grub-efi though
3308[23:16:39] *** Quits: hanasaki (~hanasaki@replaced-ip) (Remote host closed the connection)
3309[23:16:42] <digdilem> just check while you're there that the hard drive is listed as a boot device
3311[23:17:10] <rwp> The cmos battery may be failing. In which case those are cheap to replace. Frequently under the keyboard. Easily replaced.
3312[23:17:25] <deb76556> I don't see any boot devices listed
3313[23:17:52] <Truxx> I'd like to ask if there is a separate channel for issues with Debian Live? I just wanted to give it a try first before install, but does not work so far.
3315[23:17:57] <deb76556> I see 4 options I can change: "boot mode" is set to "legacy support", "boot priority" is set to "uefi first", "usb boot" is enabled and "pxe boot to lan" is disabled
3316[23:17:58] <rwp> I would try loading defaults and saving and then giving the machine a full power off, pause, power cycle step.
3317[23:18:19] <deb76556> then there's a blank limne, the word 'efi', another blank line, and the word 'legacy'. that's all I see on the boot page
3318[23:18:28] <rwp> Sigh. Complications. You need to know if your system was legacy or efi.
3334[23:20:53] <rwp> If it is a bios problem then you don't need to reinstall grub.
3335[23:20:58] <agio> rwp: solution: 1) run dpkg-reconfigure keyboard-configuration 2) choose generic 102 (Intl), and US from the options 3) reboot *it only worked after I rebooted*
3336[23:21:32] <rwp> ah... I can see that helping to make it work. After a reboot it would have a default kernel map.
3347[23:24:12] <rwp> The good news deb76556 is that if you are booting the live cd and mounting your disk then you are guarenteed to be able to figure it out. With persistence.
3370[23:28:34] <rwp> Truxx, You will need to join the OFTC network and then join #debian-live on that network.
3371[23:28:34] <hweaving> rwp: well I found out one inconsistency -- apparently my Debian ISOs have an older version of libc6:amd64 compaed to libc6:i386, and/or I had manually done a security update a while back
3372[23:28:35] <n4dir> Truxx: got you. Perhaps it is gone? never was that active, iirc.
3373[23:28:38] <hweaving> I'm going to try to sync the libc6 versions now
3374[23:28:47] <Truxx> rwp Ah, ok, I see
3375[23:29:05] <Truxx> rwp: Thank you for the hint
3376[23:29:16] <rwp> IRC is not only one network. There are many.
3378[23:29:54] <rwp> hweaving ah... Yes. I think multi-arch (not sure) needs to have same packages be installed as the same version. I think. Not sure. Don't quote me on that.
3391[23:35:33] <deb76556> after running "grub-install /dev/sda" I see that /boot/efi/EFI/debian/grubx64.efi's timestamp has changed to the current time. that wasn't happening before
3392[23:36:00] <rwp> That sounds like a good thing.
3412[23:42:36] <rwp> That does sound like a cmos battery problem. Especially if it is an older machine. Especially if it spent some years turned off unpowered draining that battery.
3413[23:42:50] *** Quits: alexandros_C (~quassel@replaced-ip) (Remote host closed the connection)
3414[23:43:01] <deb76556> the !fixgrub help text was a little off for me: it said "chroot into it (chroot /target), run "mount /boot/efi" on EFI" but wouldn't I want to mount everything before doing the chroot?
3419[23:44:59] <rwp> 2015 seems too young for a cmos battery problem. That usually occurs with models in the mid-2000 range like Thinkpad x201's and T60s and so forth.
3420[23:45:12] <deb76556> it is a lenovo
3421[23:45:23] <deb76556> which I think is genetically related to the thinkpad
3422[23:45:51] <rwp> Thinkpads were originally IBM but then Lenovo bought the brand from IBM. Lenovo had been making them for IBM previously.
3423[23:46:14] <rwp> But Lenovo also makes their own branded devices that are not in the Thinkpad line.
3424[23:46:33] <rwp> But most laptops are similar in having cmos ram with a battery that keeps the ram and the system clock powered.
3426[23:47:05] <rwp> However if your machine is from 2015 that seems too young to be having a cmos battery problem. But don't know. Could be.
3427[23:47:17] <rwp> Good luck with it though! Hope you figure it out!
3428[23:47:35] <agio> If a debian install is done onto a brand A, model foo laptop. I know its possible to take the harddisk put it into a brand B, model bar laptop. but could you actually use that OS as a daily driver? usually you have to change some network adapter device names etc? is there much work in making an install done on another machine usable on a different machine?
3429[23:47:36] <deb76556> I think I likely need to buy a new laptop
3430[23:48:07] <deb76556> in the mean time, I was thinking of transplanting the hard drive into a totally different laptop. is that likely to work?
3431[23:48:21] <rwp> I think if it is a bios problem then you shouldn't need to reinstall grub after this failure but just reset the bios configuration.
3432[23:48:32] <rwp> I hate to say this but next time it happens try just that and see if it is enough.
3433[23:49:01] <rwp> Yes! You can move the hard drive (hopefully an SSD?) to a different machine and it should work. Except...
3434[23:49:19] <rwp> Except for the difference in grub legacy boot and grub efi boot. Since that is a hardware thing.
3435[23:49:35] <rwp> But if the other system is also an EFI system then it should just work.
3436[23:49:58] <rwp> And in the other case of moving a legacy boot disk to another legacy boot system that always works. I do that *all of the time*. Always works.
3437[23:50:28] <rwp> But crossing the line from legacy to efi and efi to legacy is always troublesome for me. Fiddly. But can usually be made to work.
3438[23:51:28] *** Quits: pringau (~pringau@replaced-ip) (Remote host closed the connection)
3439[23:51:29] <agio> yes (its legacy BIOS to legacy BIOS) and I know it kind of works but there are device naming mismatches etc
3440[23:52:16] <agio> my question is: which is less work, to fix up those device naming mismatches etc or just re-install a new OS?
3445[23:54:04] <rwp> I guess I should say that after the transplant one might need to rebuild the initramfs for any needed drivers that are different in the new system.
3446[23:55:11] <rwp> "update-initramfs -u -k all" or "dpkg-reconfigure linux-image-4.9.0-8-amd64" or similar might be needed after installing a firmware driver needed by the new machine. But then it should be good!
3447[23:55:19] <agio> rwp its the wifi interfaces, e.g on one machine the wifi NIC appears as wlp3s0 and on the other it appears as wlan0
3452[23:56:27] <rwp> In the old days there was /etc/udev/rules/70-persistent-net.rules which would keep NICs named whatever based upon the ethernet address.
3453[23:56:33] <deb76556> I don't think it was a bios problem, because it started working when I did the "grub-install /dev/sda" line. I've had a similar issue twice before but on those two occasions all I had to do was update-grub
3454[23:56:49] <rwp> When moving a disk to a new machine the ethernet address is different and therefore it gets a new name assigned.
3455[23:57:06] <rwp> In the new world of system they rename the NICs to wlp3s0 like names.
3456[23:57:36] <rwp> So that just means you need to use the new name. Or force the old name. Or something along those lines. Lots of people have opinions on it. It can be an emotional topic.
3457[23:58:02] <kre10s> agio: this should work by default. set up the network bits to be automatic. you will need the hardware drivers for both laptops installed.
3458[23:58:08] <rwp> That's strange deb76556 because then that would mean bits on your disk are changing? Is it a spinning disk or an SSD?
3459[23:58:20] <deb76556> it's an SSD
3460[23:58:33] <rwp> I would be inclined to snapshot the partition table and boot area and then capture it if it is a problem and then bit compare and see if it changes.
3463[23:59:23] <kre10s> agio: the hardware will be detected each time the os loads and the right drivers get loaded automatically. no idea what happens when you suspend to disk thought...
3464[23:59:24] <rwp> I have had some cheap OCZ SSDs before that were really quite unreliable. It's possible that is your problem too.
3465[23:59:34] <deb76556> this one wasn't very cheap
3466[23:59:39] <deb76556> it's a samsung something pro