| lunaphyte | TJ-: i had to give up on making a bootable recovery flash drive for now | 01:57 |
|---|---|---|
| lunaphyte | i was just hitting too many roadblocks, and for some reason the install process was painfully slow, so each time i'd try again with a different method, it was costing me a ton of time | 01:58 |
| TJ- | lunaphyte: you've not had any luck! | 01:58 |
| lunaphyte | i'm keeping the complaints to myself - but i am beyond irritated :) | 01:59 |
| lunaphyte | right now i've just booted to a rescue shell, using the traditional server installer, and have a crude environment functioning, if you've got any interest in where things last left off | 02:00 |
| lunaphyte | i think you had suggested including some logging to validate the driver that might still be missing for the usb keyboard? | 02:04 |
| lunaphyte | just reading back through the channel logs | 02:04 |
| lunaphyte | at least now with this installer, and nomodeset, i have a functional remote console | 02:06 |
| lunaphyte | ah, right. "add a verbose script that displays the loaded modules and hardware and waits so you get time to photograph its output" | 02:07 |
| lunaphyte | let me see what i can find on doing that | 02:08 |
| lunaphyte | this is what's logged to dmesg when plugging in the keyboard: http://dpaste.com/1WNK0F7.txt | 02:21 |
| lunaphyte | i see usbhid.ko and hid-generic.ko. if i am understanding the dmesg info right, it may be using hid-generic? | 02:23 |
| lunaphyte | according to lsinitramfs, the initrd has usbhid.ko, but not hid-generic.ko. i'll try adding that | 02:24 |
| lunaphyte | time to cross my fingers | 02:26 |
| lunaphyte | omfg | 02:33 |
| lunaphyte | it's working | 02:33 |
| lunaphyte | and now it's booting | 02:34 |
| lunaphyte | or at least trying to | 02:34 |
| lunaphyte | TJ-: success! | 02:36 |
| lunaphyte | i have some issues to sort out, but it boots :) | 02:36 |
| lunaphyte | at initramfs, i had to activate the volume groups. it seems that the initrd didn't do so? | 02:37 |
| TJ- | lunaphyte: OK, so you've solved the keyboard issue! Time to party :D | 02:37 |
| lunaphyte | huge progress, yes - thanks to you :D | 02:38 |
| lunaphyte | lots of questions to come back to, but for now the next thing i need to figure out is why i have to active the volume groups manually, instead of the initrd doing it | 02:39 |
| lunaphyte | is lvm a kernel module, like the usb/hid stuff? | 02:40 |
| === yokel_ is now known as yokel | ||
| === SJrX is now known as SJr | ||
| TJ- | lunaphyte: lvm hooks should be installing the lvm tools in the initrd, AND the scripts should run "vgchange -ay" automatically | 03:15 |
| lunaphyte | hmm, ok | 03:20 |
| === lotuspsychje__ is now known as lotuspsychje | ||
| ahasenack | good morning | 10:19 |
| maeud | Hi, is anyone familiar with gnome and kerberos? I'm trying to mount shares using pam_mount and krb5i. It works fine for SSH logins but using the desktop environment it fails with error: "mount error(126): Required key not available" | 10:57 |
| maeud | but if I open a terminal in the desktop environment and run klist, I have a ticket | 10:58 |
| maeud | got it working, I had to add "user=%(USER),cruid=%(USER),uid=%(USERUID),gid=%(USERGID)" to the pam_mount volume option for each share | 11:08 |
| === TheHonorableKitt is now known as THKitten | ||
| theGoat | i just spun up an ubuntu 18.04 vm, and i have the IP and DNS configured in netplan (50-clout-init), but the system keeps setting the dns server to 127.0.0.53 | 14:44 |
| sdeziel | theGoat: that's the default way | 14:54 |
| sdeziel | theGoat: 127.0.0.53 is systemd-resolved and it's the one who received the real nameservers | 14:54 |
| theGoat | ok, just wanted to make sure.. things have really changed ;-) | 14:55 |
| sdeziel | theGoat: you can confirm with "systemd-resolve --status" | 14:55 |
| sdeziel | theGoat: yeah, indeed. Introducing a local caching resolver by default is slightly disruptive | 14:55 |
| sdeziel | I for one welcome the change, even if I'm not a huge fan of resolved... I'm sure it will get better over time | 14:56 |
| theGoat | i'l just need work with 18.04 more, to get use to all the changes | 14:58 |
| lunaphyte | during a do-release-upgrade, this sort of thing happens from time to time: http://dpaste.com/0ZQNT29.txt | 15:40 |
| lunaphyte | what's the correct way to proceed in a scenario like this? | 15:41 |
| TJ- | lunaphyte: what were the starting and target release versions? | 15:46 |
| lunaphyte | 16.04 -> 18.04 | 15:47 |
| phaidros | ehlo, hown can I disable a network device in a netplan yaml config? | 16:06 |
| tomreyn | lunaphyte: with 3rd party packages / repos? which? | 16:06 |
| tomreyn | all of those are in "main" if they'Re the original packages | 16:10 |
| cyphermox | phaidros: just remove the configuration from the file | 16:13 |
| lunaphyte | tomreyn: i do have a couple of third party repos, but they're just for some other software like vnc, prosody, etc. | 16:15 |
| lunaphyte | all of the standard stuff is all from the distribution repos | 16:16 |
| lunaphyte | i'm just wanting to know what the right way to proceed is with this | 16:16 |
| lunaphyte | it's like a half installed upgrade | 16:16 |
| phaidros | cyphermox: hm, not very deterministic, but works .. thanks :) | 16:16 |
| lunaphyte | lsb_release now says 18.04, but it hasn't done cleanup yet, hasn't done the reboot yet, etc | 16:17 |
| lunaphyte | and it's also said "The upgrade has aborted. Your system could be in an unusable state. A | 16:17 |
| lunaphyte | recovery will run now (dpkg --configure -a)" | 16:17 |
| shubjero | lol | 16:17 |
| lunaphyte | so what does that mean? what state is it in now? should i be trying to do do-release-upgrade again? should i just be doing like an apt-get install for the packages that failed and work my way through to get them installed successfully one at a time? | 16:18 |
| phaidros | lunaphyte: I would run: dpkg --configure -a and then another apt update/dist-upgrade (provided that sources.list(s) are set to bionic yet) | 16:22 |
| tomreyn | same | 16:22 |
| tomreyn | running do-release-upgrade again is *not* what you want to do in this situation since it would then try to initate an upgrade to next release. | 16:24 |
| cyphermox | phaidros: it's meant to be that way -- no config, interface isn't touched | 16:27 |
| cyphermox | phaidros: if OTOH you mean you want to keep a config, but say "hey, I want this one to be kept offline until I say so"; then that will be a feature in the future, but not yet | 16:28 |
| lunaphyte | phaidros: just to double check, you said i should expect sources.list to not be set to bionic? | 16:29 |
| sarnold | lunaphyte: I think I'd do what phaidros recommends, perhaps an apt-get install -f as well | 16:29 |
| lunaphyte | sarnold: makes sense, thanks. just wanted to be sure i'm understand right about the sources.list | 16:32 |
| sarnold | lunaphyte: you may be right that you would need to fix it up by hand.. | 16:33 |
| tomreyn | lunaphyte: ensure that apt sources point to bionic, then apt-get install -f; apt-get upgrade; apt-get full-upgrade; apt-get autoremove # maybe with --purge | 16:33 |
| tomreyn | /usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeFetcherCore.py contains the code run by do-release-upgrade if you'd like to take a closer look at what it missed. | 16:34 |
| lunaphyte | ok, great, thanks | 16:35 |
| rbasak | kstenerud: https://dep-team.pages.debian.net/deps/dep8/ is the canonical location of the dep8 spec | 16:36 |
| tomreyn | lunaphyte: http://archive.ubuntu.com/ubuntu/dists/bionic-updates/main/dist-upgrader-all/current/bionic.tar.gz is the actual upgrader | 16:39 |
| tomreyn | lunaphyte: have a look at demoted.cf.xenial, you want to remove these packages if installed. | 16:42 |
| lunaphyte | demoted.cf.xenial is inside bionic.tar.gz? | 16:43 |
| tomreyn | yes | 16:44 |
| lunaphyte | ok, thanks | 16:44 |
| Lope | A guy on another channel claims that luks'ing a hard drive directly, without any partition table, will misalign data with respect to the hard drive's 4k block size. Is that true? | 16:46 |
| tomreyn | lunaphyte: and maybe use https://github.com/tomreyn/scripts#foreign_packages (or the other utilities mentioned there) to identify other packages you should remove (should only be relevant if you had ppas installed and removed them but not packages installed from there) | 16:46 |
| lunaphyte | tomreyn: i use deborphan heavily - thanks, i didn't know about the others | 16:49 |
| sarnold | Lope: that feels pretty plausible to me but can't confirm or deny it | 16:54 |
| Lope | sarnold, ok | 16:57 |
| tomreyn | --align-payload=SECTORS Align payload at <n> sector boundaries - for luksFormat | 16:58 |
| sarnold | tomreyn: awesome! :) | 16:58 |
| tomreyn | i guess you set this to 4 then | 16:59 |
| tomreyn | Lope: ^ | 16:59 |
| TJ- | tomreyn: surely 8 ? | 17:00 |
| tomreyn | err, right | 17:00 |
| tomreyn | thanks | 17:00 |
| Lope | tomreyn, wow, cool, but unfortunately I've already formatted it. | 17:02 |
| Lope | tomreyn, how will luks normally align data? | 17:02 |
| tomreyn | Lope: probably in 512 byte blocks, but i'm only guessing | 17:03 |
| TJ- | Yes, it specifically uses 512-byte sectors as its base measurement | 17:03 |
| Lope | tomreyn, check this out: https://unix.stackexchange.com/questions/421587/dmsetup-luksformat-creating-an-alignment-inconsistency | 17:03 |
| TJ- | " --align-payload <number of 512 byte sectors> " | 17:04 |
| Lope | I've googled the issue and seen that it can be a false warning, especially when using a USB enclosure, (as I am doing) | 17:04 |
| Lope | It's a 500G mechanical HDD in a USB enclosure) | 17:04 |
| TJ- | Lope: that is possible if the USB<>SATA bridge chip is faking it | 17:04 |
| Lope | device mapper says: device-mapper: table: 253:0: adding target device sda caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=2097152 | 17:04 |
| TJ- | Lope: is it presenting as 4096/4096 (logical/physical) | 17:04 |
| TJ- | Lope: OK, so 512/4096 - that's probably passing through the drives native translation | 17:05 |
| Lope | Since 4096/512 ^ 4 = 0, perhaps I should not worry? | 17:05 |
| Lope | Oops | 17:06 |
| Lope | I meant to say: Since 4096 % 512 == 0, perhaps I should not worry? | 17:06 |
| TJ- | Lope: check with (set X appropriately): "sudo hdparm -I /dev/sdX | grep 'Sector size' " | 17:06 |
| Lope | brb | 17:06 |
| TJ- | Lope: The best arrangement is to align with the device's underlying physical block size, since that is the minimum bytes the drive can read/write. Alignment means that it can avoid having to read/write 2 blocks (16 x 512-bytes) if they straddle the alignment border and then discard some of them. | 17:09 |
| tomreyn | if you have 4k physical / imposed (by some translation) sector size then you want 4k everywhere or you'll introduce unneccessary overhead. | 17:09 |
| Lope | tomreyn, fair enough. Can I change ext4 to be 4k block size? | 17:12 |
| Lope | okay, the block size of my ext4 is already 4k | 17:13 |
| Lope | So it's all good. | 17:13 |
| Lope | Also, I'm using the disk to store big files, so it wouldn't be an issue anyway, even if there was a 512/4096 mismatch. | 17:14 |
| sarnold | misalignment is terrible enough that the only use case that could tolerate it "I never use this filesystem" | 17:15 |
| tomreyn | there's -I and -E stride=stride-size | 17:16 |
| tomreyn | (to tune2fs) | 17:16 |
| Lope | sarnold, I've realized that the USB HDD enclosure probably imposes a 4k block size. I've checked my filesystems have 4k block sizes. So I'm not going to worry. I only use the fs for storing big files anyway. | 17:17 |
| Lope | thanks tomreyn | 17:18 |
| tomreyn | yw | 17:20 |
| TJ- | sarnold: try saying that for shingled drives! | 17:24 |
| sarnold | TJ-: "the only use case that could tolerate shingled drives is 'I never use this filesystem'" :) | 17:25 |
| TJ- | :D | 17:25 |
| tomreyn | is rasdaemon the right tooling to detect ecc ram errors? | 17:30 |
| tomreyn | with 18.04, that is | 17:30 |
| sarnold | tomreyn: I believe so, yes | 17:32 |
| tomreyn | i have this issue with "No dimm labels for" (my (Desktop-like) mainboard): http://paste.ubuntu.com/p/nYzJcjNrmV/ | 17:34 |
| tomreyn | this is ecc ram, i'd like to make use of it, and the platform (ryzen 7 1800X) can do it, at least for detecting 1-bit errors | 17:36 |
| sarnold | tomreyn: interesting, I'd never noticed that in my logs before; both my laptop and supermicro server have the same message (though only the supermicro has ecc) | 17:36 |
| tomreyn | detect + correct that is | 17:36 |
| tomreyn | i *think* it means that detection wont actually happen, unless the hardware handles it fully | 17:37 |
| sarnold | it was my assumption that the hardware would handle it but also write the event to a log that rasdaemon can read. hmm. | 17:37 |
| tomreyn | s/hardware/firmware/ | 17:37 |
| tomreyn | yes, thats how it should be, and that's what you'd expect for server hardware | 17:38 |
| tomreyn | now... this is not not server hardware, i'd need the OS / user space to help it out there to powerdown on 2-bit errors | 17:38 |
| tomreyn | i.e. the ryzen platform doesn't come with firmware which handles 2-bit errors. | 17:41 |
| tomreyn | http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/75030-ecc-memory-amds-ryzen-deep-dive.html | 17:41 |
| sarnold | tomreyn: once in a while I'm reminded just how little I understand... :) | 17:46 |
| tomreyn | :) same issue here | 17:47 |
| shubjero | Hey all, I'm using Ubuntu cloud images on Openstack in kvm and I've noticed that with 14.04 and 16.04 that I can deploy very large instances (5+TB disk) and they work but if they are rebooted they are dumped at the grub rescue and unable to boot. I do NOT have this issue with the 18.04 cloud image. Any guesses? | 18:09 |
| lunaphyte | i'm looking at demoted.cfg.xenial in http://archive.ubuntu.com/ubuntu/dists/bionic-updates/main/dist-upgrader-all/current/bionic.tar.gz - what does demoted mean? | 20:33 |
| lunaphyte | i see things like makedev, and ntp listed, which seems a little bit odd | 20:33 |
| lunaphyte | https://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=makedev&searchon=names seems to indicate that makedev is part of 18.04? | 20:34 |
| sdeziel | lunaphyte: ntp was replaced by chrony if you really want a ntp daemon, otherwise the default is now to use systemd-timesyncd as ntp client | 20:34 |
| teward | sdeziel: i think they're asking more about what the demoted part mean | 20:34 |
| teward | and IIRC that' means no longer in 'main' | 20:34 |
| teward | but i'm not the expert there :p | 20:34 |
| sdeziel | chrony is in main now ;) | 20:35 |
| teward | sdeziel: i know *that* but I meant in response to "what does demoted mean?" which was asked by lunaphyte | 20:35 |
| teward | who was asking about ntp, makedev, etc. | 20:35 |
| teward | :P | 20:35 |
| sdeziel | teward: ah, OK | 20:35 |
| lunaphyte | sdeziel: using the ntp example - replaced in what way, exactly? | 20:36 |
| lunaphyte | both ntp and chrony are present and valid packages in the repo, right? | 20:37 |
| sdeziel | lunaphyte: what teward says seems to make sense. I took a quick look at that demoted.cfg.xenial file and it seems to list packages that were in main before but are now in universe | 20:37 |
| lunaphyte | oh, ok | 20:38 |
| sdeziel | lunaphyte: yes, present and valid but main vs universe refers to the support of those packages | 20:38 |
| sdeziel | lunaphyte: packages in main are supported by Canonical, those in universe by the community | 20:38 |
| sdeziel | of course, the community can also provide support for packages in main | 20:38 |
| lunaphyte | so would that then seem to imply that if makedev isn't in main any longer, your typical system shouldn't need it? | 20:39 |
| sdeziel | lunaphyte: that's a correct interpretation | 20:39 |
| lunaphyte | ok | 20:39 |
| lunaphyte | thanks | 20:39 |
| sdeziel | lunaphyte: a default/stock install/image only have packages coming from main, it's a policy at Canonical I think | 20:40 |
| lunaphyte | makes sense | 20:41 |
| tomreyn | now the really interesting question there is: does the upgrader uninstall those packages if it finds them installed. | 20:43 |
| tomreyn | i previously claimed it does, but haven'T actually checked that | 20:43 |
| tomreyn | does anyone know this OTOH? | 20:45 |
| sdeziel | tomreyn: in the past I found that I needed to cleanup after the upgrader. At least my Puppet manifest takes care of purging ntpdate-debian from boxes that went from 14.04 to 16.04 | 20:45 |
| tomreyn | i've also had such situations, but during the 16.04 -> 18.04 desktop upgrade i went through the upgrader did actually purge ntp for me. | 20:46 |
| tomreyn | ...i think | 20:46 |
| tomreyn | (so that's package "ntp", not "ntpdate*" | 20:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!