8
Advice needed for dualboot x86_64 on an already partitioned drive (thelemmy.club)
submitted 1 week ago by to c/nura@lemmy.world
8 comments fedilink hide all child comments
 

cross-posted from: https://lemmy.ml/post/53368173

Hello lemmy and Nura :D.

First time being around these parts of the web. I am a MX Linux daily driver and would like to dualboot with Nura on PC. I already exported my pmbootstrap'd split images and installed them to the last 2 partitions of my SSD with Gnome Disks (idk if it counts as flashing, pls view the attached image).

Updating grub with # update-grub seemed to work, it printed pmOS being found at sda7, but trying to boot off that gets stuck. I tried talking to a LLM to solve the issue, and my conclusion is that neither does it know well enough about pmOS/Nura - I rather not waste my time in it's hallucination, and also the way I try to setup Nura is probably not documented anywhere (or maybe I suck at reading wiki). For short, It has made me aware that os-prober does not know what to do with Nura, and that manually writing Nura to grub configs is the way.

Need a hand with that, please... thanks.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 1 week ago (4 children)

Uh, sorry, I meant the actual contents of the grub config (most probably (pmOS boot)/grub.cfg. The one with stuff like vmlinuz and initrd

To me it looks like there's some problem with running the init. I'd guess either the partition reference, path or maybe just some empty something. But that's all I can guess without the contents of the config

Just for your info - you could be running from shared boot partition. Just make sure one OS doesn't overwrite the kernel and initramd of the other. It's not a problem, just a piece of info

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 1 point 1 week ago (3 children)

    Ah, no problem! So there is nothing related to grub at all in pmOS_boot... However the system is boot-able through UEFI entries! I don't know why I didn't try that earlier.

    My workstation's BIOS is all fancy and let's you add custom entries, but it was easier to use MX's UEFI manager. I simply added a new entry to pmOS's BOOTX64.EFI. I still would like to boot it through my GRUB.

    Also thanks for the piece of info and all the interest in helping me so far :)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 1 point 1 week ago* (last edited 1 week ago) (2 children)

    Actually, here's the grub menu from MX, where pmOS entry was auto-generated.

    EDIT: corrected accidental duplication when pasting the config

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 week ago* (1 child)

    Ok, just to confirm I understand correctly:

    1. after power up you don't choose different UEFI entry, just wait for the regular (sda2) grub to come up. Same as when booting up MX
    2. you choose the option postmarketOS v26.06 (on /dev/sda7)
    3. then you get the error from the earlier photo?

    If all of that is correct, then:

    • it seems that some kernel starts fine and it's even Alpine. It's either reading the root partition or running the init that breaks
      you went with SysV or Systemd?
      • that ahci0,gpt6 6969-ACCE seems weird, though
        What are the UUIDs of your partitions?
      • looking at other example of rdinit -2, nothing else appears on the screen after the point you made picture of?
    • the kernel you want to run is on sda6 and is named vmlinuz-lts?
    • there is no initrd file in sda6?
    • I'm not sure if using /dev/sda7 isn't too early
      for a test replace dev/sda7 in line 249 with (hd0,gpt7)
      Ideally it should be partition's UUID like in the earlier entries but without the UUIDs from earlier point I don't know the string to pass to you
    • your sda6 is FAT, while sda7 is EXT. What happens if you add insmod ext2 after line 242?
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 1 week ago
      1. and 3. is all correct.

    I use systemd mode in MX. In pmOS's entries there is no such choice, unless... the 2 dublicate options in the "advanced options" GRUB entry is actually the dual init format specific to MX? Then we can assume this is an incompatibility on MX Linux's part? I guess I tried booting pmOS in both modes, but I don't see any difference. All the later tests bellow were done on the main pmOS GRUB entry, not in the "advanced options".

    The strangely named "6969" UUID is real, sda6's UUID is named like that, and I don't know why.

    All UIIDs in order:

    • EFI
      • 13AA-3B2E
    • OTHERS
      • 081de505-7ddd-482a-aff8-9403865510d7
      • 829c2c7a-d475-4692-bc78-d8502ded5d3b and LUKS e1bae6b2-c0b7-47de-bb88-3261cf0c83ba
      • 37e894b4-435c-4156-a923-7cfc27b6705f and LUKS f68c92ec-cade-4686-b467-70f4100c36e0
      • 0ba63eb1-ffa9-466c-ab2a-9b29db2882d2
    • PMOS
      • 6969-ACCE
      • 791e8d35-d7ec-46ed-9b53-a70a8beebe14

    The photo is exactly all the visible text on screen, and nothing else appears bellow the screen.

    There is no initrd in sda6, but there is vmlinuz-lts. In pmbootstrap I choose the Alpine LTS kernel, and I don't know if that's related to vmlinuz-lts's naming.

    (hd0,gpt7) did not fix anything regarding the line 249 edit.

    The line 242 edit produced, just bellow the rdinit error: Skipping autodetection of RAID arrays. (raid=autodetect will force). I later then reverted this edit and added sda7's UUID to line 249, replacing (hd0,gpt7), and it produces me same RAID array error.

  • permalink
  • fedilink
  • source
  • parent