=== cpaelzer_ is now known as cpaelzer [04:40] good morning [06:03] Good morning [06:20] hiho lordievader [06:20] Morning cpaelzer [06:20] How are you doing? [06:21] good, and you? [06:21] Doing good here :) [06:21] glad to hear that [07:40] Hey there. If I manually remove a package with "apt remove some-package" does this prevent it from being installed again automatically in the future? (I now see it listed in dpkg --get-selections with "deinstall") [07:41] I'm trying to recreate a scenario where php7.2 seems to have been, allegedly, automatically upgraded to 7.3RC. [08:20] for some reason one of my machines is in read only filesystem. [08:20] I guess there should be a forcefsck run on reboot [08:20] is there a way to make it reboot and check? [08:22] DenBeiren: differs a bit depending on your version [08:22] latest,.. 18.04.1 [08:23] DenBeiren: you'd need to change kernel parameters to force [08:24] that said, systemd should notice it has failed and run an fsck itself [08:25] DenBeiren: are all partitions mounted ro ? [08:26] DenBeiren: basically these are your options https://www.freedesktop.org/software/systemd/man/systemd-fsck@.service.html [08:37] the problem is that i have no options editing or creating any files [08:37] since i am stuck in read only mode [08:43] DenBeiren: those are kernel commandline options consumed by systemd [08:43] DenBeiren: you can set them from grub or whatever your bootloader is [08:43] disk being readonly isn't preventing you to do that [08:50] i'm afraid i don't understand what i should do,.. never had/did this before :s [08:50] DenBeiren: do you have physical access to the server? [08:50] by physical I mean can you interupt the boot process and get into grub [08:50] no, not now,.. alls is done trough ssh [08:53] DenBeiren: is your /boot partition also mounted ro ? [08:56] https://pastebin.com/biu1d2cM [08:59] https://pastebin.com/yFKNs7sX [09:01] DenBeiren: run "mount |grep sda" [09:02] that should how /boot is currently mounted. if you can mount it rw, you can edit /boot/grub/grub.cfg manually to force fsck next reboot === cpaelzer_ is now known as cpaelzer [09:51] /boot/grub/grub.cfg is empty,... is that ok? [09:51] oops [09:51] i was wrong [09:53] how should i edit grub? where and what? [09:54] DenBeiren: looking at the context of the convo above, it appears you should edit that grub.cfg with any text editor and add fsck.mode=force to the vmlinuz kernel command line [09:56] DenBeiren: in the first "menuentry 'Ubuntu' ....." section, there's "linux" line above "initrd", at the bottom of the { } group. The "linux" line is the kernel command line. [09:56] Add that fsck.mode=force at the end of that line, save the file, umount /boot and reboot [09:57] here goes nothing ;-) [09:58] in beaver we trust :-) [10:11] famous last words, it would seem [10:37] I didn't think you were supposed to edit grub.cfg manually anymore? [10:55] Gargoyle: you aren't. the user couldn't get to root and had the option to mount /boot separately for that one tiem fix and boot regularly. [10:55] (being a remote server with no accses to grub menu itself) [11:45] not last words hateball :-) [11:45] it rebooted but i can't say for sure if it did the check [11:45] my errors aren't gone in any case [11:48] DenBeiren: but did you manage to boot regularly? [11:49] it rebooted and came back up,.. [11:49] i'm not there with the machine to check the monitor [11:49] what errors then? [11:50] for example when i want to edit a file, sudo nano /etc/"tabkey" it gives me the following [11:51] https://pastebin.com/jeSQMWLN [11:53] DenBeiren: pastebin mount | grep tmp please? [11:53] \o/ Xwiki server upgraded from 16.x --> 18.x [11:54] https://pastebin.com/CaEiW5yY [11:55] DenBeiren: and what about just `mount`, no grep? [11:56] https://pastebin.com/Am0f9gLd [11:56] DenBeiren: try mount -o -remount,rw / [11:57] DenBeiren: also please pastebin your /etc/fstab [11:58] Do you have any kind of message in dmesg suggesting why / is being mounted ro? [12:01] https://pastebin.com/CahVM1Bx [12:03] "floppy:" !!! [12:04] ext2 !!! [12:04] How old is this machine? [12:05] Looks like it's a VM too. Do you control the hypervisor? [12:05] DenBeiren: can you pastebin fstab? Looks like something is not remounting root rw after root pivot. [12:06] ext2...wow [12:08] it's not *that* long ago since ext2 was default on /boot if you installed with LVM :p [12:09] Looks like Bionic according to uname [12:10] https://pastebin.com/PqSxrNLL [12:12] DenBeiren: typo on line 7? looks like no root mount in fstab, and that initial ro is never remounted [12:12] is line 7 a copy and paste error? [12:13] DenBeiren: hit enter after on line 7 [12:13] also............ floppy? really? [12:13] dont copy that floppy [12:20] hey, it's standard :-) [12:20] i guess [12:20] what! [12:20] i can't edit the file,.. [12:20] DenBeiren: did you run that remount? [12:21] of course you didn't. you users never read the support advice you ask for. mount -o remount,rw / and then you can edit stuff freely. edit fstab, fix line 7 and reboot for test. you're welcome. [12:22] blackflow: of course i did,.. but the level of knowledge with us n00bs is never as high as you guys might expect ;-) [12:24] you can always ask if something is not clear. that's what support is for ;) [12:25] DenBeiren: Show us the remount command and the output. [12:25] i was able to edit, found the typo and waiting to login after reboot atm [12:25] ah. ok [12:26] yep! seems like that did the trick guys and gals,.. [12:30] thx a lot for the help! [13:12] rbasak: hi, I have an sru question [13:12] I'm working on a fix for a bug, and it has been fixed in bionic+ already [13:12] rbasak: the fix I intend to apply to trusty and xenial is from upstream and is simpler [13:12] rbasak: but different from what is applied to bionic+ [13:13] I think that's fine [13:13] As long as there isn't expected to be a user visible functional regression on upgrade [13:13] rbasak: the bionic one comes from debian, so changing that to the upstream one (better and simpler) adds to delta, [13:13] rbasak: and the debian fix relies on a config change, so backing that out now would mean another config change [13:14] rbasak: so I think leaving bionic alone is best at this time [13:14] That sounds right to me [13:14] Probably good to explain in the SRU description what you just said though. [13:14] agreed [13:27] hey all! trying to figure out how to remove all packages installed from a particular source [13:28] running `grep Package: /var/lib/apt/lists/archive_name_*_Package but it's listing packages that aren't currently installed [13:42] v0lksman: use dpkg-query to get a list of installed packages. Then xargs over "dpkg -s" or similar to look for Source:. grep-dctrl might be useful. If there is no Source: header, the source package name is the same as the binary package name. [13:49] v0lksman: less elegant an possibly showing some false positives but I usually use that: for p in $(dpkg -l | awk '/^ii/ {print $2}'); do apt-cache policy "$p" | grep -qF "ppa.launchpad.net/foo" && echo "$p"; done [13:54] ubuntu 12.......srsly.....he is running 12 [13:54] * Ussat cries [13:56] thanks guys...looking at options. [13:56] Ussat: hope that wasn't directed at me [13:56] no, it was not [13:59] 12.04 is still supported via ESM so there is still a chance was not left there rotting [15:00] cpaelzer: I think I can add dep8 tests to that backuppc package [15:00] rbasak: in terms of an sru, adding a dep8 that doesn't exist in the development release, is that a no-no? [15:00] rbasak: scenario is bionic+ has the fix, but no dep8, and I'm adding the fix *and* a dep8 test for it to trusty and xenial [15:01] it's just the dep8 fix that isn't in the distros I'm not touching [15:04] ahasenack: I think an upload to Cosmic (or Cosmic+1 as needed) to add the dep8 would be appreciated. [15:04] rbasak: sure, but would it block the sru? [15:04] I wouldn't block an SRU just because Cosmic is frozen and therefore you can't add the dep8 righ tnow. [15:04] rbasak: I'm thinking weeks until that could happen [15:04] ok [15:04] that would be my intention, sorry for not making it clear. I would definitely add the dep8 test to c+1 when it opens [15:05] Perhaps you could leave the upload for cosmic+1 ready somewhere and link to it in the bug, and explain that you can't do it now due to freeze? [15:06] sure [15:06] what about the releases in the middle? [15:06] But yeah if you agree to put it in later, it doesn't make sense to me to block the SRU. [15:06] bionic and cosmic itself [15:06] What is it, tough SRU question day today? :) [15:06] I've done an sru in the past which was about fixing an *existing* dep8 test, but not one to add one [15:06] sure :) [15:06] I won't make you do the releases in the middle given that you've said the issue doesn't affect them. [15:07] ok, as I thought :) [15:08] I'll still see how tough adding the dep8 test will be, but from what I've seen just by writing the testing instructions, all that can be scripted easily [15:08] * rbasak tries to be pragmatic about these things; if the underlying reasons for a policy look like a bad trade-off, let's skip the policy :) [15:08] (in a specific case for specific reasons only, of course; otherwise the policy should be questioned/changed first) [15:18] rbasak: i saw your reply, and sarnold's on that bug. It's a bit late in the Cosmic cycle to add that, so it'll get added in Dd-series [15:18] (nginx --with-compat) [15:20] rbasak: we're having some preseed issues with 14.04, install completes fine but apt is left in a funky state due to shim: https://www.irccloud.com/pastebin/2uSLUZYU/ manually upgrading dpkg to 1.17.5ubuntu5.8 over 1.17.5ubuntu5 works... is this something we'll just have to add as a postinstall task or something or is there a better fix? [15:27] sam_w: not sure why you're asking me? [15:27] sam_w: that's interesting though. You do need the newer dpkg from trusty-updates first it seems if you want to install other things from trusty-updates. I'm not sure what mechanism exists (if any) to make sure that dpkg is updated before attempting to install shim. [15:28] sam_w: is the newer dpkg available in the same apt repository? IOW are you using a custom hacked mirror or something, or the official upstream repositories there? [15:28] rbasak: wasn't that a known upgrade-blocker a long time ago in the 14.04 -> 16.04 blocker there? [15:28] i coulda sworn we had some kind of upgrade-blocking evil like that at that cycle [15:28] I don't remember, but it would affect release upgrades too I think. [15:29] rbasak: I think kierank was talking to you about it the other day? Apologies if not! [15:34] sam_w: I remember a conversation about preseeding and hacking an apt repository but not about shim! [15:34] sam_w: conclusion in #ubuntu-devel is that it's a bug. Please could you file one against shim, and tag it "regression-update"? [15:34] rbasak: no hacked mirror, it's just in trusty-updates [15:35] rbasak: sure [15:35] Yeah I'm told it should declare a Pre-Depends, and doesn't, for some complicated reasons due to how it got there. === jelly-home is now known as jelly [18:36] hm, with bileto, do I need one ticket per ubuntu release? [18:36] looks like yes [18:36] even though a ppa can hold packages for multiple releases [18:44] !bileto [18:48] RoyK: https://wiki.ubuntu.com/Bileto [18:48] and bileto.ubuntu.com [19:25] ahasenack, it's the best recommended practice, yes. one ticket per ubuntu release. [19:26] multi-release publish is hard [19:38] I don't use it for publishing, just running dep8 tests in all arches and also the dependent tests [19:38] xnox: it should be easy if a ticket could be marked with all relevant releases