[00:33] <benl90> thanks rbasak nacc . Leaving now
[04:43] <cpaelzer> good morning
[06:01] <lordievader> Good morning
[07:57] <tobias-urdin> coreycb: did something change in the tempest packages? we dont get the neutron tempest plugin anymore
[07:57] <tobias-urdin> http://logs.openstack.org/22/583222/14/check/puppet-openstack-integration-5-scenario004-tempest-ubuntu-bionic-mimic/cc35e59/job-output.txt.gz#_2018-08-14_23_31_33_113245
[12:20] <ahasenack> good morning
[13:12] <rbasak> ahasenack: both of your samba uploads got trumped by security :-/
[13:13] <ahasenack> oh
[13:13] <rbasak> ahasenack: if you can rebase and reupload soon, I'll try and review immediately? I would review now but I'm a bit thrown by the tooling parenting it wrong, so the diff looks bad. I could work around to review what you uploaded, but possibly not worth it.
[13:13] <rbasak> (well, technically the tooling is parenting it correctly, which is why I noticed :)
[13:14] <ahasenack> I'll rebase it, but where is the package now? Not in proposed yet, right?
[13:14] <ahasenack> it's in limbo?
[13:15] <rbasak> It's in unapproved
[13:15] <rbasak> I can reject. Might as well do it now I guess.
[13:15] <ahasenack> can you reject it?
[13:15] <rbasak> ack
[13:15] <rbasak> Done
[13:43] <ahasenack> rbasak: I rebased xenial-samba-include-1583324 and pushed/forced, can you do a quick check if that's what you expect in terms of tags and branches?
[13:48] <ahasenack> rbasak: same for trusty-samba-include-1583324
[13:50] <rbasak> Looking
[13:52] <ahasenack> funny, debian rebooted gitlab
[13:52] <ahasenack> and the cached login was lost
[13:53] <ahasenack> must be in memory, or in /tmp
[13:57] <rbasak> ahasenack: the diff against the tip of those branches and what's in the archive looks OK. That's what I review for SRU purposes.
[13:57] <ahasenack> rbasak: ok, I need sponsoring then I'm afraid :)
[13:57] <ahasenack> (can't upload samba yet)
[13:58] <rbasak> I'm not supposed to sponsor and also SRU review
[13:58] <ahasenack> even if the same diff was sponsored before?
[13:58] <rbasak> That'd be OK, but then I need to confirm it was the same diff
[13:58] <rbasak> Let's see
[13:59] <ahasenack> cpaelzer: do you know what's missing here https://bileto.ubuntu.com/#/ticket/3355 for me to select "lander signoff"? It's gray and unclickable by me. What did I forget?
[13:59] <ahasenack> or is it because I can't upload krb5?
[14:00] <cpaelzer> ahasenack: taking a look
[14:00] <cpaelzer> maybe, it seems I can set it
[14:00] <cpaelzer> should I try to?
[14:00] <ahasenack> :/
[14:00] <ahasenack> yes please
[14:00] <cpaelzer> to see what happens
[14:01] <cpaelzer> yeah worked
[14:01] <cpaelzer> if that really is the ACL I'm not sure
[14:01] <ahasenack> sad
[14:01] <cpaelzer> but you are working on more upload permissions anyway, so we will see if that opens up more
[14:01] <ahasenack> it should block the publish button, not this step
[14:02] <cpaelzer> we might ask sil if that even is what is blocking it
[14:02] <cpaelzer> not around atm thou
[14:04] <CheckmateX> Hi can anyone guide me to edit fail2ban to block users who multiple POST's on a php page ?
[14:06] <cpaelzer> CheckmateX: like https://yaleman.org/2014/12/16/using-fail2ban-to-mitigate-apache-post-flooding/ maybe?
[14:08] <CheckmateX> cpaelzer i have a php search page and some bad people avail the page to POST multiple request this exhausts everything i'm not sure if the Recaptcha service will block them or what i need to do
[14:08] <rbasak> ahasenack: verified the diff is the same for both
[14:08] <rbasak> I'll sponsor
[14:08] <ahasenack> rbasak: thanks
[14:09] <cpaelzer> rbasak: is that for the smb security release killing the SRUs
[14:09] <cpaelzer> ?
[14:09] <ahasenack> yep
[14:09] <smb> cpaelzer, I did what?
[14:10] <cpaelzer> hehe
[14:10] <CheckmateX> cpaelzer you think the guide you give me gonna work ?
[14:10] <cpaelzer> you got released by security
[14:10] <cpaelzer> CheckmateX: I don't know, it just pretty much matched your search terms
[14:10] <smb> cpaelzer, wished I would let go... :)
[14:11] <rbasak> smb: aren't you deprecated now? I heard you were insecure or something? :)
[14:11] <CheckmateX> cpaelzer you know when i check the logs i found the same ip was maked many search POST's per minute
[14:11] <cpaelzer> smb: you started it :-P
[14:12]  * rbasak is amused by having typed "git branch -r|grep aha"
[14:12] <smb> rbasak, certainly outdated and an (hr) hazard .. ;)
[14:13] <cpaelzer> rharper: aha
[14:14] <CheckmateX> cpaelzer i can custome the php page right ?
[14:14] <CheckmateX> on fail2ban
[14:40] <Emmanuel_Chanel> Hello! The installer of ubuntu-18.04-server-amd64.iso get down at 12% of the Software Selection and Installation section. So I quited to install 18.04 server directly.
[14:41] <tomreyn> Emmanuel_Chanel: how do you mean "goes down"? what's the hardware, which non default choices did you make during installation?
[14:42] <tomreyn> and what does "install directly" mean?
[14:42] <tomreyn> did you verify the iso downloaded properly and is unmodified?
[14:43] <Emmanuel_Chanel> The "software selection and installation" get down and is restarted. / Directly means that I tried to install Ubuntu Server 18.04 from the DVD of that ISO.
[14:43] <Emmanuel_Chanel> ok. I verify now.
[14:48] <Emmanuel_Chanel> tomreyn: Where can I get the checksums?
[14:49] <tomreyn> Emmanuel_Chanel: nex tto where you downloaded the iso from
[14:50] <Emmanuel_Chanel> Now I cannot find the site of ubuntu-18.04.1-server-amd64.iso ...
[14:50] <ahasenack> rbasak: do you remember the history behind this squid delta we have been carrying? https://pastebin.ubuntu.com/p/fythxdS5Pc/
[14:50] <tomreyn> Emmanuel_Chanel: cdimage.ubuntu.com/releases/18.04.1/release/
[14:50] <ahasenack> rbasak: there is the squid-deb-proxy package, with more modern and complete refresh patterns for deb repositories
[14:50] <ahasenack> rbasak: I wonder how much I should improve this delta we have, or just drop it entirely in favor of the squid-deb-proxy package
[14:51] <ahasenack> rbasak: squid-deb-proxy has this relevant config, more complete: https://pastebin.ubuntu.com/p/nDrczbfmCY/
[14:51] <ahasenack> the regexps could be better, though
[14:52] <Emmanuel_Chanel> tomaw: ok... The checksum doesn't match now.
[14:54] <tomreyn> Emmanuel_Chanel: i assume you meant to address me. if checksums dont match then you better download again until they do.
[14:54] <Emmanuel_Chanel> ok.
[14:55] <tomreyn> Emmanuel_Chanel: in case your connectivity is not reliable, there should also be torrents, which may help then.
[14:55] <Emmanuel_Chanel> I download it via torrent.
[14:58] <Emmanuel_Chanel> The torrents' ISO's sha1sum doesn't match SHA1SUMS
[14:59] <Emmanuel_Chanel> tomreyn: Probably, that's the trouble......
[15:00] <rbasak> ahasenack: I'm not sure, sorry. I wouldn't be surprised if I were involved with that at some point though.
[15:00] <rbasak> I use squid rather than squid-deb-proxy, but also for debs.
[15:01] <ahasenack> I'm tempted to improve that patch, taking some bits from squid-deb-proxy
[15:01] <rbasak> What does squid-deb-proxy get us apart from those rules and locking down to the archive (or is it debs?)?
[15:01] <ahasenack> like adding .bz2, .xz
[15:01] <rbasak> Improving it makes sense.
[15:01] <ahasenack> squid-deb-proxy also has acls, runs another copy of squid in another port
[15:01] <ahasenack> it's more tailored indeed
[15:01] <ahasenack> but I think we can take the improved patterns from there
[15:02] <tomreyn> Emmanuel_Chanel: it matches for me
[15:02] <Emmanuel_Chanel> ok. I try again.
[15:03] <tomreyn> Emmanuel_Chanel: I'm comparing the sha1sum over the .iso file downloaded using the .torrent at http://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.1-server-amd64.iso.torrent against http://cdimage.ubuntu.com/releases/18.04/release/SHA1SUMS
[15:04] <Emmanuel_Chanel> >87bedd68607f059ca973f86346bbdf1caa6e1077 *ubuntu-18.04.1-server-amd64.iso
[15:04] <Emmanuel_Chanel> What does the astarisk mean?
[15:05] <sdeziel> '*' is for binary
[15:05] <Emmanuel_Chanel> ok.
[15:05] <sdeziel> that's the input mode
[15:06] <Emmanuel_Chanel> tomreyn: I don't know why. But SHA1SUMS says that line and my result doesn't match yet.
[15:06] <Emmanuel_Chanel> $ sha1sum -b ubuntu-18.04-server-amd64.iso
[15:06] <Emmanuel_Chanel> 73ae6579ef7c51d944a0be5c4c48f748bfd689df *ubuntu-18.04-server-amd64.iso
[15:07] <sdeziel> Emmanuel_Chanel: you could use "sha1sum -c --ignore-missing SHA1SUMS" for easier comparison
[15:08] <sdeziel> Emmanuel_Chanel: isn't the SHA1SUMS file you downloaded the one for 18.04 and the ISO for 18.04.1 ?
[15:09] <tomreyn> Emmanuel_Chanel: didnt you mean to download 18.04.*1* ?
[15:09] <tomreyn> oh i'm late ;)
[15:09] <Emmanuel_Chanel> Yes, I downloaded ubuntu 18.04 server's.
[15:09] <Emmanuel_Chanel> sha1sum -c --ignore-missing SHA1SUMS says ok.
[15:09] <Emmanuel_Chanel> now.
[15:09] <Emmanuel_Chanel> $ sha1sum -c --ignore-missing SHA1SUMS
[15:09] <Emmanuel_Chanel> ubuntu-18.04.1-server-amd64.iso: OK
[15:10] <tomreyn> glad you worked it out.
[15:10] <sdeziel> odd, both http://cdimage.ubuntu.com/releases/18.04/release/SHA1SUMS and http://cdimage.ubuntu.com/releases/18.04.1/release/SHA1SUMS serve the same file
[15:11] <Emmanuel_Chanel> So my ISO was verified stuff......
[15:22] <rbasak> --ignore-missing? Handy!
[15:22] <Emmanuel_Chanel> $ sha1sum -b /dev/sr1
[15:22] <Emmanuel_Chanel> 87bedd68607f059ca973f86346bbdf1caa6e1077 */dev/sr1
[15:22] <rbasak> I always used grep
[15:22] <Emmanuel_Chanel> SHA1SUM matches my Ubuntu 18.01.1 Server DVD......
[15:22] <blackflow> rbasak: TIL after all these years.... :)  me too.
[15:23] <Emmanuel_Chanel> tomreyn: So I found that the error is on the released ISO image itself...
[15:28] <Emmanuel_Chanel> Around 12% point, "Software Selection and Installation" restarts. And it repeats forever.
[15:28] <Emmanuel_Chanel> It's same for Ubuntu 18.01 Server DVD.
[15:29] <tomreyn> Emmanuel_Chanel: have yu verified this against copletely separate hardware and installation media?
[15:31] <Emmanuel_Chanel> I don't understand what separate hardware means. I checked the installation media completely with SHA1SUM on http://cdimage.ubuntu.com/releases/18.04.1/release/SHA1SUMS
[15:32] <tomreyn> Emmanuel_Chanel: chances are you just have a bad dimm or something. i'll try on a VM.
[15:33] <Emmanuel_Chanel> Maybe... Well, I've installed Ubuntu 16.04.5 Server on the server and upgrade it to 18.04 now. I don't have another test environment. So I cannot check now.
[15:36] <tomreyn> Emmanuel_Chanel: can you tell me about your hardware please
[15:38] <Emmanuel_Chanel> Yes. HP ProLiant ML310e Gen8 v2
[15:38] <tomreyn> booting uefi or legacy?
[15:38] <Emmanuel_Chanel> legacy.
[15:39] <tomreyn> Emmanuel_Chanel: how did you partition?
[15:40] <tomreyn> i assume you have multiple disks form the installers' point of view?
[15:41] <tomreyn> these are the options you had during installation, the highlighted one is default: http://i.imgur.com/wU2Sfzc.png
[15:41] <Emmanuel_Chanel>  /dev/sda1 bios boot /dev/sda2 /boot /dev/sda3 main LVM and another space on /dev/sdb1
[15:41] <tomreyn> thanks, ext4 file systems? also on sdb1?
[15:42] <Emmanuel_Chanel> I've selected btrfs then.
[15:42] <tomreyn> where?
[15:42] <Emmanuel_Chanel> The multiple disks caused the problem?
[15:42] <Emmanuel_Chanel>  /dev/sdb1
[15:42] <tomreyn> so file systems on sda are ext4?
[15:42] <tomreyn> i don't know of any problem, yet
[15:43] <tomreyn> i'm trying to reproduce what you reported
[15:43] <Emmanuel_Chanel> $ ls /dev/mapper/
[15:43] <Emmanuel_Chanel> control           gateway--vg-root    gateway--vg-var
[15:43] <Emmanuel_Chanel> gateway--vg-home  gateway--vg-swap_1
[15:43] <Emmanuel_Chanel> Now the LVM volumes are such and execpt home and swap, they are ext4 partitions.
[15:44] <tomreyn> okay, and sdb1 is just this partition with btrfs directly on top, no lvm etc?
[15:44] <Emmanuel_Chanel> Yes. on top.
[15:47] <tomreyn> Emmanuel_Chanel: is /dev/sda > 2TB or did you create a GPT partition table there beforehand?
[15:48] <Emmanuel_Chanel> 6TB with GPT if I didn't mistake.
[15:48] <tomreyn> with this size the installer should automatically use GPT. i think it does use msdos & MBR for disks with <2TB capacity
[15:50] <Emmanuel_Chanel> I thought so, too. And it's working now.
[15:58] <Emmanuel_Chanel> tomreyn: You have that HP server?
[15:58] <tomreyn> no
[15:59] <tomreyn> i'm just another random user
[16:01] <Emmanuel_Chanel> ok.
[16:02] <Emmanuel_Chanel> Actually, what does the correct name of "Software Selection and Installation"?
[16:02] <Emmanuel_Chanel> I selected Japanese environment since I'm actually a Japanese man. ( Emmanuel_Chanel is just a handle. )
[16:04] <tomreyn> i don't understand the question, please clarify.
[16:05] <tomreyn> thanks for pointing out japanese, so it might be multi byte issue
[16:09] <jamespage> cpaelzer: hey around still?
[16:09] <Emmanuel_Chanel> You would see what I call "Software Selection and Installation" of the Ubuntu Server's installer. But I don't really know. So I asked its correct name.
[16:11] <Emmanuel_Chanel> Does that correct English shown name?
[17:06] <cpaelzer> jamespage: no more here, but coming by every now and then
[17:16] <tomreyn> Emmanuel_Chanel: sorry, didnt see your reply. i understand the installation step you mean (and do not remember the exact title myself). i did postpone testing this until there will be more indication that this is an actuall installer issue.
[17:21] <Emmanuel_Chanel> At 12% or so, the dialog window(?) occurs. And the step crashes and restarts. That error process repeats forever.
[17:22] <Emmanuel_Chanel> It says that it's down by segfault. And I don't find what segfault occurred.
[17:30] <jamespage> cpaelzer: I'll ping you tomorrow am re python-libvirt and py3.7
[17:51] <cpaelzer> jamespage: I think you don' thave to
[17:51] <cpaelzer> jamespage: 1786157 ?
[17:51] <cpaelzer> coreycb: already pinged me, the issue is quite clear
[17:51] <cpaelzer> to resolve we just need anything >=libvirt 4.5 in cosmic
[17:52] <cpaelzer> and that I work on since a week
[17:52] <cpaelzer> it is close to be ready, but I wait on upstream and Debian response to a lot of things and a MP review from the team
[17:52] <cpaelzer> My plan was to push that on Friday (and worst case clean up minor things later if upstream feedback is more complex than ack/nack)
[17:52] <cpaelzer> that in turn will unlick the new version whcih would work for you
[17:53] <cpaelzer> OTOH if my assumption on the particular bug is wrong, then let me know
[18:02] <cpaelzer> kstenerud: o/
[18:09] <tomreyn> Emmanuel_Chanel: while it's a live linux, the installer is a linux installation. you can switch tty's and the installer has an option to spawn a shell. it will have a 'dmesg' command and a syslog, too.
[18:11] <Emmanuel_Chanel> Sorry, I haven't checked dmesg. Just I remember that something got segfault to lead the Software Selection and Installation to restart.
[18:11] <Emmanuel_Chanel> tomreyn: You couldn't reproduce my situation? Sorry for not collecting more info. to tell.
[18:16] <tomreyn> Emmanuel_Chanel: no, i wasn't able to reproduce it. (but i don't have the same hardware available.)
[18:18] <Emmanuel_Chanel> Around 12%, on that steop, what software is started?
[18:18]  * RoyK guesses disk issues
[18:19] <RoyK> check dmesg
[18:20] <RoyK> or memory failure
[18:20] <RoyK> http://memtest.org/ is good
[18:20] <Emmanuel_Chanel> I should've done that. But now my server of that problem is back to ordinary operating.
[18:24] <Emmanuel_Chanel> tomreyn: Thanks for experiments!
[18:37] <tomreyn> welcome
[20:37] <runelind_q> if I'm running on HWE can I apt-get purge linux-image-generic?
[20:39] <sarnold> I'd expect that to work; report back if it gives you trouble :)
[20:43] <runelind_q> especially since I'm remote from the server :)
[21:17] <tobias-urdin> jamespage: heard from coreycb that he was away until friday so just reposting to you
[21:17] <tobias-urdin> 09:48 < tobias-urdin> coreycb: did something change in the tempest packages? we dont get the neutron tempest plugin anymore                                                                |
[21:17] <tobias-urdin> 09:48 < tobias-urdin>
[21:17] <tobias-urdin> http://logs.openstack.org/22/583222/14/check/puppet-openstack-integration-5-scenario004-tempest-ubuntu-bionic-mimic/cc35e59/job-output.txt.gz#_2018-08-14_23_31_33_113245
[21:17] <tobias-urdin> hopefully you'll see this tomorrow :) see you later
[21:18] <arrrghhh> Hey all.  I have a mdadm raid1 array (NOT the OS disk) - I'd like to tear it down back to be a simple JBOD
[21:19] <arrrghhh> It appears I should be able to umount the mdadm array, stop the array and zero the superblocks... but I can't stop the array or zero the superblocks, it seems *something* is still calling it... but I have successfully done the 'umount'
[21:21] <tomreyn> arrrghhh: are you hopeing to preserve the data this way?
[21:21] <arrrghhh> tomreyn, ideally if I could preserve the data on one disk... I do have backups
[21:21] <arrrghhh> but I would prefer to not have to resort to the backups as that takes time
[21:22] <tomreyn> arrrghhh: okay, i don't know whether this approach will work for doing so. it might, but not sure.
[21:22] <arrrghhh> tomreyn, well even if it does destroy the data, meh.  Whatever method gets it done...
[21:22] <tomreyn> arrrghhh: i can, however, comment on the tearing-things-apart-part.
[21:23] <tomreyn> so just unmounting the file systems wont be sufficient, you need to stop the array
[21:23] <arrrghhh> right, I can't stop the array :)
[21:23] <tomreyn> oh you actually planned that step, sorry
[21:23] <arrrghhh> I assume something is still accessing it... I don't know what.  lsof isn't very helpful
[21:23] <arrrghhh> Cannot get exclusive access to /dev/md0:Perhaps a running process, mounted filesystem or active volume group?
[21:24] <arrrghhh> I stopped all the docker containers and samba/nfs
[21:24] <tomreyn> "dmsetup ls" sometimes helps getting new ideas onwhat to try there
[21:24] <arrrghhh> hm ok
[21:25] <tomreyn> maybe you'll the the major/minor still mounted or otherwise 'used' this way?
[21:25] <arrrghhh> tomreyn, is that for LVM?  I only see my LVM volumes
[21:25] <tomreyn> but i know of no better way either
[21:25] <arrrghhh> I figured if I unmounted it, nothing else could be using it...
[21:25] <tomreyn> umm you're right, sorry, lvm and cryptsetup would use dmsetup
[21:25] <arrrghhh> I guess I can reboot the server
[21:25] <tomreyn> not mdraid
[21:26] <arrrghhh> comment the mount in fstab
[21:26] <arrrghhh> I'll try that when I get home.
[21:26] <arrrghhh> will bbiab, if anyone else has any ideas I'll read them when I get home :)
[21:26] <tomreyn> can you post /proc/mdstat
[21:32] <tomreyn> you mentioned you have lvm, if that's on top of /dev/md0 you'll need to vgchange -a n
[21:32] <tomreyn> (and, i think optionally, pvremove)
[22:09] <arrrghhh> well I seem to have dropped the channel... oh well, a reboot did get the array to stop
[22:09] <arrrghhh> oh the reboot.  derp lol
[22:18] <qman> arrrghhh: yeah, you have to luksclose or other wise un-crypto the thing and turn off the volume group
[22:19] <qman> And even then, lvm doesn't always let go without rebooting
[22:19] <qman> That's just a lovely lvm thing, it's been a persistent issue for years
[22:20] <qman> Well, a device mapper thing, more accurately
[22:20] <arrrghhh> hm I am not using LVM on this disk
[22:20] <arrrghhh> ah
[22:56] <arrrghhh> so after I zero the superblock, is there something I need to do to change the disks back to JBOD?
[22:57] <arrrghhh> I am trying to find the UUID with blkid so I can setup the individual disks in fstab and these two RAID disks are not showing up in blkid...
[22:58] <blackflow> arrrghhh: mdadm based software raid?
[22:59] <arrrghhh> blackflow, yes correct mdadm
[23:00] <arrrghhh> it was RAID1, I am trying to break the array and just have two plain ole disks..
[23:00] <arrrghhh> ideally preserving the data on one, but not essential.
[23:01] <blackflow> arrrghhh: did you mdadm --stop    the array first?
[23:01] <arrrghhh> yep
[23:01] <blackflow> not sure then. you can always reboot.
[23:01] <arrrghhh> oh ok
[23:01] <blackflow> or wait... see what partprobe does
[23:02] <arrrghhh> sure
[23:02] <arrrghhh> well without sudo it was mad.  with sudo, nothing.  just paused for a bit and went to the next line, nothing in the output
[23:02] <blackflow> arrrghhh: yeah but does blkid now list individual disks/partitions?
[23:03] <blackflow> which btw... should've been listed even before.
[23:03] <arrrghhh> nope
[23:03] <arrrghhh> /dev/sdb1 and /dev/sdc1 are not in blkid
[23:03] <blackflow> mdadm devices don't change the visibility of individual disks/partitions to the kernel. are you sure that's all mdadm? no hardware raid anywhere? not evne bios fakeraid?
[23:03] <arrrghhh> no fakeraid
[23:04] <arrrghhh> this is how they show up in fdisk -l: "/dev/sdb1        2048 1953525167 1953523120 931.5G fd Linux raid autodetect"
[23:04] <arrrghhh> https://hastebin.com/wicosezequ.coffeescript
[23:05] <blackflow> hm, maybe the partition type is confusing blkid. you can always reset those to 83
[23:05] <arrrghhh> that's what I was thinking, that raid autodetect type
[23:05] <arrrghhh> ok
[23:06] <blackflow> it's been a while since I last used mdadm. I've been ZFS-ing for years now :)
[23:06] <sarnold> :)
[23:06] <blackflow> sarnold: oh yeah, you like ZFS too! ;)   *highfive*
[23:06]  * sarnold ^5 blackflow
[23:10] <arrrghhh> hm.  well even after a reboot they do not show up in blkid...
[23:11] <blackflow> arrrghhh: changed partition types?
[23:11] <arrrghhh> well on one of the disks I did
[23:11] <arrrghhh> but neither show up... hm
[23:13] <blackflow> are those partitions linked in /dev/disk/by-uuid?
[23:13] <blackflow> blkid is just... summarizing the information you already have available in /dev
[23:14] <arrrghhh> hm there are some dm-1, dm-2 etc devices
[23:14] <arrrghhh> but I don't see sdb1 or sdc1
[23:15] <arrrghhh> there are four of these "dm-#" devices...
[23:15] <blackflow> arrrghhh: how about    blkid -g   ?
[23:15] <arrrghhh> not sure what -g does, but it is empty
[23:15] <blackflow> `man blkid` will explain :)
[23:16] <arrrghhh> garbage collect the cache
[23:16] <arrrghhh> yea I looked at the help sorry
[23:16] <blackflow> well, I'm guessing those partitions are lacking any meaningful identifiers to be noted as individual devices, being part of the raid array. missing labels, uuids, or something.
[23:17] <arrrghhh> so... reformat?
[23:17] <blackflow> repartition, reformat, something like that.
[23:17] <arrrghhh> hm bummer.  well this is why I took a backup lol
[23:18] <arrrghhh> I thought it would be possible to break the array tho without data loss... oh well
[23:18] <blackflow> arrrghhh: try removing the partition layout and then repartitioning exactly the same way, sector-wise
[23:18] <blackflow> eg with parted,   mklabel msdos   and then mkpart  for each, using sector numbers to have _exactly_ the same layout
[23:19] <blackflow> that should give them partuuid at least, and blkid/kernl should be able to see them as such. might need to run partprobe after you re-partition
[23:20] <blackflow> note that partitioning only changes the partition tables. if you re-partition in exactly the same way, the data under them should stay intact and at the same offsets.
[23:20] <arrrghhh> right
[23:21] <arrrghhh> I'm just looking up how this works, I don't use parted all that often
[23:22] <blackflow> there are other tools, parted is just something I'm used to
[23:25] <arrrghhh> I just get the start/end with fdisk right?
[23:27] <arrrghhh> hm parted shows it as well
[23:27] <arrrghhh> but it seems odd... not precise I guess
[23:29] <blackflow> that's why I mention using sectors and not MB or MiB
[23:34] <arrrghhh> blackflow, mklabel says it will destroy data...?
[23:34] <arrrghhh> Warning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you
[23:34] <arrrghhh> want to continue?
[23:34] <arrrghhh> oops.
[23:35] <sarnold> it might not actually overwrite all data, but just the user know the most likely outcome
[23:35] <sarnold> if you're playing games behind the back of the system it might still work. and if not, well, you've got backups, right? right? :)
[23:37] <arrrghhh> yep I do
[23:37] <arrrghhh> was hoping to avoid using them, as it will take a lot longer to restore.... but they are there
[23:38] <sarnold> good good. then you can carry on with your wild experiment :)
[23:38] <arrrghhh> I didn't think breaking a raid array would be this hard...
[23:39] <arrrghhh> oh there is no 'file system' listed when I print this disk
[23:39] <arrrghhh> that may be an issue...
[23:39] <arrrghhh> I guess I have to format at that point?
[23:44] <sirvictory4> is it safe to mix input- and output-type filter rules in a single custom iptables chain? Or should I have something like webserver-in and webserver-out chains?
[23:46] <arrrghhh> well after a reboot and a format the one disk is showing... that sucks tho :(
[23:47] <whislock> sirvictory4: What are you trying to achieve?
[23:49] <whislock> arrrghhh: Completely irrelevant, but I keep thinking of Monty Python/Holy Grail when I see your name.
[23:49] <sirvictory4> whislock: just organizing my iptables rules, thats all
[23:49] <arrrghhh> well that castle was one of the inspirations
[23:49] <sirvictory4> they are getting long
[23:49] <whislock> sirvictory4: Doesn't really help me much.
[23:50] <whislock> sirvictory4: Are you doing anything overly complicated?
[23:51] <sirvictory4> whislock: ok, a simple matching rule of "-p icmp -j my-icmp-table" for both INPUT and OUTPUT
[23:53] <arrrghhh> so is there any other way after doing a mkfs.ext4 on the partition I can get blkid to pick it up without rebooting?
[23:53] <arrrghhh> wait nvm.  /dev/disk/by-uuid has it.
[23:54] <whislock> sirvictory4: Honestly, I long ago gave up trying to manage iptables myself. I just use ufw/firewalld these days. Just as good, 1% of the effort.