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