[15:03] <maeud> Hi, can anyone help me with a preseed issue, it fails when trying to install the grub bootloader. Here is the partman section of my preseed file: https://pastebin.com/raw/F265bZgw  - The error is: "Volume group sda not found" then next line "Cannot process volume group sda" - I also have in my preseed: "d-i grub-installer/bootdev string /dev/sda1" but that's ignored if I chroot into /target and run parted, I can see /boot is on /d
[15:04] <maeud> ran out of bug reports to read, nothing to go on
[15:12] <TJ-> maeud: looks wrong to me; you're mixing LVM and raw partitioning
[15:13] <maeud> I thought I needed /boot like that as everything else is encrypted TJ-
[15:14] <TJ-> maeud: that's not what I mean; you've done d-i partman-auto-lvm/... so it assumes an LVM layout but then d-i partman-auto/disk string /dev/sda so it expects an LVM VG 'sda'
[15:15] <TJ-> maeud: if you want LVM it needs to be in one or more of the partitions
[15:16] <maeud> from the docs that's meant to be used in conjunction TJ- ?
[15:17] <maeud> that option sets the disk to use (if more than one) then you set the method to use
[15:22] <TJ-> maeud: but for the /boot/ file-system don't you need $lvmignore{ }  ?
[15:22] <maeud> I'll try it TJ- see if that helps
[15:24] <maeud> ok running through now, see in 5 min or so
[15:24] <TJ-> maeud: also, is this creating MBR or GPT? IF GPT there needs to be a BIOS-boot partition for GRUB's core image
[15:25] <maeud> How would I see that TJ- ?
[15:25] <maeud> it should be MBR, how can I confirm?
[15:25] <maeud> 150GB disk
[15:25] <TJ-> maeud: examine the result when it works/fails :)
[15:26] <cryptodan> go into bios and see if efi is enabled and if it is then likely it will be gpt
[15:26] <TJ-> maeud: as in "sudo blkid /dev/sda" should show PTTYPE=
[15:26] <maeud> yeah it's MBR
[15:26] <maeud> I saw msdos disk before
[15:26] <maeud> in parted
[15:27] <maeud> it's a VM cryptodan, but it's MBR
[15:27] <maeud> gen 1 VM in hyper-v
[15:27] <TJ-> maeud: OK, so grub-install will write the core.image to the spare sectors from #1 to just before the start of partition #1
[15:28] <maeud> OK, it's working through the install, see in a min
[15:33] <maeud> no luck TJ-, it's still giving me the same error: "Volume group "sda" not found"
[15:41] <TJ-> maeud: so you need to capture debug logging, plus examine what has been created on disk, to figure out how it differs from your intention.
[15:44] <TJ-> I presume you're expecting sda1{ext4} sda2{LUKS->LVM}
[15:45] <maeud> pretty much, sda1 /boot, sda5 crypt
[15:45] <TJ-> sda5 implies an extended partition
[15:46] <TJ-> presumably partman creates that by default no matter how many partitions you configure
[15:48] <maeud> TJ-: https://imgur.com/a/yNmeHZl
[15:48] <maeud> does that look right?
[15:54] <TJ-> maeud: not really much use; use "lsblk /dev/sda"
[16:06] <maeud> lsblk doesn't exist in target TJ-
[16:06] <maeud> sorry, it does exist but can't read
[16:06] <maeud> it doesn't exist outside of target but if I copy it from target it doesn't have access to libs, sec
[16:09] <maeud> TJ-:  here's lsblk of /dev/sda: https://i.imgur.com/gvrklAB.png
[16:10] <TJ-> maeud: so the disk layout is correct; therefore there must be something affecting the LVM VG name for it to decide on 'sda'! does "sda" exist anywhere else in the preseed file?
[16:12] <maeud> just "d-i partman-auto/disk string /dev/sda
[16:12] <maeud> "
[16:16] <maeud> If I comment that line out TJ- it prompts for me to select partitioning method, then if I select manual, it says no root file system defined
[16:17] <TJ-> maeud: then there's something else going on your preseed file. If I were you I'd test it in a virtual machine to make investigation/examination easier
[16:18] <maeud> I am testing in a VM
[16:18] <maeud> sec let me post it
[16:21] <maeud> TJ-: https://pastebin.com/raw/6f3Anx4f
[16:21] <maeud> nothing else referencing it
[16:25] <TJ-> maeud: if it's a VM then you chroot mount the install and look at the debian-installer/partman  log files
[16:25] <maeud> I can't complete the install, do you mean in the vt?
[16:27] <maeud>  /var/log/partman
[16:27] <maeud> I'll look there
[16:27] <TJ-> You're using a VM to test, so you can shut down the VM, and chroot-mount the disk-images
[16:31] <TJ-> I've never liked d-i preseeding, especially partman; I prefer scripts I can control
[16:32] <maeud> I'm using preseeding to do the minimal amount as possible as it's a bit of a nightmare
[16:32] <maeud> playbook doing the rest
[16:32] <maeud> just need to get an install up and running
[16:36] <TJ-> I wrote scripts to test a RAID+LUKS+LVM install this week
[16:38] <maeud> so how do I see what's going on here TJ-, I can see the debug logs for partman and syslog, hw
[16:38] <maeud> it's specifically grub install where it fails
[16:38] <maeud> I've pointed it to sda1 which we've confirmed is /boot
[16:39] <TJ-> how do you mean, you've pointed it to sda1 ?
[16:39] <maeud> remember with the bootdev option which seems to be ignored
[16:40] <TJ-> I'd check the d-i log see what command line it is using for grub-install, because it /should/ be "grub-install /dev/sda"
[16:41] <maeud> where about is that one, I chose the menu item for debug logs, it gives me hardware-summary, partman and syslog
[16:43] <Ussat> anyone here run a gitlab server that uses LDAP ?
[16:43] <TJ-> maeud: I'd suspect syslog
[16:44] <maeud> nothing in syslog, that's what I posted before, it literally just gives me those 2 errors about sda vg
[16:45] <TJ-> The joys of d-i !
[16:46] <maeud> that's it
[16:50] <maeud> ok it's in debug mode now
[17:06] <lotuspsychje> place your details here qwebirc16206
[17:06] <qwebirc16206> Hi! I can't install Ubuntu Server 18.04 on my machine.
[17:06] <qwebirc16206> I have 2 HDDs and want t setup RAID1.
[17:07] <qwebirc16206> Here is the error image: https://drive.google.com/file/d/1dfw_TpcUDGbepl4sO5arQ97Tc-SNUrHn/view
[17:08] <qwebirc16206> It says curtin command block-meta
[17:08] <qwebirc16206> and the step is 9/11
[17:10] <Ussat> did you try to install ON the raid or make raid after ?
[17:11] <qwebirc16206> I tried to create RAID during the installation. Manual partitioning, like this:
[17:11] <bipul> qwebirc16206, Just share the steps of installation. And where are you installing it?
[17:14] <qwebirc16206> bipul: nothing special
[17:14] <qwebirc16206> https://drive.google.com/open?id=1kroSfFCI5Su1ODcdzkCncXo_Hj2lD7sV
[17:14] <Ussat> Peronsally, I would raid after...
[17:14] <maeud> TJ-: the install process is using "grub-installer", it takes /target as an argument then throws that error about sda vg unknown
[17:14] <maeud> it's a udeb pkg
[17:15] <qwebirc16206> bipul: standard configuration up to partitioning
[17:15] <qwebirc16206> I have attached an image of what the partitions looked like
[17:16] <TJ-> maeud: so something in the configuration is confusing it into thinking the VG name is the raw disk name - no idea!
[17:17] <qwebirc16206> tomreyn: here is the info: Ubuntu-Server 18.04.1.0 LTS "Bionic Beaver" - Release amd64 (20180725.1+apt)
[17:17] <qwebirc16206> Ussat: what? how?
[17:17] <tomreyn> qwebirc16206: ok. based on your screenshot, the installer seems to be trying to create a RAID-0 array, not RAID-1. are you sure you configured RAID-1?
[17:19] <maeud> and grub-installer is a 1.3k line bash script
[17:19] <maeud> awesome
[17:19] <qwebirc16206> tomreyn: yes, I have configured RAID1
[17:19] <qwebirc16206> see this: https://drive.google.com/file/d/1kroSfFCI5Su1ODcdzkCncXo_Hj2lD7sV/view
[17:19] <qwebirc16206> where did you find RAID0?
[17:20] <qwebirc16206> Oh, indeed, I see it...
[17:20] <Ussat> qwebirc16206, https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-18-04
[17:21] <tomreyn> qwebirc16206: this mentioned "raid-0", but maybe that's just the name of the curtin module: https://lh6.googleusercontent.com/6xRkZPJHz1IUEV4TZ8KLyK43BHrTFGSxRgkVdlkfrXUAxSV8bHKLXTHjgJRn0E90b4GPpyLYad5Qbw=w1720-h1242
[17:21] <Ussat> To be fair, I dont raid much most of my servers are SAN connected to an isilon
[17:21] <tomreyn> or maybe it's yet another curtion / subiquity bug.
[17:22] <tomreyn> qwebirc16206: use the alternative (classic, debian) installer
[17:22] <qwebirc16206> I haven't seen that option...
[17:22] <qwebirc16206> There is this installation, OEM installation and check disk.
[17:23] <qwebirc16206> Is it this OEM installation that you meant?
[17:23] <tomreyn> qwebirc16206: no, i'm referring to a different ISO download
[17:23] <tomreyn> qwebirc16206: see "alterantive downloads" at https://www.ubuntu.com/download/server
[17:25] <tomreyn> qwebirc16206: can you confirm that this system boots in UEFI mode?
[17:26] <TJ-> So much easier with scripts and deboostrap! :)
[17:27] <tomreyn> i'm actually considering to write a new installer in bash
[17:27] <tomreyn> maybe someone did this already.
[17:29] <qwebirc16206> yes, it boots in UEFI
[17:29] <qwebirc16206> there is also a /boot/efi partition
[17:31] <tomreyn> i noticed. i'm just thinking about reproducing it. i was hoping the latest build of the default server installer would fix most issues, but i guess many remain unfixed.
[17:33] <kinghat> is this odd that it shows i have 1 security update when i log in and when i search for updates it says up2date? https://paste.debian.net/hidden/d99e2318/
[17:34] <TJ-> kinghat: no, the motd may not have been updated yet
[17:35] <tomreyn> right, there's some 'caching' involved
[17:35] <kinghat> oh. its been a few days iirc.
[17:36] <TJ-> update-motd I think
[17:37] <kinghat> as an extra package? will it work itself out?
[17:37] <TJ-> kinghat: there's a tool you can execute "update-motd" that runs all the scripts that add their bits to the MOTD
[17:38] <TJ-> kinghat: scripts are dropped in /etc/update-motd.d/ and those are run and their output gathered by update-motd
[17:38] <kinghat> hmm this is odd: https://paste.debian.net/hidden/e994c8c2/
[17:39] <TJ-> kinghat: it could be due to the specific script, from update-notifier-common,  /usr/lib/update-notifier/update-motd-updates-available
[17:39] <kinghat> i had messed with grub when i had to take over the machine to get my user back into the sudo group/sudoers file.
[17:41] <TJ-> kinghat: oh, that looks like something caused by curtin/containers stuff, check if there's files in /etc/default/grub.d/
[17:42] <kinghat> kinghat@kinghat-server:/etc/default/grub.d$ ls -ln
[17:42] <kinghat> total 4
[17:42] <kinghat> -rw-r--r-- 1 0 0 140 Aug 21 20:42 50-curtin-settings.cfg
[17:42] <tomreyn> menu.lst? sounds like grub1 (AKA 0.98) when it should be grub2
[17:44] <kinghat> i cant remember what i did to grub because it wasnt formatting correctly on the screen or something like that when i was trying to get into recovery. then i just used a live cd to get sudo to change the sudoers file.
[17:45] <kinghat> maybe i did that grub-boot-repair thing. its been a month or more.
[17:45] <tomreyn> pastebinit <( cat /etc/os-release; echo; dpkg -l | grep grub)
[17:46] <tomreyn> i see. maybe the above output is irrelevant then
[17:46] <kinghat> https://paste.ubuntu.com/p/9mmJ5S5JSs/
[17:46] <tomreyn> just install grub2 to the boot disk
[17:47] <tomreyn> is this an AWS system?
[17:47] <kinghat> nah just ubuntu server on a thumb drive in the house.
[17:48] <tomreyn> i'm not sure what grub-legacy-ec2 actually does but i guess i would just remove it then
[17:48] <tomreyn> also purge the bios variant of grub2 if you use efi
[17:49] <TJ-> There's a postinst script that runs and generates that /etc/default/grub.d/50-curtin-settings.cfg which causes some GRUB v1 crud to be done; I seem to recall it is due to some weirdness on AWS or some other 'cloud'
[17:49] <tomreyn> i.e. sudo apt purge grub-pc grub-legacy-ec2
[17:49] <TJ-> I can't find the bug now but I was dealing with that issue some time ago
[17:49] <tomreyn> and then sudo grub-install /dev/whereever
[17:49] <tomreyn> ok TJ-
[17:50] <kinghat> i dont know for sure if its efi or not. its an old HP workstation board that has a bunch of stuff turned off to be able to run outside of an HP chassis and a PSU converter etc.
[17:50] <tomreyn> i remember that Xen PV systems always had trouble booting with grub2
[17:52] <tomreyn> IIRC there's some environment variable which can tell you how the system booted (UEFI vs BIOS), but i forgot the details and cant find it now
[17:52] <TJ-> hmmm, maybe it was something else, maybe to do with /etc/cloud/cloud.cfg.d/
[17:53] <kinghat> ill look tomreyn
[17:53] <tomreyn> if you have a /sys/firmware/efi directory then you have uefi
[17:53] <TJ-> tomreyn: I generally check sysfs /sys/firmware/efi/
[17:53] <tomreyn> :) thanks
[17:54] <TJ-> tomreyn: right, but it may not have booted with legacy mode, I seem to recall, there's a subtlety to it - checking the efivars I think
[17:54] <tomreyn> actually i made this up about the environment variable.
[17:54] <TJ-> oops, lose the "not" from that last line
[17:54] <kinghat> kinghat@kinghat-server:/sys/firmware/efi$ ls
[17:54] <kinghat> config_table  efivars  fw_platform_size  fw_vendor  runtime  runtime-map  systab  vars
[17:55] <tomreyn> kinghat: so thats a system which booted in uefi mode
[17:55] <kinghat> got ya. so do i need to check `efivars` or just that i have `efivars`?
[17:56] <tomreyn> unless TJ-'s subtlety applies, which i'm not aware of
[17:57] <tomreyn> kinghat: given that sysfs is present / mounted, if you have a directory /sys/firmware/efi then you booted in uefi mode.
[17:58] <tomreyn> i assume this is what you were asking?
[18:00] <kinghat> tomreyn: yes basically.
[18:01] <kinghat> so still run the purges and sudo grub-install?
[18:03] <tomreyn> kinghat: personally, in a situation where "i cant remember what i did to grub [..] maybe i did that grub-boot-repair thing", i would, yes.
[18:04] <TJ-> tomreyn: it would be really useful to have a /proc/sys/kernel/bootloader_method
[18:04] <kinghat> is there a default dir grub installs to or i should put it in dev/?
[18:05] <kinghat> https://paste.debian.net/hidden/10785d0e/
[18:06] <tomreyn> TJ-: yes, indeed.
[18:06]  * TJ- considers a patch and what Linus' reaction would be :)
[18:06] <tomreyn> ROOOOAR!
[18:07] <kinghat> lel
[18:08] <tomreyn> kinghat: looks fine to me, if it does to you?
[18:08] <tomreyn> kinghat: you run grub.install against a storage, not a directory.
[18:08] <kinghat> what does the 2 not fully installed or removed means?
[18:09] <TJ-> have you ever tried to grep for 'efi' or 'EFI' in kernel where #define and  #DEFINE are everywhere!?
[18:09] <tomreyn> kinghat: that you have 2 packages which are neither in state 'ii' not in state 'un'
[18:10] <tomreyn> dpkg -l | grep -Ev '^(un|ii)'
[18:11] <kinghat> https://paste.debian.net/hidden/d7ec8494/
[18:12] <kinghat> here is the dpkg grep: https://paste.debian.net/hidden/2ad5d621/
[18:12] <tomreyn> just "touch /boot/grub/menu.lst" and run it again, looks like the post removal script is buggy
[18:13] <kinghat> touch needs permission?
[18:14] <tomreyn> depends on what it wants to touch
[18:14] <tomreyn> for touching /boot/grub/menu.lst it'll need sudo
[18:14] <tomreyn> also make sure /boot is actaully mounted
[18:15] <kinghat> https://usercontent.irccloud-cdn.com/file/1SP5V3OX/image.png
[18:15] <tomreyn> why grub2? thats new
[18:16] <tomreyn> but i guess you can just agree and then reinstall anything thats missing
[18:17] <kinghat> ummmm lol
[18:18] <kinghat> so this is effectively starting fresh with grub?
[18:18] <kinghat> i havent clicked yes yet.
[18:22] <TJ-> tomreyn: looks like we can rely on the sysfs node: https://paste.ubuntu.com/p/5qYCCWm2C5/
[18:24] <kinghat> should everything grub related on my system be removed and then added back?
[18:38] <kinghat> tomreyn: https://paste.debian.net/hidden/08e4e972/
[18:42] <tomreyn> TJ-: thanks for looking this up
[18:46] <tomreyn> kinghat: such a nicely broken package. maybe just purge "dpkg --purge" grub-pc and grub-legacy-ec2. or purge all of grub , then reinstall grub-efi-amd64 grub-common
[18:47] <tomreyn> * grub2-common
[18:48] <kinghat> tomreyn: `dpkg --purge grub*` ?
[18:54] <tomreyn> kinghat: i think dpkg only handles one package at a time, but not sure
[18:54] <tomreyn> other than that, yes
[18:54] <kinghat> youre correct. try with apt purge?
[18:57] <teward> anyone know if it's possible to boot an ISO stored within an LVM partition into RAM at grub launch time?
[18:57] <tomreyn> kinghat: apt purge didnt seem to work, so i suggested dpkg --purge
[18:57] <teward> asking because I need to weekly Clonezilla this system to a backup disk and i need some GRUB guidance :|
[18:57] <teward> (they give me an ISO)
[19:01] <tomreyn> teward: there's "grub-imageboot" ("boot iso, harddisk and floppy images with grub2 and syslinux memdisk") and "grml-rescueboot" ("Integrates Grml ISO booting into GRUB"). i had mixes results with those on an uefi booting system (have not tried legacy bios). i think the grml ones worked with some iso's but not others.
[19:01] <tomreyn> generally grub can boot from an iso
[19:02] <tomreyn> (but maybe not all of them, not sure)
[19:02] <teward> tomreyn: right, but the tricky part is, the documentation I found doesn't anticipate the ISO being inside an LVM LV
[19:02] <teward> it anticipates it being on a physical partition somewhere
[19:02] <teward> ... which... I don't actually have at the moment.
[19:02] <teward> since this system is full-disk LVM.
[19:02] <teward> since this system is full-disk LVM except for 512MB at the start for a boot partition.
[19:02] <tomreyn> oh, yes, you said LVM, sorry, no idea then
[19:02] <teward> yeah that's where I'm getting stuck :|
[19:02] <teward> I mean TO BE FAIR
[19:02] <teward> I could probably replicate this in an LV
[19:02] <tomreyn> shrink the PV, i guess
[19:03] <teward> tomreyn: last time I did that I torched the partition table LOL
[19:03] <teward> I'll do that after I take a Full Disk Image later :P
[19:03] <teward> and i'll just USB boot for that ;P
[19:03] <teward> ... remind me how to shrink a PV again xD
[19:03] <teward> shrink a PV safely*
[19:03] <tomreyn> i wouldnt dare doing it live either
[19:04] <tomreyn> and i'd need to look up how to do it, too
[19:04] <tomreyn> i did it before, and it worked, that's all i rmeember
[19:05] <teward> i only need like 300MB so eh
[19:05] <teward> i'mma backup my system with a full disk image first though
[19:05] <teward> that way if I fubar it i can restore it
[19:05] <teward> again
[19:05] <teward> it shouldn't be hard to shrink the LVs.  I'll have to recreate the swap LV though
[19:05] <teward> but that won't be a problem.
[19:06] <tomreyn> IIRC when you shrink the PV (after shrinking the LVs) you have to provide the target size explicitly, which is silly, it doesn'T have anything like ext4's "minimal size" option where it shrinks to the smallest possible size automatically
[19:08] <tomreyn> so it's a bit of try and error: you guess the new size, then have lvm resize the PV, then it either prints a warning saying the ewuivalent of "this looks to small but it did it anyways" or the equivalent of "all fine".
[19:08] <kinghat> tomreyn: i ran it again anyways and got this: https://paste.debian.net/hidden/e6779eea/
[19:08] <tomreyn> in the former case you re-reun it with a slightly larger size
[19:08] <tomreyn> ...until oyu get rid f the warning
[19:09] <tomreyn> kinghat: yeay, this actually worked
[19:09] <kinghat> it didnt remove `grub.d` though.
[19:09] <tomreyn> whats left in /etc/grub.d ?
[19:10] <kinghat> kinghat@kinghat-server:/etc/grub.d$ ls -ln
[19:10] <kinghat> total 4
[19:10] <kinghat> -rwxr-xr-x 1 0 0 424 Dec 10 02:00 25_custom
[19:11] <tomreyn> kinghat: and that contains?
[19:12] <tomreyn> i have 40_custom and 41_custom on this bionic
[19:13] <kinghat> tomreyn: https://paste.debian.net/hidden/73c80033/
[19:13] <tomreyn> kinghat: did you or some other admin of this system create this file?
[19:14] <kinghat> im the only one. not that i remember.
[19:14] <tomreyn> kinghat: and do those files actually exist on /boot/efi/EFI/ubuntu/ ?
[19:16] <tomreyn> ...or in /boot/efi/EFI/BOOT
[19:16] <kinghat> yes. among others
[19:17] <tomreyn> and blkid reports that your ESP'S UUID is 84C3-4FDF ?
[19:17] <kinghat> https://paste.debian.net/hidden/adb4e53c/
[19:18] <tomreyn> blkid | grep 'PARTLABEL="efi"'
[19:18] <tomreyn> sdc1 is UUID 84C3-4FDF
[19:18] <tomreyn> and is potentially your ESP
[19:19] <tomreyn> so i guess you can keep it, or remove it, whatever you like
[19:19] <tomreyn> it shouldnt do any harm
[19:19] <tomreyn> just adds 3 extra entries on your grub menu
[19:20] <kinghat> wont grub install just make a new one?
[19:20] <tomreyn> a new what?
[19:21] <kinghat> `grub.d`
[19:21] <tomreyn> not if it's already there, otherwise it'll add to what's already there
[19:21] <tomreyn> i mean: not if it's already there, it'll add to what's already there
[19:22] <kinghat> but if its not there it will just start fresh?
[19:22] <teward> tomreyn: the alternative is I shrink the LV's down considerably to make sure there's enough space and leftover extents to not deal with anything
[19:22] <teward> but then shrink the PV from there, but that's... tricky.
[19:23] <tomreyn> teward: i don't think i'm getting the alternatives you're dioscussing. one is to shrink LVs, then the PV, the other is...?
[19:24] <teward> tomreyn: > you guess the new size, then have lvm resize the PV, then it either prints a warning saying the ewuivalent of "this looks to small but it did it anyways" or the equivalent of "all fine".
[19:24] <teward> ^ avoid this by ultrashrinking :P
[19:25] <kinghat> there is actually a bunch of stuff still in `/boot`: https://paste.debian.net/hidden/f3ab06d3/
[19:25] <teward> shrink the LV way smaller than it needs to be but meh
[19:25] <teward> tomreyn: i'mma do a Full Disk Backup now then attempt to NOT explode the system heh
[19:32] <tomreyn> teward: if you have unpartitioned space on the VG which is backed by exactly one PV then you can just pvresize with the trial-and-error approach. if you have a VG backed by multiple PVs youmay have to pvmove (to move VG data (extents) off one of the PVs) first, so you can remove this PV.
[19:32] <tomreyn> and i dont think you need to do it 'way smaller', no
[19:33] <kinghat> im not sure if its ready to be 'regrubbed' or not but shouldnt `grub-pc` add everything back like the efi stuffs or does that have to be installed manually as well?
[19:34] <tomreyn> kinghat: if those /boot/grub* are there while all the grub* packages are purged, then you should proibably purge those untracked files.
[19:34] <tomreyn> "dpkg -S /path/to/directoryorfile" to check whether its part of a package
[19:34] <teward> tomreyn: i ALMOST deleted the wrong thing lol
[19:34] <teward> switched the lvremove options xD
[19:34] <tomreyn> teward: whoops
[19:34] <teward> that could've been bad xD
[19:35] <tomreyn> i think you real yjust want to test whether you bare metal recovery procedure works
[19:36] <teward> considering i've already restored this twice before... :P
[19:36] <kinghat> kinghat@kinghat-server:/etc/grub.d$ dpkg -S /boot/grub
[19:36] <kinghat> dpkg-query: no path found matching pattern /boot/grub
[19:36] <tomreyn> kinghat: congratulations for testing it.
[19:36] <kinghat> remove those as well?
[19:38] <tomreyn> kinghat: i run an ubuntu 18.04 desktop which does uefi booting and don't have /boot/grub
[19:38] <tomreyn> so i guess you dont need it. after all its not part of any package you have installed. so, yes, i guess it can go.
[19:39] <kinghat> ill get rid of the `grub.bak` dir as well
[19:39] <tomreyn> it would help if you knew what you did to your system :)
[19:39] <tomreyn> i assuem this is a result of running "boot repair"
[19:40] <kinghat> ya. then i manually went in via livecd sudo and fixed the sudoers file
[19:40] <kinghat> should have just done that from the start
[19:40] <kinghat> but i thought there was a problem with grub.
[19:40] <kinghat> there wasnt.
[19:40] <kinghat> i made a problem though. :P
[19:41] <teward> tomreyn: another stupid quesiton, but is there a way to map known partitions to what their GRUB root= equivalents are :|
[19:41] <teward> or do I have to drop to the grub cli to do that
[19:42] <tomreyn> teward: the UUIDs? those are printed by blkid
[19:43] <tomreyn> teward: is this what you meant?
[19:44] <teward> tomreyn: close enough
[19:44] <teward> i'll read the grub manpage
[19:44] <teward> i have to full disk image this first
[19:44] <kinghat> tomreyn: https://paste.debian.net/hidden/f250554c/
[19:44] <teward> back in a bit.
[19:46] <kinghat> not sure about the `/efi/ubuntu/` `grub.cfg` and `grubx64.efi` files
[19:48] <tomreyn> kinghat: grub-install should replace them when you run it.
[19:48] <kinghat> ok. can i remove the `grub.d` dir or just the `25_custom` file in it?
[19:49] <tomreyn>  /boot/efi/ubuntu/grubx64.efi is stage1 of grub, grub.cfg points it to where stage2 is located
[19:50] <tomreyn> kinghat: if you still dont have any grub packages installed, you can just remove all of /etc/grub.d/
[19:51] <kinghat> ok its gone.
[19:51] <kinghat> so `grub-install` or `grub-pc`?
[19:51] <tomreyn> be sure to install grub2 and grub2-common and to run update-grub and grub-install soon, though, or you wont be able to boot.
[19:52] <tomreyn> those are apples and oranges: grub-install is a command, grub-pc is a package name.
[19:53] <tomreyn> sorry, it's not "grub2 and grub2-common" but "grub-efi-amd64 and grub2-common"
[19:53] <kinghat> i mean do i need to have grub before i can `grub-install`?
[19:53] <tomreyn> although this may actually both work
[19:54] <tomreyn> kinghat: yes, you wont have the grub-install command before you installed the package which provides it.
[19:54] <tomreyn> so install it
[19:56] <kinghat> doesnt one of the grub packages already bring in `grub-efi-amd64`?
[19:58] <tomreyn> if you install "grub2" or "grub" this may depend on / install grub-efi-amd64, i have not checked
[19:58] <kinghat> regardless: https://paste.debian.net/hidden/a5456c62/
[19:58] <tomreyn> what matters is that you'll have grub-efi-amd64 and grub-efi-amd64-bin and grub2-common in the end
[19:59] <tomreyn> i dont see any errors on the output, do you have any questions?
[19:59] <kinghat> so now `update-grub` and then `grub-install`?
[20:00] <tomreyn> corret
[20:00] <tomreyn> correct
[20:00] <tomreyn> "grub-install" takes one argument, the destination device.
[20:00] <kinghat> ok i dont want to mess that one up.
[20:01] <tomreyn> i usually install to multiple devices, just in case one breaks.
[20:01] <kinghat> so `grub-install /dev/sdc` via the blkid output here: https://paste.debian.net/hidden/adb4e53c/
[20:02] <tomreyn> ignore what i just said, this doesn'T apply to uefi (unless you have multiple ESPs)
[20:03] <tomreyn> yes, "grub-install /dev/sdc" is probably correct.
[20:03] <tomreyn> i'm a bit puzzled why this is not sda, though
[20:03] <kinghat> i did `grub-probe -t device /boot/grub` and it says /dev/sdc2 but i only need the sdc?
[20:04] <kinghat> me too lol
[20:04] <tomreyn> you seem to have zfs on sda and sdb, i'm not into this
[20:04] <kinghat> i dont know how that happened tbh.
[20:04] <tomreyn> there's a lot of rather relevant things you should try to be more in the know of. ;-)
[20:05] <tomreyn> kinghat: it's good to know or be able to tell, by yourself, how the boot process works, in case it breaks
[20:06] <kinghat> https://paste.debian.net/hidden/d27c8455/
[20:07] <kinghat> do i need to `grub-update` again?
[20:09] <kinghat> i havent restarted but i logged out of the session and back in and im not seeing any updates like before. so
[20:09] <tomreyn> kinghat: no. check the files and modification dates in /boot/efi/EFI/ubuntu/
[20:10] <tomreyn> i'd expect that at least grubx64.efi has a current file modification time
[20:10] <tomreyn> maybe grub.cfg also
[20:10] <kinghat> https://paste.debian.net/hidden/d972f2cb/
[20:10] <kinghat> just `grubx64.efi`
[20:13] <tomreyn> ok. that's fine. we already looked at grub.cfg and it pointed at the correct ESP
[20:13] <kinghat> scared to reboot
[20:13] <tomreyn> you shouild be able to reboot fine.
[20:14] <kinghat> here goes
[20:14] <tomreyn> if it doesn't work immediately, see if you can pick this grubx64.efi on your uefi configuration interface
[20:14] <kinghat> you mean from the bios?
[20:14] <tomreyn> yes
[20:14] <kinghat> im remote atm.
[20:15] <tomreyn> oh, good luck then
[20:15] <tomreyn> i'd rather wait unil i'd be back on site
[20:15] <tomreyn> unless i had out of band management
[20:15] <tomreyn> or remote hands
[20:15] <kinghat> physical access is... all the way downstairs..
[20:16] <tomreyn> that sounds acceptable, if you're not in a 64 floor skyscraper without a lift.
[20:16] <kinghat> lol
[20:16] <kinghat> `reboot` initiated!
[20:20] <kinghat> im in!
[20:20] <kinghat> yay!
[20:20] <kinghat> tyvm tomreyn!
[20:20] <tomreyn> :)
[20:20] <maeud> just can't get past this stupid grub issue at all
=== crimastergogo_ is now known as crimastergogo
[21:48] <teward> tomreyn: well... that didn't go well.  Managed to restore, but I had to do some... not cool tactics.
[21:48] <teward> Ultimately just GUI booted to a Live Desktop USB with a patched gparted and did the LVM resize
[21:48] <teward> which apparently WORKS when the right patch is applied
[21:49] <teward> i'll have to bug the Desktop team at some point to fix this.
[22:12] <maeud> re-did the whole process and it starts the grub install, screen goes black and it loops trying to restart the screen
[22:12] <maeud> can't win
[22:12] <maeud> lol
[22:45] <Checkmate> is there any tools to block bots ?
[22:45] <Checkmate> on website
[23:19] <CodeMouse92> Checkmate: fail2ban works pretty well, as far as blocking malicious bots and other attacks
[23:20] <CodeMouse92> In terms of valid search engine bots, robots.txt is how you control what they crawl.
[23:29] <Intelo> is it possible to buy ip from somewere and use that ip in your vps provider (and not the ip of vps host it self)? You own the ip and can attach it to anywhere?
[23:31] <mybalzitch> you'd need an ASN, and for your VPS provider to allow you to announce your ASN within their network. Not impossible but usually costly
[23:32] <mybalzitch> and I'm not sure they (ARIN) would sell you a /24 (255 IP's) let alone a single ip
[23:34] <Intelo> where to get ip ?
[23:35] <maeud> type "buy ip space" into Google
[23:36] <Intelo> k