| systemdlete | When I installed a devuan chimaera for use as a master clone VM, I accidentally made /usr encrypted. So I found some articles on the web instructing how to "unencrypt" a device. https://www.thegeekdiary.com/centos-rhel-how-to-delete-luks-encrypted-device/ is one example; others seem to be copy-paste of the same instructions, idk. At any | 02:47 |
|---|---|---|
| systemdlete | rate, the VM will no longer boot, and guess what I forgot to do before I started this process on a VM!? (Want to kick myself in the head for this.) | 02:48 |
| systemdlete | It prompts me for the passphrase for the first device, which I enter. Then the next message is telling me that the device I "unencrypted" is not a valid luks device. That is true. It should not be at this point. But the boot just hangs then. I took a look at the cryptsetup-early init scripts and the libraries, but still haven't figured | 02:50 |
| systemdlete | it out. | 02:50 |
| systemdlete | Note that I did try removing the crypttab entry for the device, but it did not help either. (I am using a recent systemrescuecd for these recovery attempts.) I could start all over, but I was hoping to succeed at this because I have a couple of clones that need this treatment as well. | 02:51 |
| systemdlete | Again, I ACCIDENTALLY made /usr encrypted, it was not intentional. Seriously; there is no need for /usr to be encrypted, unless it is part of some "security through obscurity" scheme, which is totally silly. | 02:53 |
| fsmithred | boot live iso, open and mount /usr, mount /, copy /usr to the root partition, fix fstab | 02:53 |
| systemdlete | it's not as simple as that, unfortunately. | 02:54 |
| systemdlete | I copied the encrypted drive to a temp drive, then re-created the lv and the filesystem and copied filesystem back to the same drive. | 02:55 |
| systemdlete | (I still have the temp drive image of /usr, though, if that is needed for yet a 3rd attempt.) | 02:55 |
| systemdlete | fsmithred: I followed the instructinons on those web pages faithfully, of course substituting my own drive names etc. So I still don't understand why boot complains. Somehow, crypt tools have kept a record, somewhere, that /usr is still encrypted, even though it is not. | 02:56 |
| fsmithred | did you rebuild initrd? | 02:57 |
| systemdlete | No, and I am thinking that is probably the source of my misery. | 02:57 |
| systemdlete | systemrescuecd could be used for that purpose, and I suppose that is what I need to do. | 02:58 |
| fsmithred | probably. I use my own. | 02:58 |
| systemdlete | the problem is that in order to get the system to the point where I can run mkinitrd (or whatever it is called), I first need to boot the system, which I can no longer. The other way is to carefully mount bind the fssys and proc and dev and all the other fs which is tedious and I dread doing it for fear I will mess things up worse. I've | 03:00 |
| systemdlete | done it in the past for other scenarios, successfully, but I dread the process. | 03:00 |
| fsmithred | mount the system, chroot, run 'update-initramfs -u -k all' | 03:00 |
| systemdlete | It would be nice if someone had a standard utility in, say, /bin, that could do this with a few hints. I mean, as a standard part of a distro. | 03:00 |
| systemdlete | yeah, I know... | 03:01 |
| fsmithred | the installer isos in rescue mode will normally mount the system easily | 03:01 |
| systemdlete | wont' they run into the same problem and hang? | 03:03 |
| fsmithred | I've never encrypted just /usr, so I don't know what it will do. But I think it's worth a try. I have used it with lvm and also raid. | 03:04 |
| systemdlete | some other fs are also encrypted, which is why the boot still wants to get passwords for the other filesystems. But it is the initrd that is bad here. | 03:09 |
| systemdlete | the easiest way would be to somehow unzip the initrd, fix the cryptsetup file there, then rezip it. But I know in the past this was not easy to do because there was some issue with unzipping it long enough to make those changes. I forget specifically what that was. | 03:13 |
| systemdlete | amazingly, I think I've done it. I un-cpio'd the untarred image, made the cryptsetup change, re-cpio'd it, ziped it and named it back to what grub expects and voila! | 03:34 |
| systemdlete | I will now make a note to myself on how to do this in the future and add it to my elog notebook. And that will include snapshotting the VM prior to starting as well as updating the initrd image. | 03:35 |
| systemdlete | actually, repairing the initrd image was not as difficult or grueling as I remember it from years ago. | 03:36 |
| sasha1805 | I have Devuan Chimaera 4 stable xcfe and problem with adding ppa in repository: | 11:59 |
| djph | sasha1805: 'ppa' are usually ubuntu-specific things ... | 11:59 |
| sasha1805 | root@Think-Desktop:/home/think# sudo add-apt-repository ppa:yannick-mauray/quickgui | 12:00 |
| sasha1805 | sudo apt update | 12:00 |
| sasha1805 | Traceback (most recent call last): | 12:00 |
| sasha1805 | File "/usr/bin/add-apt-repository", line 95, in <module> | 12:00 |
| sasha1805 | sp = SoftwareProperties(options=options) | 12:00 |
| sasha1805 | File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 109, in __init__ | 12:00 |
| sasha1805 | self.reload_sourceslist() | 12:01 |
| sasha1805 | File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 599, in reload_sourceslist | 12:01 |
| sasha1805 | self.distro.get_sources(self.sourceslist) | 12:01 |
| sasha1805 | File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources | 12:01 |
| sasha1805 | raise NoDistroTemplateException( | 12:01 |
| sasha1805 | aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Devuan/chimaera | 12:01 |
| sasha1805 | Ign:1 cdrom://[Devuan GNU/Linux 4.0 chimaera amd64 - desktop 20211012] chimaera InRelease | 12:01 |
| sasha1805 | Err:2 cdrom://[Devuan GNU/Linux 4.0 chimaera amd64 - desktop 20211012] chimaera Release | 12:01 |
| sasha1805 | Please use apt-cdrom to make this CD-ROM recognized by APT. apt-get update cannot be used to add new CD-ROMs | 12:01 |
| sasha1805 | Hit:3 http://deb.devuan.org/merged chimaera InRelease | 12:01 |
| sasha1805 | Hit:4 http://pkgmaster.devuan.org/merged chimaera-security InRelease | 12:01 |
| sasha1805 | Hit:5 http://deb.devuan.org/merged chimaera-updates InRelease | 12:01 |
| sasha1805 | how can i install this? Here my dream but i cant add ppa https://github.com/quickemu-project/quickgui | 12:03 |
| djph | compile it from source. | 12:04 |
| debdog | there's even a pre-compiled binary available | 12:13 |
| dacav | Hello | 23:57 |
| dacav | I've got here a freshly installed devuan that is unable to find the root filesystem. After waiting for a while, it says "error opening /dev/md?*: No such file or directory" | 23:58 |
| dacav | it looks like the ext4 module is not loaded, maybe that's the reason | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!