| cathode | hi | 06:08 |
|---|---|---|
| Guest83465 | Good morning | 06:17 |
| cathode | i'm trying to force rename a network interface to a meaningful name but it's "not working" and i'm not sure how to look to see why it's not working | 06:19 |
| cathode | https://www.punyal.com/2016/08/18/ubuntu-16-04-rename-a-network-interface/ <-- using this method | 06:19 |
| cathode | ubuntu 17.04 | 06:19 |
| Guest83465 | cathode: Read the last two sections of https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ | 06:20 |
| === Guest83465 is now known as lordievader | ||
| cathode | ok thanks | 06:28 |
| cathode | after i add my own .link files, how do i apply them other than rebooting? | 06:28 |
| lordievader | I suppose this should do the trick: https://unix.stackexchange.com/questions/39370/how-to-reload-udev-rules-without-reboot | 06:31 |
| lordievader | Though I am not sure if udev will rename an existing device. | 06:32 |
| cathode | holy crap it worked | 06:34 |
| cathode | thanks | 06:34 |
| cathode | i had to reboot | 06:34 |
| cathode | but my network interfaces are correct now :D | 06:34 |
| lordievader | Good to hear the problem is solved. | 06:40 |
| === funabash1 is now known as funabashi | ||
| ahasenack | smb: hi, I prepped https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400 for an SRU | 13:59 |
| ubottu | Launchpad bug 1707400 in libvirt (Ubuntu Xenial) "libvirt-bin doesn't regenerate apparmor cache in postinst" [Medium,In progress] | 13:59 |
| ahasenack | rbasak: I wonder if "interesting bugs this week" and their investigation would be good material for blog posts | 13:59 |
| rbasak | ahasenack: +1 | 14:01 |
| smb | ahasenack, was that just for my info or was there something I was expected to do? | 14:12 |
| ahasenack | smb: just fyi | 14:13 |
| smb | ahasenack, ah good. :) | 14:13 |
| === Piper-Off is now known as Monthrect | ||
| === Monthrect is now known as Piper-Off | ||
| might_get_loud | Hi all, im hosting a little PHP app on ubuntu server, and the app is in /home/$USER/app folder. I modified groups for $USER to be have www-data group, and www-data user to be part of $USER group. I also set up shared permisions on all files na folders to match users and groups with chmod g=u. But i cant access app, i have 500 internal server error. When i change owner of those files to www-data:www-data i can access app just fine. Anyone | 16:27 |
| might_get_loud | have any idea? | 16:27 |
| might_get_loud | Im using 16.04 and php 7.1 | 16:27 |
| smoser | nacc, given a git-ubuntu git repo, can i produce a .orig easily? | 16:44 |
| nacc | smoser: yes, with a branch i have :) | 16:44 |
| nacc | smoser: (which uses pristine-tar) | 16:45 |
| ahasenack | doesn't build-source produce one? | 16:45 |
| smoser | that just happens to be more than i wannted | 16:46 |
| ahasenack | ok | 16:46 |
| nacc | ahasenack: well, build-source uses pull-lp-source in master | 16:47 |
| ahasenack | what does pristine-tar do? tars everything but debian/ up? | 16:48 |
| ahasenack | and calls it whatever version you have as the top most in d/changelog? | 16:48 |
| nacc | ahasenack: well, we use pristine-tar to import things | 16:49 |
| nacc | ahasenack: so it's actually taking in the tarball as in the archive | 16:49 |
| smoser | nacc, link ? | 16:50 |
| smoser | i assumed i'd 'pristine-tar checkout <tarball>' but it wants a branch named 'pristine-tar' which isnt there. | 16:50 |
| nacc | smoser: one sec | 16:52 |
| nacc | smoser: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+ref/lp1698402 | 16:52 |
| nacc | smoser: yeah, that's the issue for us, as we have both a debian and ubuntu pristine-tar branch | 16:53 |
| nacc | smoser: the above branch abstracts that out | 16:53 |
| smoser | nacc hm.. i dont see how you tell pristine-tar which is the branch to look at | 17:01 |
| smoser | http://paste.ubuntu.com/25227663/ | 17:02 |
| mdeslaur | nacc: I am going to disable http2 support in apache2 so it can get out of -proposed | 17:02 |
| nacc | mdeslaur: ok | 17:02 |
| nacc | smoser: don't use gbp | 17:03 |
| nacc | smoser: it won't work with our repository | 17:03 |
| nacc | smoser: otp, give me a bit | 17:03 |
| smoser | i was looking at your code | 17:04 |
| smoser | and thats what it seemed to do | 17:04 |
| smoser | also invoking pristine-tar basically does the same thing | 17:04 |
| nacc | smoser: we use gbp to import it and then reproduce the pristine-tar | 17:04 |
| Apocope | I have a server I updated from 12.04 to 14.04 using do-release-upgrade. Now cups won't see groups from ldap. How can I sort this out? | 17:04 |
| ahasenack | Apocope: were you using libnss-ldap? | 17:05 |
| ahasenack | or was cups contacting the ldap server directly | 17:05 |
| nacc | smoser: https://git.launchpad.net/~nacc/usd-importer/commit/?id=a87d89645f0cac3bddf58eb77d567f3999e16de3 | 17:05 |
| smoser | oh thats sick | 17:06 |
| smoser | you should fix pristine-tar | 17:06 |
| smoser | to take a branch | 17:06 |
| Apocope | ahasenack: Yes, libnss-ldapd, configured via puppet. Oddly, I have a server that was installed as 14.04, same puppet stuff and it works properly. | 17:07 |
| nacc | smoser: yeah, i think we have a bug for that somewhere | 17:08 |
| ahasenack | Apocope: if relying on libnss-ldap, you can use getent passwd <user> to test ldap, where <user> exists in ldap only | 17:08 |
| ahasenack | (or libnss-ldapd, I assume it's the same idea: a new nss module in /etc/nsswitch.conf for the "passwd:" line) | 17:09 |
| smoser | nacc, https://bugs.launchpad.net/ubuntu/+source/pristine-tar/+bug/1708214 | 17:10 |
| ubottu | Launchpad bug 1708214 in pristine-tar (Ubuntu) "support using branches with name other than 'pristine-tar'" [Undecided,New] | 17:10 |
| smoser | i just opened. didn't see an ubuntu bug at least. | 17:10 |
| Apocope | ahasenack: That works fine. My regular account is from ldap, I can log in, run sudo, all that stuff. Just, as far as I know, CUPS isn't seeing it. /etc/nsswitch.conf is identical between the working and the non-working server. | 17:12 |
| nacc | smoser: thanks | 17:12 |
| smoser | probaly https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467300 | 17:12 |
| ubottu | Debian bug 467300 in pristine-tar "Please allow several pristine-tars in the same repository" [Wishlist,Open] | 17:12 |
| ahasenack | Apocope: does your ldap server allow anonymous binds/searches, or does it need a password? | 17:13 |
| ahasenack | Apocope: in other words, do you have a password stored somewhere in /etc for libnss-ldap(d) to contact the directory? | 17:13 |
| Apocope | ahasenack: No anonymous binds. | 17:14 |
| ahasenack | Apocope: so a password is needed. Can cups read that file with the password? I forget what it is, something in /etc/ldap/ probably | 17:14 |
| nacc | smoser: also, we needed something works (well, where we are now) in 16.04, which wouldn't be able to depend on pristine-tar (or gbp in this case) taking a branch | 17:17 |
| nacc | smoser: note that we can't use pristine-tar directly anyways | 17:17 |
| nacc | smoser: because of component tarballs :) | 17:17 |
| docmur | Hey guys, I'm trying to get dropbear initramfs to work so I can decrypt my VM via SSH during boot, however no matter what guide I follow I always get an error about authorization_key file now having valid SSH keys | 17:19 |
| Apocope | ahasenack: Are you sure that cups need to be able to read that file? The system has knowledge of group info from ldap. If I run 'getent group systemadmin' I get a reasonable response. I tried setting slapd.conf to be world readable, but it didn't do anything different. | 17:21 |
| ahasenack | Apocope: when you run getent group <name>, libnss-ldapd will contact the directory to search for <name>. You said that anonymous binds/searches are not allowed, so libnss-ldap needs credentials, right? | 17:21 |
| ahasenack | maybe I misunderstood | 17:22 |
| ahasenack | it wouldn't be rootpw from slapd.conf, though | 17:23 |
| Apocope | ahasenack: Yes, you're right, but ldap accounts in general are working. My account information is stored in ldap, I can log in, my groups, from ldap show up. | 17:23 |
| ahasenack | Apocope: and what errors show up in the cups logs? | 17:24 |
| ahasenack | and, is cups running in a chroot perhaps? | 17:24 |
| Apocope | ahasenack: No chroot. "cupsd: Unknown SystemGroup "systemadmin" on line 17 of /etc/cups/cups-files.conf." "cupsd: Unable to read "/etc/cups/cups-files.conf" due to errors." | 17:25 |
| ahasenack | Apocope: cups runs as the "lp" user, right? | 17:26 |
| smoser | docmur, that sounds interesting. it might be easier for you to test outside of an initramfs. i dont have any specific hints though. | 17:26 |
| ahasenack | well, one of its processes | 17:26 |
| smoser | i do know that cirros runs dropbear from initramfs so theres nothing specifically magic there. | 17:27 |
| ahasenack | Apocope: and you can "getent group systemadmin" as root? | 17:27 |
| docmur | smoser, okay, any recommendations? I have got Dropbear to work on 14.04 (I think) | 17:27 |
| Apocope | ahasenack: cupsd seems to be running as root. 'getent group systemadmin' gives reasonable looking group information. | 17:29 |
| ahasenack | getent run as root? | 17:29 |
| Apocope | ahasenack: Yes | 17:29 |
| smoser | docmur, this is the first time i've ever looked at it in ubuntu. i notice there is a | 17:30 |
| smoser | dropbear-initramfs | 17:30 |
| smoser | which i'm guessing is what you're trying to use. | 17:30 |
| docmur | Wow, I should run the search | 17:30 |
| docmur | Let me try that package :) | 17:31 |
| ahasenack | Apocope: are there apparmor errors in the output of dmesg? something with DENIED? | 17:32 |
| Error404NotFound | Is there a super lightweight, may be single file, proxy server that I can use to forward domains to ports? I have few http servers running on 8080, 8081, 8082, and I'd rather have them access as abc.com, def.com. I don't want full blown nginx for just name->port. | 17:32 |
| ahasenack | Error404NotFound: are the multiple domains on the same ip, or different ips? | 17:33 |
| Error404NotFound | I could use different ips, say: 127.0.0.1:8080, 127.0.0.2:8081 | 17:33 |
| Apocope | ahasenack: Oh, yes. "type=1400 audit(1501695210.403:183): apparmor="DENIED" operation="connect" profile="/usr/sbin/cupsd" name="/run/nslcd/socket" pid=17838 comm="cupsd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0" | 17:34 |
| ahasenack | is that socket from libnss-ldapd? | 17:35 |
| ahasenack | or what is it | 17:35 |
| ahasenack | Error404NotFound: no, I meant, if the domains mapped to different ips in dns, I was going to suggest the most lightweight of all redirects: iptables :) | 17:35 |
| Apocope | ahasenack: nslcd is the local LDAP name service daemon. That seems important. | 17:35 |
| ahasenack | Apocope: it does. And what about the other machine where it works? | 17:36 |
| nacc | smoser: ok, off the phone now -- we don't currently provide an interface to the APIs to extract the tarballs. If you are interested in that (e.g., git ubuntu export-orig <upstream version>), file a feature request, please :) | 17:36 |
| Error404NotFound | ahasenack nah, they're all running locally, no dns involved. | 17:36 |
| Apocope | ahasenack: I'm seeing that same log, except it says ALLOWED instead of denied. | 17:37 |
| ahasenack | Apocope: this was an upgrade from which ubuntu release again? | 17:38 |
| ahasenack | trusty to xenial? Or what? | 17:38 |
| Apocope | ahasenack: 12.04 -> 14.04 | 17:38 |
| ahasenack | Apocope: try this command as root, and then restart cups(d): apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.cupsd | 17:39 |
| ahasenack | that will reload the apparmor profile but ignore any existing cache, and write a new cache out | 17:39 |
| ahasenack | then the same for /etc/apparmor.d/usr.sbin.cups-browsed (just because it's about cups too) | 17:39 |
| nacc | smoser: question re: the intent of the open-iscsi test. It's checking to see if iscsid can be started. But we've updated the systemd unit to not start unless configured. That test seems (now) to simply be invalid, should I just delete it? | 17:40 |
| Apocope | ahasenack: I just tried copying the /etc/apparmor.d/usr.sbin.cupsd file from the working server to the non-working server, restarted apparmor and cups works now. I'm just going to call that good. Thanks for your help. | 17:43 |
| ahasenack | Apocope: I think you could have a stale apaprmor cache file, I've seen that in another bug I just recently worked on, and it happened because of a release-upgrade too | 17:43 |
| ahasenack | Apocope: when you copied the file, you changed its timestamp to be $now, i.e., more recent than the cache, so apparmor grabbed that file instead of the cache | 17:44 |
| ahasenack | that bug drove me nuts for a bit because the apparmor profile was correct, yet I was still getting DENIED errors | 17:44 |
| ahasenack | Apocope: fwiw, apparmor cache files are in /etc/apparmor.d/cache | 17:45 |
| ahasenack | cool that it works now :) | 17:45 |
| Apocope | ahasenack: You're probably right about that. I'm comparing the files, and the only difference is that there's a flags=(complain) in one that's not in the other. Thanks so much. | 17:45 |
| ahasenack | I'll drink some coffee to that :) | 17:45 |
| smoser | nacc, pollinate is behind the archive in trusty-proposed | 17:49 |
| smoser | its in gitubuntu/import-cron-packages.txt | 17:49 |
| smoser | should i just import? | 17:50 |
| nacc | smoser: it's a bit racy right now, it depends on when the bot was running (i can give more detail) -- let me check one thing | 17:50 |
| smoser | i can just run import and let it do its thing too | 17:51 |
| nacc | smoser: go ahead, i need to fix something with the snap | 17:58 |
| smoser | i'm also currently importing dropbear | 17:59 |
| smoser | as i wanted to look at source per the question above and can't possibly imagine doing that any other way | 17:59 |
| docmur | I found this guide: https://hamy.io/blog/remote-unlocking-of-luks-encrypted-root-in-ubuntu-debian/ and it's works great :), if anyone needs to remotely decrypt a VM | 18:23 |
| nacc | smoser: the source in a particular release? | 18:28 |
| nacc | smoser: if you do import dropbear, can you also add it to the auto-import list? (a MP for it is fine) | 18:29 |
| ahasenack | nacc: in git ubuntu submit, what's the syntax for --target-branch? Something like "ubuntu/xenial-devel"? | 18:55 |
| nacc | ahasenack: yeah, that should be right (the bit after refs/heads/ basically) | 18:55 |
| ahasenack | nacc: ok | 18:56 |
| sarnold | hallyn: hello :) does https://github.com/shadow-maint/shadow/commit/954e3d2e7113e9ac06632aee3c69b8d818cc8952 need a CVE? | 19:26 |
| sarnold | hallyn: (asking due to https://bugs.launchpad.net/bugs/1266675 ) | 19:27 |
| ubottu | Launchpad bug 1266675 in shadow (Ubuntu) "newusers error adding more than one user" [Undecided,Confirmed] | 19:27 |
| ahasenack | powersj: rbasak: nacc: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#Merge_Proposals_and_Reviewing | 19:42 |
| ahasenack | I'll email too, so cpaelzer has something to read when he is back ;) | 19:42 |
| rbasak | Thanks! | 19:44 |
| hallyn | sarnold: i didn't think so, as i don't think it's exploitable, and isn't used by anything suid-root, | 19:50 |
| hallyn | sarnold: but i could be wrong, so if you feel it deserves one then by all means... | 19:51 |
| sarnold | hallyn: that was my initial impression but then I got to wondering if terrible tools like webmin or similar might assume the functionality works and perhaps allow someone to get more privileges than expected by "add a user" front end.. | 19:53 |
| hallyn | sarnold: sounds like issuing a cve is the prudent thing to do then | 20:01 |
| sarnold | hallyn: alright, I'll take care of the paperwork. thanks. | 20:02 |
| ahasenack | nacc: where did you have the manpage tricks documented again, for the git-ubuntu snap? | 20:07 |
| ahasenack | or is that not needed anymore? | 20:07 |
| === JanC is now known as Guest87139 | ||
| === JanC_ is now known as JanC | ||
| nacc | ahasenack: it's in the bug, one sec | 20:39 |
| nacc | ahasenack: LP: #1699526 | 20:39 |
| ubottu | Launchpad bug 1699526 in usd-importer "Extra steps needed to enable manpages in snap" [Low,Triaged] https://launchpad.net/bugs/1699526 | 20:39 |
| teward | i forsee one issue with nginx and the merges. | 20:42 |
| teward | ubuntu is ahead of Debian :p | 20:43 |
| teward | and there's an official divergence because they're tracking mainline and we're tracking stable... so... | 20:43 |
| teward | it's also out of date lol | 20:43 |
| nacc | teward: is that referring to the git-ubuntu tooling? | 20:43 |
| teward | (on the list of repos) | 20:43 |
| teward | nacc: yep | 20:43 |
| nacc | teward: nginx is a bit odd in that regard, an "Ubuntu merge" is always (at least otherwise in my experience) relative to the Debian version | 20:43 |
| nacc | teward: not strictly required, of course | 20:44 |
| nacc | teward: i think you could do it, you just need to tell `git ubuntu merge` what the new onto should be (presumably it's an upstream ref) | 20:44 |
| nacc | teward: but it probably will fail because it won't find debian/changelog there | 20:44 |
| nacc | teward: it sounds like less of a merge and more of a uupdate | 20:44 |
| teward | nacc: that's *usually* what ends up being the case with nginx | 20:44 |
| teward | with a merge every so often if there's major packaging changes, but those're easy to nitpick wrt git | 20:45 |
| nacc | teward: ack -- it almost certainly will need some love, feel free to file a bug (https://bugs.launchpad.net/usd-importer/+filebug) if you have a specific flow we can't support (with a testcase, ideally, but we can figure that out later) | 20:46 |
| teward | nacc: usually though there's not much difference in packaging, that's why i've not used a Git workflow yet for nginx merges and instead did the 'old school' way - that *may* be one of the very few packages where all that needs done manually... | 20:48 |
| teward | but hey i'm used to it :p | 20:48 |
| nacc | teward: sure, if you've got a workflow that works for you, no need to even use our tooling :) | 20:49 |
| teward | indeed. | 20:49 |
| nacc | teward: it will happily follow the archive for now | 20:49 |
| SuperLag | Is there something I can do for configuration, to not keep so many old kernels in /boot? | 21:11 |
| nacc | SuperLag: i think unattended-upgrades can autoremove if you turn it on | 21:13 |
| SuperLag | nacc: I have unattended-upgrades turned on, I'm guessing it requires more configuration beyond that. | 21:33 |
| nacc | SuperLag: yeah, there's a commented out line int he default config, iirc Unattended-Upgrade::Remove-Unused-Dependencies "true"; | 21:34 |
| hashwagon | Why would my ubuntu server 16.04 system not show a usb drive with lsblk -f, but shows the devices with lsusb? If I unplug it and back in it'll show up, but I can't do that with remote systems. | 22:04 |
| nacc | rbasak: please take a look at my last comment in https://code.launchpad.net/~powersj/ubuntu/+source/logcheck/+git/logcheck/+merge/327810 | 22:13 |
| powersj | nacc: thank you for the reviews! Are you using git ubuntu lint from master? | 22:14 |
| powersj | if so I'll make sure to use it from here on out | 22:15 |
| nacc | powersj: just pushing out another fix for it (that is related to the last review) and yes | 22:15 |
| nacc | powersj: the snap should be refreshing shortly | 22:15 |
| powersj | ok thanks | 22:15 |
| powersj | sweet | 22:15 |
| powersj | hopefully will speed this turn around time | 22:15 |
| powersj | word failure... but yes speed things up | 22:15 |
| nacc | yeah, and i'm hoping to instatiate the review bot soonish too (at least for our team) | 22:15 |
| nacc | which will make this all a bit more automatic | 22:16 |
| powersj | sweet | 22:16 |
| nacc | smoser: sorry if i missed it, but did you have any feedback on the potential change to test_daemon for src:open-iscsi? | 22:27 |
| RoyK | hashwagon: perhaps with a scsi host rescan? usb shows up like scsi devices and I beleive they are treated that way at these layers too https://blogs.it.ox.ac.uk/oxcloud/2013/03/25/rescanning-your-scsi-bus-to-see-new-storage/ | 22:28 |
| nacc | smoser: my current thinking is we should disable that test altogether with the new systemd unit | 22:28 |
| peterrus | I have an install with a root filesystem in lvm, and for some reason every time I boot I get dropped to the recovery shell, then if I run 'mount -a' and then exit my system boots normally | 22:35 |
| peterrus | any pointers on what could go wrong? | 22:35 |
| drab | just a guess, but the uuid of the fs in the initrd/fstab might be wrong | 22:36 |
| drab | so when initrd boots up and wants to load / (which also contains your fstab), it fails | 22:37 |
| drab | if you mount -a (ie mount everything), then / appears | 22:37 |
| peterrus | drab: any way to find out which uuid the initrd is expecting? | 22:37 |
| drab | however thinking aloud, that doesn't quite make sense since fstab would still not be available by the time that mount -a happens | 22:37 |
| drab | but I'd still poke in that direction | 22:37 |
| peterrus | drab: you might be right :p | 22:38 |
| drab | peterrus: blkid | 22:38 |
| drab | that will tell you the uuid of all the disks | 22:38 |
| drab | I'd start byu checking that the output of that matches what's in your fstab | 22:38 |
| drab | and then you may want to run sudo update-initramfs | 22:39 |
| drab | (assuming it matches) | 22:39 |
| drab | and see if that helps at all | 22:39 |
| peterrus | drab: its using /dev/mapper/ubuntu--vg-root | 22:40 |
| drab | oh right, lvm, so not a uuid in fstab | 22:40 |
| drab | peterrus: when you get dropped in the shalel, have you tried any of the lvm commands? | 22:42 |
| drab | to see what's available lvm wise at that point? | 22:42 |
| drab | and also look at some logs | 22:42 |
| drab | also what ubuntu version are you running? I'm seeing some bugs for lvm2 that showed up with the same symptoms you described | 22:45 |
| drab | peterrus: this seems to be relevant: https://askubuntu.com/questions/567730/gave-up-waiting-for-root-device-ubuntu-vg-root-doesnt-exist | 22:48 |
| drab | do you get the same error? | 22:48 |
| peterrus | drab: appearently I had to fsck my /boot/efi partition :p | 22:53 |
| peterrus | its all fixed now | 22:54 |
| peterrus | thanks for pointing me in the right direction though ! | 22:54 |
| peterrus | I have been living like this for a year now :p | 22:54 |
| noft | is microcode firmware for Intel CPUs useful on linux OS ? any advantage/dis. ? | 22:55 |
| sarnold | noft: the microcode updates can fix bugs that otherwise can kill systems dead -- see the hyperthread mentions on https://launchpad.net/ubuntu/+source/intel-microcode/+changelog | 22:57 |
| sarnold | noft: previous microcode updates have disabled known-buggy transactional memory handling extensions that lead to buggy locking primitives | 22:59 |
| === masACC is now known as maswan | ||
| sarnold | noft: normally intel doesn't document _anything_ though. you just don't know what gets fixed and what doesn't get fixed. | 22:59 |
| noft | sarnold: saw a link that you gave me...btw nothing to worry much about, sandy architecture in my case | 23:05 |
| noft | sarnold: it looks like 'must have' for newer cpu, skylake/kaby | 23:06 |
| noft | lot of bugfixing | 23:07 |
| sarnold | noft: the trouble is that you'll never know what it fixes for your CPU except in exceptionally rare circumstances :( | 23:07 |
| noft | sarnold: you there? | 23:29 |
| sarnold | yeah | 23:30 |
| noft | found this | 23:31 |
| noft | You already have proprietary microcode running inside your CPU, this package just provides an update | 23:31 |
| noft | for it. It's not a non-free "driver", as it really has nothing to do with your system at all - it gets | 23:31 |
| noft | loaded by the kernel at boot time, sent to the CPU, updated in the EEPROM block on the CPU and then | 23:31 |
| noft | left alone, never to be used in a meaningful way again | 23:31 |
| noft | microcode updates are usually issued to fix errata in the CPU's | 23:31 |
| noft | design, which can be anything ranging from lockups to crashes to silent data corruption | 23:31 |
| noft | I think it's good idea to get it | 23:32 |
| sarnold | both those descriptions sound fair, except for the 'never to be used in a meaningful way again' -- since it's the software that controls how the CPU is implemented.. | 23:33 |
| noft | oh i get it | 23:34 |
| noft | so for a permanent update I should update BIOS ? | 23:34 |
| sarnold | that'd accomplish about the same thing but runs the risk of giving you motherboard problems (there's always some risk there..) | 23:35 |
| noft | ...well it still depends if manufacturer included updated microcode into bios update | 23:36 |
| noft | correct me if i'm wrong | 23:36 |
| sarnold | right; and they may or they may not. bios people are almost as bad as intel in telling you what they fix :( | 23:37 |
| noft | true | 23:37 |
| noft | btw nvm, it's not like I'm running server on this machine or anything that I care, like science researches etc | 23:38 |
| sarnold | still you want a stable computer :) | 23:39 |
| nacc | rbasak: sigh, libvirt may break our versioning checks :) | 23:41 |
| noft | right but until now I didn't expect anything strange | 23:41 |
| nacc | rbasak: in trusty-security/updates: 1.2.2-0ubuntu13.1.16/1.2.2-0ubuntu13.1.20 | 23:41 |
| noft | as I said, it's nice to see changelogs...from those I saw that newer CPUs are likely to need those the most | 23:42 |
| sarnold | older cpus have probably already had their updates, and might have been simpler machines too :) | 23:44 |
| rbasak | nacc: is there a particular reason libvirt does it that way? I'd rather we be consistent across all packages. Though things like the kernel and HWE packages will always be an exception I expect. | 23:55 |
| nacc | rbasak: no idea :) | 23:55 |
| nacc | rbasak: a good question for smb or cpaelzer | 23:55 |
| rbasak | nacc: and in the meantime, I think it's fine for lint to continue pointing it out to libvirt uploaders :) | 23:55 |
| nacc | rbasak: yep | 23:55 |
| rbasak | nacc: time for gulint overrides? :-P | 23:56 |
| nacc | rbasak: heh | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!