[00:43] <matthewjp2> it says to get java but it gives me this error matplayzmcpe@matplayzmcpe-desktop:~$ sudo apt-get install sun-java6-jdk
[00:43] <matthewjp2> Reading package lists... Done
[00:43] <matthewjp2> Building dependency tree
[00:43] <matthewjp2> Reading state information... Done
[00:43] <matthewjp2> Package sun-java6-jdk is not available, but is referred to by another package.
[00:43] <matthewjp2> This may mean that the package is missing, has been obsoleted, or
[00:43] <matthewjp2> is only available from another source
[00:43] <matthewjp2> However the following packages replace it:
[00:43] <matthewjp2>   apt
[00:43] <matthewjp2> E: Package 'sun-java6-jdk' has no installation candidate
[00:43] <matthewjp2> matplayzmcpe@matplayzmcpe-desktop:~$
[01:09] <matthewjp2> hi
[07:57] <lordievader> Good morning.
[08:57] <z4sk4> hi all
[08:57] <lordievader> o/
[10:36] <bumbar_> i'm trying to install cpp-ethereum, which depends on alethzero, which depends on libqt5webengine5, which depends on qtdeclrative-abi-5-4-1, but: The following packages have unmet dependencies: libqt5webengine5 : Depends: qtdeclarative-abi-5-4-1 but it is not installable
[15:18] <OerHeks> Hi, is this feature indeed in 16.04? unity-panel can be placed at the bottom? http://linux.softpedia.com/blog/ubuntu-16-04-lts-to-let-users-move-the-unity-launcher-at-the-bottom-of-the-screen-498000.shtml
[15:30] <k1l> OerHeks: no
[15:30] <k1l> that article is not really based on facts
[15:31] <k1l> https://code.launchpad.net/~feng-kylin/unity/unityshell-rotated-kylin/+merge/281182   that is the patch. its still pending and "need review"
[15:34] <OerHeks> k1l, thank you, i wondered as i didn't hear about it.
[15:39] <k1l> and i bet there will be some shitstorm again why 16.04 did not include that patch when that linux news site said it will
[15:53]  * genii covers his ears in horror and glares at k1l
[17:26] <JediMaster> hi guys, I've managed to somewhat break an upgrade from 14.04 to xenial, it doesn't appear to be able to read the lvm root to boot, I get the following: http://pastebin.com/VCGVjxH0
[17:27] <JediMaster> it's also a remote machine, just to make things more interesting =)
[17:28] <JediMaster> luckily I can remote boot the xenial iso, I have tried the rescue procedures, it managed to mount the root partition and I ran grub-install on it, then dropped to the chrooted shell, and ran update-grub
[17:28] <JediMaster> but still get the above error
[17:47] <JediMaster> ok, I'm booted back into Linux 3.13.0 kernel, anything I can do to fix the 4.3.0 kernel?
[17:48] <lotuspsychje> JediMaster: its not very recommended to upgrade from trusty to xenial
[17:48] <lotuspsychje> JediMaster: clean install instead?
[17:48] <JediMaster> nah, can't be bothered with a full reinstall at the moment, I will when it's released but not yet
[17:49] <lotuspsychje> JediMaster: things can still break in this stage
[17:50] <JediMaster> lotuspsychje, I'm aware =)
[17:50] <JediMaster> it looks like it's just the 4.3 kernel causing problems at the moment
[17:51] <JediMaster> just done a apt-get --reinstall on the 4.3 image and it's updated grub, going to try a reboot
[17:54] <JediMaster> tbh PHP 7 is the main reason for the upgrade, I know I could compile it myself, but nice to have automatic security updates when it goes live
[17:56] <JediMaster> hmm, same error with linux 4.3.0-5-generic
[18:07] <JediMaster> what could be different between the ubuntu linux 3.13.0 and 4.3.0 packages that would stop the LVM root from being detected?
[18:08] <JediMaster> both the linux-image and linux-image-extra packages for both are installed, and probably less relevant, the headers too
[18:09] <JediMaster> all are -generic too
[18:11] <JediMaster> grub commands are the same too: linux   /vmlinuz-4.3.0-5-generic root=/dev/mapper/backup--vg-root ro  pci=noacpi splash quiet $vt_handoff
[18:11] <JediMaster> and: linux   /vmlinuz-3.13.0-74-generic root=/dev/mapper/backup--vg-root ro  pci=noacpi splash quiet $vt_handoff
[18:15] <JediMaster> other grub config appears to be the same for both kernel images
[18:15] <JediMaster> maybe the initrd image doesn't contain the required drivers
[18:17] <JediMaster> the initrd.img for 4.3 is 50% larger than the 3.13 one (31M vs 20M)
[18:25] <lordievader> JediMaster: Can you mount the root fs in the busybox?
[18:26] <JediMaster> lordievader, I can just go to grub and select linux 3.13 instead and it boots fine, but I'd rather get the latest 4.13 working
[18:26] <lordievader> JediMaster: That was not my question ;)
[18:26] <JediMaster> lordievader, but to answer your question, no, /dev/mapper doesn't show it
[18:26] <JediMaster> give me a chance =)
[18:27] <lordievader> JediMaster: Do you have lvm command available in the initrd?
[18:27] <JediMaster> I've actually just extracted both initrd images to compare them, there's tonnes of differences in available modules =/
[18:28] <JediMaster> lordievader, I could reboot and try but it'll take 3-4 minutes as it's a server, I guess I could check the image
[18:28] <lordievader> Sure, quite different kernel versions.
[18:28] <lordievader> JediMaster: This chat is on another machine?
[18:28] <JediMaster> yeah, the machine is remote in a datacentre
[18:28] <lordievader> Ok, good ;)
[18:28] <JediMaster> I've got remote KVM
[18:40] <JediMaster> lordievader, yes /sbin/lvm is in the initrd image
[18:40] <lordievader> Okay, what is the output of 'lvm vgs'?
[18:41] <JediMaster> ok, I'm booted into 3.13 at the moment, I'll run it there, then reboot and pastebin both
[18:41] <JediMaster> anything else to check before I reboot?
[18:41] <lordievader> lvm lvs
[18:42] <lordievader> I think it shows unactivated lv's.
[18:43] <JediMaster>  if only I could copy/paste from the KVM
[18:43] <JediMaster> I had to use OCR to do the pastebin earlier =)
[18:43] <lordievader> If you use 'virsh console' you can ;)
[18:43] <JediMaster> too lazy to type it all out heh
[18:45] <JediMaster> just looking that up seems to have a lot of kvm related links, just to be clear I meant Dell's iDRAC when I meant remote KVM
[18:46] <JediMaster> *said
[18:47] <JediMaster> lvm vgs complains: /run/lvm/lvmetad.socket: connect failed: No such file or directory
[18:47] <JediMaster> bah, mkdir /run/lvm then re-running it didn't work heh
[18:49] <JediMaster> I'm guessing not all the required mount points are mounted within busybox
[18:53] <JediMaster> lordievader, any idea if busy box has a text editor?
[18:55] <JediMaster> really, there's wget installed in initrd image but not vi
[19:00] <JediMaster> is there a way of forcing linux to drop to the initrd image rather than a normal boot?
[19:00] <JediMaster> so I can check the running modules in the working initrd
[19:00] <lordievader> Ah, the other kvm.
[19:00] <JediMaster> lordievader, yeah =)
[19:01] <lordievader> And you are looking for 'break=<something>'
[19:01] <lordievader> lvm2 is still installed after the upgrade?
[19:01] <JediMaster> I'll reboot and check
[19:03] <JediMaster> the upgrade was pretty broken due to a change in rkhunter's config, I ended up having to apt-get dist-upgrade, autoremove etc.
[19:03] <lordievader> Perhaps it got removed, that would explain these troubles ;)
[19:03] <JediMaster> even though it boots into the old kernel?
[19:04] <JediMaster> it's booting, I saw it starting lvm2, so I guess it's there
[19:04] <JediMaster> yeah, lvm2 2.02.133-1ubuntu2
[19:06] <lordievader> The lvm2 package adds some modules to the initrd, if the initrd of the 4.x kernel got made after it got removed those modules are missing.
[19:06] <lordievader> The old kernel doesn't have that problem if the initrd is not rebuild.
[19:08] <JediMaster> I did: apt-get --reinstall install linux-image-4.3.0-5-generic
[19:08] <JediMaster> doesn't that rebuilt initrd on install?
[19:08] <JediMaster> *rebuild
[19:10] <lordievader> Yes, the 4.3 kernel. Is that the old kernel?
[19:10] <JediMaster> I wonder if there are kernel modules that have been renamed or replaced between 3.13 and 4.3 which maybe haven't been correctly copied into the initrd
[19:11] <JediMaster> no, 3.13 is the old trusty kernel, 4.3 is the new one
[19:11] <lordievader> Yeah that is what I mean ;) But if lvm2 is still installed my theory is invalid.
[19:11] <JediMaster> yeah, it is
[19:13] <JediMaster> well I've got a working machine on 3.13, but if I reboot it'd break, I'm not sure removing linux-generic is a wise idea
[19:13] <lordievader> That is a meta-package.
[19:14] <lordievader> But do keep it installed ;)
[19:17] <lordievader> Odd though that it fails on lvmetad, it should just fall back or the regular scanning...
[19:17] <lordievader> I suppose 'lvm pvs' gave the same error?
[19:18] <JediMaster> didn't try it, shall I reboot, or anything to try from the working kernel first?
[19:20] <lordievader> Rebuild an initrd... though I don't think it will help.
[19:20] <JediMaster> I --reinstalled lvm2, it's run update-initramfs as part of the install, I'll try again
[19:21] <JediMaster> oddly, only for 4.3.0-5
[19:21] <JediMaster> not for the existing kernel that's booted
[19:25] <JediMaster> lordievader, same error, also same error with lvm pvs
[19:26] <lordievader> Systemd ain't available yet in a Ubuntu initrd, is it?
[19:26] <JediMaster> can't see it there
[19:26] <JediMaster> btw, thanks for the help lordievader
[19:26] <lordievader> Lets see what I have in my initrd.
[19:27] <JediMaster> I still don't understand wget being in it
[19:28] <TJ-> JediMaster: I very much suspect that system has hit by some regressions in the PCI bus assigment logic since v3.13 kernel.
[19:28] <TJ-> JediMaster: looking at your original pastebin showing PCI failures leads me to that conclusion, which possibly means the disk controller isn't being initialised
[19:28] <JediMaster> TJ-, I do have a bunch of PCI errors in there
[19:29] <JediMaster> that might explain it, it's a Dell PowerEdge R415
[19:30] <lordievader> I get the same error but my lv's do show up.
[19:30] <JediMaster> lordievader, TJ-'s theory would cover that
[19:31] <JediMaster> TJ-, do you think it's a kernel bug, or a missing driver?
[19:33] <TJ-> JediMaster: there have been some bad regression since v3.18 that still aren't fixed in mainline as yet... 17 months and counting so far. The fact the fragment of dmesg output is showing device init failures makes me suspect that one or more devices are unable to allocate all their resources into parent bridge windows correctly.
[19:33] <JediMaster> I wonder what kernel the daily iso installer uses as it picked up the lvm correctly
[19:34] <TJ-> JediMaster: on the next 4.x reboot, when it fails to the busybox initrd shell, do "dmesg | grep BAR " for an initial indication of if that is the case. If you have sufficient remote control, pull the entire 'dmesg' output to a local log-file and paste it
[19:35] <JediMaster> TJ-, damn, can't put a pipe symbol in the kvm =/
[19:35] <JediMaster> ah ascii codes with alt and num pad are working =D
[19:36] <TJ-> JediMaster: if it works from the same kernel on an ISO then PCI bus windows is less likely; in which case I'd check that /etc/initramfs-tools/initramfs.conf has "MODULES=most"
[19:37] <JediMaster> rofl, what are the odds, I nearly guessed the ascii code, I put 123 in and it's 124 =D
[19:37] <TJ-> 1 in 256 ? :p
[19:37] <JediMaster> TJ-, there's many many pages of output
[19:37] <JediMaster> yeah, but still =)
[19:37] <TJ-> JediMaster: yes, it's the entire kernel log, and very useful in these situations
[19:38] <JediMaster> getting that from a graphical remote console will be tricky
[19:38] <TJ-> you've got errors for USB, IDE, network, and MPT devices. Suggests a major low-level cause
[19:38] <JediMaster> if I pipe it to the filesystem, will that write to the initrd.img file?
[19:39] <TJ-> No
[19:39] <JediMaster> bah
[19:39] <JediMaster> worth a try
[19:39] <TJ-> At this stage there's likely no accessible devices, but you could check and mount one file-system read/write if there is one, to save the log permanently
[19:39] <JediMaster> hmm, I wonder if USB is working, I may be able to mount another drive
[19:40] <TJ-> anything in "ls -la /dev/block/" that's useful?
[19:40] <JediMaster> nope, all loop and ram
[19:41] <JediMaster> I guess not then
[19:41] <TJ-> not even the device with GRUB's file-system, and /boot/ on it?
[19:41] <JediMaster> not in there, no
[19:41] <JediMaster> no, /boot isn't mounted either
[19:41] <TJ-> if /boot/grub/ is in the VG-LV backup-vg/root ... then that tends to confirm the disk controller isn't accessibly
[19:42] <TJ-> because GRUB's lvm module has obviously accessed it
[19:42] <JediMaster> IIRC /boot isn't an LVM partition
[19:42] <TJ-> anything with "find /lib/modules -type f -name '*.ko' ?
[19:42] <JediMaster> so I think grub is accessing the PCI correctly but the 4.3.0 kernel isn't
[19:43] <TJ-> GRUB uses UEFI/BIOS services to read the disk, unless you switch it to 'native' mode
[19:43] <TJ-> Once the kernel starts it has to do that with its own drivers
[19:43] <JediMaster> ah right, and yes, tonnes of modules
[19:43] <JediMaster> it's still listing them
[19:44] <JediMaster> I happen to have the output of /proc/modules from the 3.13.0 kernel, anything I should look for?
[19:44] <TJ-> JediMaster: OK, so not missing modules... this points back to my original gut feeling... failure to correctly map the PCI devices. Are you able to edit the kernel's command-line via the GRUB menu at boot time?
[19:44] <JediMaster> yes
[19:44] <TJ-> JediMaster: differences between that and the failing /proc/modules
[19:44] <JediMaster> there's tonnes more from the working kernel, but that's not from initrd
[19:46] <TJ-> JediMaster: OK, next time you boot to this failing kernel add "pci=realloc,assign-busses" as a test. That tells the PCI setup code 2 things: 1) adjust PCI bridge windows to fit downstream devices, regardless of what the BIOS/ACPI config states and 2) ignore the BIOS bridge/device config entirely and redo it
[19:46] <JediMaster> I'll do that now
[19:47] <TJ-> If that solves/improves it, that is more evidence towards the PCI bridge window issues. It may not completely fix all issues though.
[19:48] <JediMaster> TJ-, I've currently got pci=noacpi at the moment, it's been years since I set up this machine, but I think it was failing to halt correctly at the time, could this be part of the problem?
[19:49] <JediMaster> ohh ohh... new errors
[19:50] <JediMaster> but it's booting
[19:50] <JediMaster> yeah, removing the pci=noacpi has sorted it
[19:50] <TJ-> oh... that would DEFINIATELY have been causing problems!
[19:51] <TJ-> Didn't know you had that. That stops the BIOS/UEFI from informing the PCI sub-system of the optimum device mappings
[19:51] <JediMaster> haha, ok my bad then
[19:51] <TJ-> it'll probably work fine without that, and without my suggestions
[19:52] <TJ-> no pci=XXXX or noacpi or whatever
[19:52] <JediMaster> lordievader, it was pci=noacpi causing the problems
[19:52] <JediMaster> yeah, I removed it from the grub edit line and it booted fine, I'll update the config
[19:53] <TJ-> It is a very old rare system that will benefit from pci=noacpi or 'noacpi'
[19:54] <TJ-> that's a sledgehammer to crack a very samm nut. There are subtle sub-system controls for those to affect just the bit that has an issue, rather than disabling the entire thing
[19:57] <JediMaster> yeah, I couldn't find any other fix at the time for the machine not powering down on halt
[19:57] <JediMaster> at least I can remotely power the machine on with the iDRAC
[19:58] <TJ-> that can often be solved by using the most recent acpi_osi=XXXX value the ACPI DSDT of the system supports
[19:59] <JediMaster> completely forgot that I'd changed the default kernel arguments, it's been many years
[20:00] <JediMaster> hmm, black screen now =/
[20:00] <JediMaster> the machine is up, but the console is dead
[20:00] <JediMaster> weird, ctrl-alt-f1 and it's back
[20:01] <JediMaster> all looks fine now, will try a halt and see if it powers down
[20:02] <JediMaster> nope, it doesn't power down after "system halted" never mind, I can do that via the iDRAC
[20:06] <JediMaster> TJ-, lordievader thanks very much for both of your help, all looking good now
[20:06] <TJ-> JediMaster: see if you can fix that power-off issue with acpi_osi
[20:06] <JediMaster> any idea where I find the DSDT code for the system?
[20:07] <JediMaster> I've had a quick google and couldn't find it
[20:07] <JediMaster> lol I only did the dist-upgrade a few hours ago and there's a new kernel already =D
[20:07] <TJ-> JediMaster: "sudo strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows' " and identify the most recent Windows version it reports, something like "Windows 2012" ... then add to /etc/default/grub's "GRUB_CMDLINE_LINUX="... \"acpi_osi=Windows XXXXX\" " (where XXXXX is the 2012 or whatever you identified)
[20:07] <JediMaster> er do-release-upgrade even
[20:08] <TJ-> JediMaster: then "update-grub" so /boot/grub/grub.cfg is updated, and try a reboot
[20:08] <JediMaster> I'll try that now
[20:08] <TJ-> make sure to *escape* the double-quotes in that string \" not "
[20:09] <TJ-> since the entire string is surrounded by " too
[20:09] <JediMaster> oh yuck
[20:09] <JediMaster> http://pastebin.com/zRdcPayn
[20:10] <JediMaster> I guess the newest must be 2006.1
[20:11] <TJ-> Yes. the fact there's 2006 and 2006.1 suggests the BIOS ACPI will do something slightly different for the point release.
[20:13] <TJ-> what happens is, the ACPI DSDT contains bytecode of methods that the kernel's ACPI core executes. The DSDT code contains code that alters what methods and services it offers based on the OSI string passed by the OS.
[20:14] <TJ-> The default is usually some very basic minimum (because its rare the BIOS ACPI OSI matches on "Linux" and if it does, it usually explicitly sets the 'miminum' support level
[20:14] <TJ-> By having Linux tell the ACPI OSI that it is "Windows 2006.1" you should cause the maximum range of services to be enabled
[20:14] <TJ-> ACPI is used to control reboot/power so it makes sense that is the cause of the failure to shutdown correctly.
[20:15] <JediMaster> I wonder why the kernel doesn't scan it to see what's the highest level available automatically?
[20:16] <TJ-> Because it's not the way its done; those strings aren't guaranteed to be the OSI strings, but I've found this to consistently work
[20:17] <TJ-> You can actually completely disassemble the DSDT to source-code using the 'iasl' tool, and as I used to work on that side of the kernel, it taught me this workaround through investigating many broken DSDTs
[20:19] <JediMaster> a sort of non standardised standard?
[20:20] <JediMaster> I'm afraid that didn't work, still powered on after "reboot: System halted"
[20:20] <JediMaster> it's not a big problem really, only when I need to take the machine out of the rack, which is only once every few years tbh
[20:21] <JediMaster> Thanks again for the help, much appreciated
[20:23] <JediMaster> slightly worryingly grub isn't coming up with the menu, it stays black for a while
[20:23] <JediMaster> after POST it goes black until I ctrl-alt-f2
[20:28] <TJ-> that sounds like a GPU mode issue. if it's a server disable GFX mode with GRUB's "GRUB_TERMINAL=console"
[20:29] <TJ-> no need for a bitmapped graphical framebuffer and splash screen for a server
[20:29] <JediMaster> odd, it wasn't doing it earlier
[20:30] <TJ-> could be the newer kernel doing more modesetting for that GPU, that the Trusty kernel doesn't do?
[20:31] <JediMaster> yeah, I did just upgrade to another kernel too
[20:31] <JediMaster> mind you, the kernel is loaded at that point, it's grub doing that
[20:32] <JediMaster> GRUB_TERMINAL=console did the trick
[20:33] <JediMaster> yeah now I see the Ubuntu 16.04 loading screen (at least the server console version with the 4 dots)
[20:37] <TJ-> I disable plymouth splash entirely. Lose the "splash". Can't remove it anymore it is too invasive, though
[20:37] <JediMaster> yeah I don't like it personally, is that just the splash kernel line option?
[20:38] <JediMaster> I guess I'd better remove quiet too
[20:40] <TJ-> yes. I prefer having 'debug' on there since I like to see everything that the kernel reports
[20:43] <JediMaster> it took 3 years for me to realise I could skip the Dell memory tests by hitting escape, useful on a server with 512GB of RAM, used to take 10 minutes to test it in POST
[20:44] <JediMaster> ok that's all looking a lot better now
[20:47] <JediMaster> ok, I had better head off, thanks TJ- & lordievader