fsmithred | Ryushin, I recall clearly now that it said Devuan in the boot menu. | 03:10 |
---|---|---|
fsmithred | both when I was booting from command line and after I fixed it | 03:11 |
Ryushin | fsmithred: Let me check my VM. | 03:28 |
Ryushin | My grub menu shows Devuan. The UEFI has an entry for devuan and debian. So that is why my vm probably booted just fine. If it could not boot one, it booted the other. | 03:31 |
Ryushin | running efibootmgr on my laptop shows Debian, Windows Boot Manager, refind, and devuan. Hmm... no wonder booting got messed up. | 03:34 |
Ryushin | Wondering if grub should be forked to keep thing like this from happening in the future. Seems a bit like over kill though. | 03:35 |
fsmithred | might be a simple fix | 03:42 |
Ryushin | I'm thinking so. | 03:44 |
Ryushin | In the VM, I deleted the debian UEFI entry and its /boot/efi/EFI/debian directory. | 03:46 |
fsmithred | rm or efibootmgr? | 03:46 |
Ryushin | I did a grub-reinstall again, and it did not create a /boot/efi/EFI/debian folder. But now, during boot, it drops to a grub shell and shows the prefix as (hd0,gpt1)/EFI/debian | 03:47 |
Ryushin | let me see if it created a debian uefi entry. | 03:47 |
fsmithred | oh, so now it knows where the efi partition is | 03:47 |
fsmithred | other than that, it's expected behavior | 03:48 |
fsmithred | or consistent with my experience, anyway | 03:48 |
Ryushin | So now the prefix is wrong and it will no longer boot. devuan uefi entry and /boot/efi/EFI/debian. | 03:48 |
Ryushin | But if the debian folder was there, it would boot. At least I think it will. Let me try. | 03:49 |
Ryushin | Yep, I just copied the /boot/efi/EFI/devuan to /boot/efi/EFI/debian and now the system boots. | 03:50 |
Ryushin | So the prefix is pulling from the debian folder. Who knows how long both folders were there. | 03:51 |
fsmithred | editing that grub.cfg should also work to fix it | 03:52 |
Ryushin | And there is only one UEFI entry for devuan. | 03:52 |
Ryushin | Are you thinking bout removing the prefix and hard coding it? | 03:53 |
Ryushin | Editing /boot/efi/EFI/devuan/grub.cfg or /boot/grub/grub.cfg? | 03:54 |
fsmithred | EFI/devuan/grub.cfg | 03:55 |
fsmithred | I don't really want to do that | 03:55 |
fsmithred | but might do it anyway, just to see | 03:55 |
fsmithred | but not tonight. almost time for me to sleep. | 03:55 |
Ryushin | I'm testing, but I'm thinking the /boot/efi/EFI/devuan/grub.cfg is never even read yet. As it's entry is set prefix=($root)'/boot/grub | 04:00 |
Ryushin | Let me look at the efibootmgr | 04:01 |
Ryushin | efibootmgr -v shows Boot0001* devuanHD(1,GPT,5ae879c2-723d-46be-8696-ae9fb5d90e62,0x800,0xee000)/File(\EFI\devuan\grubx64.efi) | 04:09 |
Ryushin | And echo $prefix shows (hd0,gpt1)/EFI/debian | 04:10 |
Ryushin | So I'm really thinking now that debian had hard coded that in the prefix somewhere in the code. | 04:11 |
Ryushin | So tomorrow then. At least I think we are getting closer. | 04:15 |
fsmithred | yeah, thanks | 04:15 |
Ryushin | fsmithred: Need to look closer, but this might be our bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769172 | 13:56 |
Ryushin | In version: 2.02+dfsg1-5 | 13:57 |
fsmithred | Looks like that's the right place. I'm getting the source package now. | 14:07 |
Ryushin | I think you will need to change line 32: efi_vendor="${6:-$(dpkg-vendor --query vendor | tr '[:upper:]' '[:lower:]')}" | 14:11 |
Ryushin | I think Devuan will need to fork the package actually for the new signed package grub-efi-amd64-signed | 14:12 |
fsmithred | oh, maybe | 14:13 |
fsmithred | wonder what happens if I remove that package | 14:13 |
Ryushin | Reading that bug, I don't think it matters as they hard coded the prefix now. | 14:13 |
fsmithred | that needs to change | 14:14 |
fsmithred | unless they're planning to drop the --bootloader-id option | 14:14 |
fsmithred | not sure then what happens if you have two debian installs on the same box | 14:15 |
fsmithred | they compete for bootloader, I guess | 14:15 |
Ryushin | I think it's because of the whole signing issue. And that was the signed package that I noticed between my old version of grub that I was installing and the new one. | 14:15 |
fsmithred | yeah, I saw that and wondered about it | 14:15 |
fsmithred | damn, cloning the git is s l o w | 14:17 |
Ryushin | I don't think having the two debian installs would affect it. It's just going to start one grub.cfg file and you will need a chainloader to point to boot the other debian distro. | 14:18 |
onefang | That's how my Magic Pixie Dust USB stick works. 20 odd distros, some of them Debian based. | 14:19 |
Ryushin | I think that this is just a nature of having a signed distro now? | 14:19 |
onefang | It doesn't do EFI though. | 14:20 |
Ryushin | I guess refind or a unsigned grub will have to be used. | 14:20 |
onefang | Devuan ASCII is the main one that controls grub. | 14:20 |
fsmithred | onefang, don't go away - I'm gonna give you a link | 14:21 |
onefang | I gotta stay up for at least the next hour. | 14:21 |
fsmithred | https://get.refracta.org/files/experimental/dev1usb_2019-01-25.img | 14:22 |
fsmithred | test build of a live usb that uses grub | 14:22 |
fsmithred | bios/uefi, devuan desktop-live, minimal-live, netinstall and mini.iso | 14:23 |
fsmithred | um, maybe not mini.iso on that one | 14:23 |
Ryushin | Not sure if devuan wants to build the EFI signing infrastructure or not. | 14:24 |
fsmithred | anyway, minimal-live fails to boot and netinstall requires dropping to console and running a few commands to get the installer to find the cd | 14:24 |
fsmithred | no devuan devs are looking for more work to do | 14:24 |
onefang | I probably wont get to look at it until Wednesday, but I'm downloading it now. | 14:24 |
onefang | Slowly. lol | 14:25 |
Ryushin | fsmithred: I would not think the devs would want any more to do as well, especially something like grub to manage. But I don't see a way out unless you fork the package and remove all the signing components. | 14:27 |
Ryushin | The easiest path might be to create the signing infrastructure and that way you can just keep using the debian source. | 14:28 |
Ryushin | I really have no interest in needing secure boot to work. | 14:28 |
fsmithred | same here | 14:28 |
onefang | I'm only interested in having something that boots on legacy and EFI, without having to diddle with the BIOS settings. | 14:29 |
fsmithred | I have to reboot to do this, but I'll try removing the -signed package | 14:29 |
onefang | Bonus if it can boot on a Mac. | 14:29 |
fsmithred | onefang, you're talking about a live or installer disk? | 14:30 |
onefang | USB stick I carry with me, tat has the 20 odd distros, boot on what ever computer I need no work on, choose the distro depending on what I need at the time. Sometimes that might be to install something. My swiss army knife. | 14:31 |
fsmithred | what does it use for booting? | 14:32 |
fsmithred | (which bootloader) | 14:32 |
onefang | BIOS Grub at the moment. | 14:32 |
onefang | A grub that is controlled from the main distro, ASCII. | 14:33 |
fsmithred | yjsy | 14:33 |
fsmithred | oops | 14:34 |
fsmithred | that's a regular installation, or a live system? | 14:34 |
onefang | Regular install, though some of the others are live systems. | 14:34 |
onefang | HEADS is a live system. Most of the Red Hat ones are to, but that's coz the RH installer can't handle sharing a GPT with others. The exception there is QUBES. | 14:36 |
fsmithred | I couldn't get heads to boot on my multi-boot live-usb | 14:37 |
fsmithred | drops to initramfs shell | 14:37 |
fsmithred | I'd like to see your boot menu entry for that | 14:38 |
Ryushin | fsmithred: Going to rebuild the grub source package. | 14:41 |
fsmithred | oh, good luck. You changed something in it? | 14:41 |
Ryushin | Nope. I think it will pick up the devuan line just fine. This line should show devuan: dpkg-vendor --query vendor | tr '[:upper:]' '[:lower:]') | 14:43 |
onefang | I need a new SD card reader. lol | 14:46 |
fsmithred | Ryushin, I removed the devuan and debian bootloaders and the grub-efi-amd64-signed package | 14:48 |
fsmithred | ran grub-install and update-grub and it boots correctly | 14:49 |
fsmithred | it created a devuan boot dir on the efi partition, and that works | 14:49 |
Ryushin | You also deleted the /boot/efi/EFI/debian directory? | 14:50 |
fsmithred | yes | 14:50 |
Ryushin | nice. | 14:50 |
fsmithred | I used efibootmgr -b XXXX -B XXXX | 14:50 |
fsmithred | on both devuan and debian bootloaders | 14:50 |
fsmithred | which removed those dirs | 14:50 |
onefang | The relevant lines are - | 14:50 |
fsmithred | grub-install made a new devuan dir, and it works | 14:51 |
Ryushin | I did not know that. I manually deleted the directories but used the efibootmgr to delete the UEFI entires. | 14:51 |
onefang | search -n -l "heads amd64" -s | 14:51 |
onefang | chainloader +1 | 14:51 |
fsmithred | you have the intact iso file on the usb, or you unpacked it? | 14:52 |
fsmithred | ^^^ onefang | 14:53 |
onefang | It's an ext4 partition with /isolinux and /live. | 14:55 |
onefang | So the chainloader is running isolinux. | 14:55 |
onefang | Ah, I run extlinux on that partition to make it bootable. | 14:58 |
fsmithred | yeah, extlinux with ext | 14:58 |
fsmithred | do you know if chainloader would work to boot an iso file? | 15:00 |
fsmithred | need food. brb | 15:01 |
onefang | I think I have some of those on there. | 15:01 |
onefang | Hmmm, I used to have some of those, but I ended up unpacking them. So that's a yes in theory, I managed it somehow or other, just can't recall the details. It was years ago. | 15:07 |
Ryushin | fsmithred: Holy smokes, the grub compile tests take a LONG time to run. They are still running. | 15:10 |
Ryushin | So compiling the source did not produce the grub-efi-amd64-signed package. It produced a grub-efi-amd64-signed-template_2.02+dfsg1-10_amd64.deb package. | 15:29 |
fsmithred | so it can be modified for any distro? | 15:29 |
fsmithred | (if you can figure out what to do with it) | 15:30 |
Ryushin | Well, I'm thinking that debian has another step that creates the grub-efi-amd64-signed package. | 15:30 |
fsmithred | yeah, probably some secret command | 15:30 |
Ryushin | Just compiling the grub package does not produce it. | 15:30 |
Ryushin | Well, I think it is that signing infrastructure that was mentioned in the bug. | 15:30 |
Ryushin | Let me remove that signed package like you did and run your same tests. | 15:31 |
fsmithred | yes, I think that's what puts the grub.cfg in the efi partition | 15:31 |
fsmithred | wait! | 15:32 |
Ryushin | waiting.... :) | 15:32 |
fsmithred | run 'aptitude why grub-efi-amd64-signed' | 15:32 |
fsmithred | I forgot to do that to see what pulled it in | 15:32 |
Ryushin | i grub-efi-amd64 Depends grub-efi-amd64-bin (= 2.02+dfsg1-10) i A grub-efi-amd64-bin Recommends grub-efi-amd64-signed | 15:33 |
Ryushin | So another recommended package. Just like apparmor and the kernel. | 15:33 |
fsmithred | ah, ok. first part of my install did not exclude recommends | 15:34 |
Ryushin | But just doing an apt upgrade if there is a new grub package will install grub-efi-amd64-signed package. | 15:34 |
fsmithred | will it? | 15:35 |
Ryushin | So can Devuan just exclude the file in the merged? | 15:35 |
fsmithred | oh, maybe dist-upgrade will do it. Upgrade should not install any new packages | 15:35 |
Ryushin | Yep, it will. Found that out the hard way with apparmor. | 15:35 |
fsmithred | damn | 15:36 |
fsmithred | we might want to keep the package available in case someone needs secure boot | 15:36 |
Ryushin | So perhaps with the merged packages the signed package can be blacklisted | 15:36 |
fsmithred | pretty sure it can | 15:36 |
Ryushin | It's useless without providing the back end for creating the signed package for devuan. | 15:37 |
fsmithred | won't it work if you use --bootloader-id=debian? | 15:37 |
Ryushin | Well, there has to be a /boot/efi/EFI/devuan|debian folders to work. | 15:38 |
Ryushin | Let me test removing the signed package like you did. | 15:39 |
fsmithred | ok | 15:39 |
Ryushin | fsmithred: Yep, so removing the signed package removes the forced prefix. | 15:45 |
Ryushin | So just have that package blacklisted | 15:45 |
Ryushin | BTW, it seems that efibootmgr -b XXXX -B XXXX did not delete the folders in /boot/efi/EFI. I had to do that manually. | 15:46 |
fsmithred | maybe different uefi implementations | 15:46 |
fsmithred | I'm using a toshiba laptop | 15:46 |
fsmithred | the efibootmgr command to change the order of the bootloaders works, but then it reverts to the old order when I reboot. So really, it doesn't work. | 15:47 |
Ryushin | Okay, so problem solved. Someone just needs to blacklist the package. | 15:50 |
KatolaZ | I hope you can summarise the discussion later | 15:51 |
KatolaZ | :) | 15:51 |
fsmithred | summary of the first part is in my email to devuan-dev yesterday | 15:51 |
fsmithred | mini.iso install boots to grub prompt | 15:52 |
KatolaZ | fsmithred: but that is about mini.iso, not minimal-live right? | 15:52 |
fsmithred | right | 15:52 |
fsmithred | it's about grub | 15:52 |
KatolaZ | fsmithred: in which case, in particular? | 15:52 |
KatolaZ | ('cause I have used it several times already) | 15:52 |
fsmithred | new grub includes grub-efi-amd64-signed, which puts a grub.cfg in the devuan dir on the efi partition | 15:53 |
fsmithred | but that grub.cfg wants to find a debian dir on that partition | 15:53 |
KatolaZ | in the debian partition | 15:53 |
fsmithred | yes | 15:53 |
fsmithred | no | 15:53 |
KatolaZ | we have not forked grub | 15:53 |
fsmithred | devuan partition | 15:53 |
KatolaZ | so where does the "devuan" come from? | 15:53 |
fsmithred | grub | 15:53 |
KatolaZ | mmmhhh | 15:53 |
KatolaZ | how? | 15:53 |
fsmithred | it knows we're running devuan | 15:53 |
fsmithred | grub magic | 15:53 |
KatolaZ | oh son of a bitch, that grub | 15:54 |
fsmithred | lol | 15:54 |
KatolaZ | badass chap :D | 15:54 |
onefang | That's grub 2, it's twice as bad. | 15:54 |
fsmithred | I think most people would agree with that | 15:54 |
Ryushin | grub-efi-amd64-signed forced a grub prefix of (root)/EFI/debian and it will never find the (root)EFI/devuan folder. | 15:54 |
KatolaZ | well, let's just convince grub to use a debian/ folder | 15:55 |
KatolaZ | (obvious and, I guess, not immediate) | 15:55 |
fsmithred | you can do 'grub-install --bootloader-id=debian' and it will work | 15:55 |
KatolaZ | I wonder where grub takes that info from | 15:55 |
fsmithred | but really, grub needs to be fixed upstream | 15:55 |
KatolaZ | is this related to lsb maybe? | 15:55 |
fsmithred | KatolaZ, I've seen the code, and it looks at a lot of things | 15:55 |
fsmithred | somewhat | 15:55 |
KatolaZ | the only sane way to fix grub is to ditch it | 15:55 |
Ryushin | Doing the --bootloader-id=debian creates the EFI/debian folder, which then will have the EFI/devuan work. | 15:56 |
KatolaZ | fsmithred: but is it a grub thing or something in the debian package? | 15:56 |
fsmithred | yeah, but the bootloader-id option should work no matter what I want to call my bootloader | 15:56 |
fsmithred | debian | 15:56 |
fsmithred | pretty sure | 15:56 |
KatolaZ | ok | 15:56 |
KatolaZ | then let's dig it out | 15:56 |
fsmithred | Ryushin, you don't need to have EFI/devuan | 15:57 |
fsmithred | just EFI/debian will work | 15:57 |
Ryushin | It's from this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769172 | 15:57 |
fsmithred | but will be a problem if you want to have devuan and debian installed on the same box | 15:57 |
fsmithred | well, just one will run the boot | 15:57 |
Ryushin | True, if you want to just keep EFI/debian, then sure. | 15:57 |
KatolaZ | Ryushin, fsmithred: please put up a pad | 15:57 |
KatolaZ | to collect this info | 15:58 |
fsmithred | can't we discuss it on the ml? | 15:58 |
KatolaZ | yes, as well | 15:58 |
fsmithred | I'm considering making a bug report to debian | 15:58 |
KatolaZ | ok | 15:58 |
fsmithred | fucking --bootloader-id should work | 15:59 |
KatolaZ | it's worth trying | 15:59 |
Ryushin | But if you want to have EFI/devuan, then we just need to black list the grub-efi-amd64-signed package. Since devuan does not have the signed boot loader infrastructure anyway, it can be removed. | 15:59 |
fsmithred | yeah, that's an easy fix | 15:59 |
KatolaZ | Ryushin: but this will make booting Devuan on secureboot impossible, right? | 15:59 |
KatolaZ | (well, it seems to be screwed up atm anyway) | 16:00 |
fsmithred | yes | 16:00 |
fsmithred | as it is now | 16:00 |
fsmithred | well, you can do your own signing, but I've never tried that | 16:00 |
fsmithred | Rod Smith has instructions | 16:00 |
fsmithred | rEFInd guy | 16:00 |
Ryushin | KatolaZ: I've never done any secureboot. First things I've always disabled. I was thinking in order for it to work, there would be a debian UEFI boot entry and not devuan. | 16:02 |
KatolaZ | Ryushin: it looks like we need to have our own signed package | 16:03 |
Ryushin | I have no idea how much work is involved in creating the signed infrastructure to create the grub-efi-amd64-signed package as just compiling the grub deb source does not produce it, but a template file. | 16:04 |
fsmithred | template package | 16:04 |
fsmithred | what's in it? | 16:04 |
Ryushin | So in my eyes, the two ways forward for devuan is to black list the signed package and keep grub working the way it always has, or create the infrastructure and fork the package and compile it and create the signed package. | 16:05 |
fsmithred | having our own signed package would be the better solution | 16:05 |
Ryushin | Don't know what is in it. I guess I should find out. :) | 16:05 |
Ryushin | DEBIAN/control: This package contains template files for grub-efi-amd64-signed. This is only needed for Secure Boot signing. | 16:09 |
Ryushin | Other files look like they are just part of the template. I'll put the deb up on my cloud so you can extract it and see for yourselves. | 16:13 |
fsmithred | the template package is in the repo | 16:13 |
fsmithred | I'm going to install it | 16:13 |
Ryushin | Good solution. | 16:14 |
fsmithred | maybe it will let me make my own signing files | 16:14 |
Ryushin | Need to go get ready. I started working on this first thing when I got up. | 16:14 |
Ryushin | be back in awhile. | 16:14 |
fsmithred | ok, see you later | 16:14 |
Ryushin | fsmithred: Did you get signing to work? | 17:38 |
fsmithred | HAHA | 17:38 |
fsmithred | I installed the template package and it seems to only have the files for a debian directory (for packaging) | 17:38 |
fsmithred | here's the file list: https://termbin.com/qavb | 17:40 |
Ryushin | Hmm... So right now it's magic on how that signed package is created? | 17:42 |
fsmithred | yeah | 17:42 |
fsmithred | I'm working on other stuff now, so I didn't look inside any of those files | 17:42 |
Ryushin | I wonder if the Debian devs have any documentation on what they did to create the package. | 17:43 |
fsmithred | or how to use it | 17:43 |
fsmithred | might find more looking in ubuntu - they did it first, and they tend to have explanations | 17:43 |
Ryushin | Reading the meta bug on secure boot: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036 | 17:44 |
Ryushin | Boy, that thing gets ugly in a hurry. | 17:46 |
Ryushin | Just blacklist the signed package. | 17:46 |
fsmithred | lol | 17:47 |
fsmithred | I'm ok with that. If you must run windows, run it on another machine on another subnet, please. | 17:47 |
Ryushin | If one of the Devuan devs gets bored out of their skull and is has to scratch a new itch, then have at it. Otherwise, the path of less resistance. | 17:49 |
KatolaZ | Ryushin: less resistance is fine, but a longish-term plan would be better | 17:50 |
KatolaZ | we now know that secureboot won't work Devuan | 17:50 |
Ryushin | KatolaZ: Well, not without a dev taking the time to do it. Perhaps it would not be so bad if you could have an copy of the infrastructure how debian or ubuntu does it. But it still will require forking the package, getting a shim key from Microsoft, etc. I think it only makes sense if an infrastructure was in place for smaller distros. | 17:54 |
Ryushin | Otherwise, far too much work. Unless it was paid for by a company that needs it to be in Devuan for their infrastructure. | 17:55 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!