Isoboot and btrfs fun

[oshunluvr]

I'm not sure I tried using a subvolume other than the ones used for / and /home, which would have been @_bionic and @home_bionic.

Note (mostly for the unwary stumbler to this thread) that for a one off that stanza is good, but the coding of (hd0,3) is fragile, grub may change its enumeration of storage on another boot.

Possibly true, but my last several mobo's and computers haven't had the "floating" drive IDs like in days past. IME, this was caused by USB drives being inserted prior to powering up and the system deciding they preceded the installed drives. Obviously, if you were booting to a thumb drive or USB drive, the installed version of GRUB wouldn't have any impact because you wouldn't bee booting from it anyway. Besides, you're going to have to explain how your "set root='hd3,msdos6' " differs in this regard from my " loopback loop (hd0,3)". Aren't they exactly the same thing stated on different lines or did I miss something?

Anyway, mostly I was commenting on the fact that I have, without problem or complexity, been able to boot to an ISO and install from it to the same hard drive and same btrfs file system without any problems. When you get the "other drives are mounted..." message, just continue without attempting to unmount them. I've never had a problem.

[oshunluvr]

"Persistence" in this reference means allows you to have storage along with a USB installation, not booting from any ISO. They are totally separate things. AFAIK, there's no such thing as booting from an ISO and having persistence. Persistence is available with some distros (Ubuntu variants support this) when installing an ISO image to a USB thumb drive. Alternately, you can format and install GRUB to a USB thumb drive and use it like any hard drive. I think the need for persistence came from the days when thumb drives were small capacity and not cheap.

As far as having additional storage available - any boot methodology would allow you to mount another device to access or store files, but the mounted connection would not survive a reboot without persistence.

[jlittle]

But I'm afraid you cannot have a persistent system when you boot from .iso, or am I wrong?

Not persistent in the sense of updating it, installing software, and so on. But the term "persistent" is sometimes used to mean having some storage where you can stash stuff, and if you boot from an iso you can mount some place, like a USB stick or the storage where the iso is and stash stuff there.

Or, use the iso to install into the btrfs I mentioned in the thread title. Booting from the iso on my SSD and installing on to that SSD took me 7 minutes, from reboot to "install complete".

[nicrnicr]

Thank you very much oshunluvr & jlitlle.

But I'm afraid you cannot have a persistent system when you boot from .iso, or am I wrong?

[jlittle]

Hmm, this works for me without issue;

From a single BTRFS file system, booting grub from a stand-alone subvolume, using the stanza below, I have booted to the ISO and installed from it to the same BTRFS file system.

[FONT=monospace][COLOR=#000000]menuentry 'KDEneon ISO' {[/COLOR]
  set isofile="/@grub/neon-useredition-amd64.iso"
  loopback loop (hd0,3)$isofile
  linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
  initrd (loop)/casper/initrd.lz
}
[/FONT]

The ISO itself is in the @grub subvolume.

I'm not sure I tried using a subvolume other than the ones used for / and /home, which would have been @_bionic and @home_bionic.

Note (mostly for the unwary stumbler to this thread) that for a one off that stanza is good, but the coding of (hd0,3) is fragile, grub may change its enumeration of storage on another boot.

[oshunluvr]

Hmm, this works for me without issue;

From a single BTRFS file system, booting grub from a stand-alone subvolume, using the stanza below, I have booted to the ISO and installed from it to the same BTRFS file system.

[FONT=monospace][COLOR=#000000]menuentry 'KDEneon ISO' {[/COLOR]
    set isofile="/@grub/neon-useredition-amd64.iso"
    loopback loop (hd0,3)$isofile
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
    initrd (loop)/casper/initrd.lz
}
[/FONT]

The ISO itself is in the @grub subvolume.

[nicrnicr]

Thank you very much jlittle for this information:
"I found the right search term. I've just installed cosmic into my main btrfs SSD after booting from an iso in a bionic subvolume on that SSD; it's unnecessary to copy the iso anywhere. This is the grub entry I used:

menuentry "Kubuntu iso" {
set isofile="/@home_bionic/john/downloads/iso/cosmic-desktop-amd64.iso"
set root='hd3,msdos6'
search --no-floppy --set=root --label "main"
loopback loop ($root)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=${isofile} noprompt noeject toram
initrd (loop)/casper/initrd
}

Note the "toram" option. To use this you'd want to adjust the path to the iso, and the label of where the iso is, or use the UUID with --fs-uuid instead of --label.

Then, before starting ubiquity -b, the magic incantation in a konsole is sudo umount -l -r -f /isodevice. Of course, one needs to do a "manual" install and be very careful about where the install is to go, especially that the format checkbox is not ticked."

But I don't understand very well, what is where installed, in order to do what? In which on system, should we write this in terminal?

[jlittle]

I found the right search term. I've just installed cosmic into my main btrfs SSD after booting from an iso in a bionic subvolume on that SSD; it's unnecessary to copy the iso anywhere. This is the grub entry I used:

menuentry "Kubuntu iso" {
set isofile="/@home_bionic/john/downloads/iso/cosmic-desktop-amd64.iso"
set root='hd3,msdos6'
search --no-floppy --set=root --label "main"
loopback loop ($root)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=${isofile} noprompt noeject toram
initrd (loop)/casper/initrd
}

Note the "toram" option. To use this you'd want to adjust the path to the iso, and the label of where the iso is, or use the UUID with --fs-uuid instead of --label.

Then, before starting ubiquity -b, the magic incantation in a konsole is sudo umount -l -r -f /isodevice. Of course, one needs to do a "manual" install and be very careful about where the install is to go, especially that the format checkbox is not ticked.

[jlittle]

you can put the .ISO on a removable drive or usb stick and still boot it that way , just sayin

Writing to USB sticks can be slow and error-prone, and just copying to a removable drive has pitfalls. Removable drives with SSD performance are not much of a thing yet.

[GreyGeek]

mkusb allows one to create a persistent USB stick of Kubuntu. I keep one in my watch pocket for those times when I may need to boot someone's computer.

[vinnywright]

you can put the .ISO on a removable drive or usb stick and still boot it that way , just sayin

VINNY

[jglen490]

Y'all are just into pain and inconvenience

[jlittle]

Wanting to test out the Cosmic final release, stumbling about, I found my way into the practice of booting from iso files directly, as documented in Grub2/ISOBoot.

There was a thread about this on KFN in 2015, but I missed its relevance at the time, and there's been many posts about how to write bootable USB sticks since then. As a newbie fixated on a new hammer, I can't imagine why anyone goes to the bother of writing sticks.

Anyway... the instructions say

The isodevice must be unmounted for a successful installation. If isodevice cannot be unmounted by the installer, the installation will fail unless the user forces its unmounting.

but I thought with btrfs, installing into subvolumes, it won't be necessary to unmount the device the install system is running from, so long as it's not @ and @home.

Nope. Ubiquity noticed the device was in use, and gave a warning about it, but let me continue if I installed to another partition, but then froze and got nowhere.