4 ms·

[Edit 2] where you put grub/grub.cfg in the above partition layout is also up to you. It could reside on the EFI parition. Its all about how you lay it out in t

by drvdevd 10y ago

[Edit 2] where you put grub/grub.cfg in the above partition layout is also up to you. It could reside on the EFI parition. Its all about how you lay it out in the host system when putting this disk together and then how you run grub-install

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
Bluescreens 10y ago
I'm... not following a 100%. But getting there. Its frustrating to feel like your 98% there, and just missing the one thing :/. My setup right now _is_: (hd0,gpt1): ESP - /boot/grub/grub.cfg - /boot/{i386-pc,locale,x86_64-efi} - /EFI/BOOT/BOOTx64.EFI (hd0,gpt2): ext4 - ubuntu-16.04.bla.iso - custom.iso I don't see the difference in grub.cfg(appart from 14/16, that was mb, I tried both 14/16 standard isos :D), and indeed its location doesn't matter as this works for the default live cd/it does seem to find the things inside the custom.iso/casper. ------------------------------------ And I totally agree with the part regarding the Casper scripts ;). I tried the following: - mount default 16.04 iso - take out its vmlinux.efi & initrd.lz - put it in the casper/ folder of the custom.iso This booted! :). And then it hang on the 'not enough loop devices' error from the post below. :( So I tried grabbing either the vmlinuz-LATEST_VERSION and the vmlinuz-LATEST_VERSION.efi.signed for the vmlinuz.efi in the casper/ (with corresponding initrd.lz), but those crashed even earlier. Just "error: no suitable video mode found. booting in blind mode", which is not the actual critical error, as the default 16.04 proclaims this as well, and then proceeds to boot properly in blind mode. Can't really seem to figure out how far the custom version got... You happen to know of a listing of sorts regarding the required Casper files? I just get some general stuff. It really seems to indeed hinge around those vmlinuz.efi and initrd.lz files. The naming convention with the .efi and .lz shouldn't even matter that much, as long as the grub entry matches it. But those _are_ the images the host OS is booting from. Do they have some internal pathing/referencing I'm missing? Something that keeps staring at me though is the /grub and /EFI inside the .iso. The iso basically has: - boot/grub - casper - EFI/BOOT/{BOOTx64.EFI,grubx64.efi} But I'm not too trusting of the grub.cfg inside the iso... menuentry "Boot custom iso" { set gfxpayload=keep linux /casper/vmlinuz.efi boot=casper quiet splash -- initrd /casper/initrd.lz } I do think I need it, but does it need more references than this? Should it also have the (hd0,2)etc. prepending? Or is this OK as it is a selfreference within the iso? Thanks for the help so far, its already comforting to know that someone else suspects the same area for the issues :). I swear this is going to drive me properly mad one of these days.
- drvdevd 10y ago
  You're welcome! I definitely think this is an internal pathing issue relative to the ISO -- and I have grappled with this same stuff before many times and gone mad several times over so I get it :) I just found a nice reference that I remember using when working with Ubuntu ISOs before at https://help.ubuntu.com/community/LiveCDCustomizationFromScratch https://help.ubuntu.com/community/LiveCDCustomizationFromScr... It may be outdated and you may have already seen it, but the key point is the section "Install Packages Needed For Live System": > apt-get install --yes ubuntu-standard casper lupin-casper > apt-get install --yes discover laptop-detect os-prober > apt-get install --yes linux-generic Since they're building the ISO from scratch using debootstrap and a chroot, some scripts in the casper package will probably set up paths, grub, etc, all relative to the current root (the chroot they're working in). This would also probably explain why using a vmlinuz.efi and initrd.lz from a default 16.04 iso kinda worked for you -- because some paths and versions match up, etc. Long story short: you should try following that guide to some extent when packing up the custom.iso (unpack, install casper package(s) in a chroot, repack), then find a way to use grub on your ESP to "chainload" [1] the iso from the second partition. HTH, I'll check back later and see if you had any luck :) [1] https://wiki.gentoo.org/wiki/GRUB2/Chainloading#ISO_images https://wiki.gentoo.org/wiki/GRUB2/Chainloading#ISO_images
  - Bluescreens 10y ago
    Sounds reasonable and looks interesting ^^. Will take a look at it first thing tomorrow ;).
  - Bluescreens 10y ago
    Sorry for the late reply, had to work through a few iterations... But it works now ^^. Turns out the issue was not really in the grub and or initrd/vmlinuz... I worked through your LiveCD guide, but did not en up with a working iso in the end :(. However, it did remind me of this guide: https://help.ubuntu.com/community/MakeALiveCD/DVD/BootableFlashFromHarddiskInstall https://help.ubuntu.com/community/MakeALiveCD/DVD/BootableFl... on which distroshare is based. Running through the original guide resulted in a bootable iso. After checking, none of my previous homegrown isos were ever bootable on their own :O!. Apparently the level of black-magic in Unetbootin was greater then I had anticipated. Best part of all, that iso is created on a non-EFI machine, and boots in EFI-mode just fine due to the grub-install --target=x86_64-efi on the bootstick. Everything else is just loaded over the original EFI-modules apparently. So no need to completely revamp all of my old code, just need to take a looksy into the iso generation part (used mkisofs instead of grub-mkrescue in my old scripts because of >4GB fat32 issues). Thanks for all the help and interest man. It really kept me (mostly) sane ;)!

by drvdevd 10y ago

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

Bluescreens 10y ago

I'm... not following a 100%. But getting there. Its frustrating to feel like your 98% there, and just missing the one thing :/. My setup right now _is_: (hd0,gpt1): ESP - /boot/grub/grub.cfg - /boot/{i386-pc,locale,x86_64-efi} - /EFI/BOOT/BOOTx64.EFI (hd0,gpt2): ext4 - ubuntu-16.04.bla.iso - custom.iso I don't see the difference in grub.cfg(appart from 14/16, that was mb, I tried both 14/16 standard isos :D), and indeed its location doesn't matter as this works for the default live cd/it does seem to find the things inside the custom.iso/casper. ------------------------------------ And I totally agree with the part regarding the Casper scripts ;). I tried the following: - mount default 16.04 iso - take out its vmlinux.efi & initrd.lz - put it in the casper/ folder of the custom.iso This booted! :). And then it hang on the 'not enough loop devices' error from the post below. :( So I tried grabbing either the vmlinuz-LATEST_VERSION and the vmlinuz-LATEST_VERSION.efi.signed for the vmlinuz.efi in the casper/ (with corresponding initrd.lz), but those crashed even earlier. Just "error: no suitable video mode found. booting in blind mode", which is not the actual critical error, as the default 16.04 proclaims this as well, and then proceeds to boot properly in blind mode. Can't really seem to figure out how far the custom version got... You happen to know of a listing of sorts regarding the required Casper files? I just get some general stuff. It really seems to indeed hinge around those vmlinuz.efi and initrd.lz files. The naming convention with the .efi and .lz shouldn't even matter that much, as long as the grub entry matches it. But those _are_ the images the host OS is booting from. Do they have some internal pathing/referencing I'm missing? Something that keeps staring at me though is the /grub and /EFI inside the .iso. The iso basically has: - boot/grub - casper - EFI/BOOT/{BOOTx64.EFI,grubx64.efi} But I'm not too trusting of the grub.cfg inside the iso... menuentry "Boot custom iso" { set gfxpayload=keep linux /casper/vmlinuz.efi boot=casper quiet splash -- initrd /casper/initrd.lz } I do think I need it, but does it need more references than this? Should it also have the (hd0,2)etc. prepending? Or is this OK as it is a selfreference within the iso? Thanks for the help so far, its already comforting to know that someone else suspects the same area for the issues :). I swear this is going to drive me properly mad one of these days.

drvdevd 10y ago
You're welcome! I definitely think this is an internal pathing issue relative to the ISO -- and I have grappled with this same stuff before many times and gone mad several times over so I get it :) I just found a nice reference that I remember using when working with Ubuntu ISOs before at https://help.ubuntu.com/community/LiveCDCustomizationFromScratch https://help.ubuntu.com/community/LiveCDCustomizationFromScr... It may be outdated and you may have already seen it, but the key point is the section "Install Packages Needed For Live System": > apt-get install --yes ubuntu-standard casper lupin-casper > apt-get install --yes discover laptop-detect os-prober > apt-get install --yes linux-generic Since they're building the ISO from scratch using debootstrap and a chroot, some scripts in the casper package will probably set up paths, grub, etc, all relative to the current root (the chroot they're working in). This would also probably explain why using a vmlinuz.efi and initrd.lz from a default 16.04 iso kinda worked for you -- because some paths and versions match up, etc. Long story short: you should try following that guide to some extent when packing up the custom.iso (unpack, install casper package(s) in a chroot, repack), then find a way to use grub on your ESP to "chainload" [1] the iso from the second partition. HTH, I'll check back later and see if you had any luck :) [1] https://wiki.gentoo.org/wiki/GRUB2/Chainloading#ISO_images https://wiki.gentoo.org/wiki/GRUB2/Chainloading#ISO_images
- Bluescreens 10y ago
  Sounds reasonable and looks interesting ^^. Will take a look at it first thing tomorrow ;).
- Bluescreens 10y ago
  Sorry for the late reply, had to work through a few iterations... But it works now ^^. Turns out the issue was not really in the grub and or initrd/vmlinuz... I worked through your LiveCD guide, but did not en up with a working iso in the end :(. However, it did remind me of this guide: https://help.ubuntu.com/community/MakeALiveCD/DVD/BootableFlashFromHarddiskInstall https://help.ubuntu.com/community/MakeALiveCD/DVD/BootableFl... on which distroshare is based. Running through the original guide resulted in a bootable iso. After checking, none of my previous homegrown isos were ever bootable on their own :O!. Apparently the level of black-magic in Unetbootin was greater then I had anticipated. Best part of all, that iso is created on a non-EFI machine, and boots in EFI-mode just fine due to the grub-install --target=x86_64-efi on the bootstick. Everything else is just loaded over the original EFI-modules apparently. So no need to completely revamp all of my old code, just need to take a looksy into the iso generation part (used mkisofs instead of grub-mkrescue in my old scripts because of >4GB fat32 issues). Thanks for all the help and interest man. It really kept me (mostly) sane ;)!