Instead of writing to DVD or USB device, I find it easier to install to a new partition using loopback. I’ve been doing it, and the following was similar to what I used with 15.6. But when I try to install 16.0, it loads some things, but then drops to the command prompt saying a problem, similar to what some experienced using Ventoy. But I’m using loopback. Are there different parameters needed for 16.0? Checksum checked out.
menuentry "Leap-16.0-offline-installer-x86_64-Build171.1 ISO install" {
set isofile="/path-to-LinuxISO/Leap-16.0-offline-installer-x86_64-Build171.1.install.iso"
set root=(hd0,gpt7)
loopback loop $isofile
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile nosplash showopts
initrd (loop)/boot/x86_64/loader/initrd
}
.iso on the NVME I started my one and only fresh 16.0 installation from:
# ls -gGh aga*
-rw-r--r-- 2 688M Oct 10 13:27 agama-installer.iso
-rw-r--r-- 2 688M Oct 10 13:27 agama-installer.x86_64-17.0.0-openSUSE-Build2.14.iso
#
Gist of Grub stanza used to start Agama:
insmod part_gpt
insmod ext2
set isofile=/agama-installer.iso
set root=(hd1,gpt6)
loopback loop $isofile
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile rd.live.image verbose iso-scan/filename=$isofile plymouth=0…
Note above I was only loading the 688M NET installation .iso, when I discovered if the .iso file is on the same HDD, SSD or NVME containing the target space for installation, the installer will act like the device doesn’t exist. The here omitted (…) linu line options were all valid linuxrc/old installer parameters, including video=, ifcfg=, hostname=, etc. IIRC all of them actually got applied.
Workaround: boot to multi-user.target, umount whatever filesystem(s) on the target device that you find are mounted, then switch to graphical.target to let installer initialize with your target device available.
I had seen one of the posts, but did not understand what you were meaning. The slash in a parameter seemed confusing to me, but now I understand.
Looking at another one about dracut help and I’m reminded ‘=’ in parameters with LABEL and UUID? I looked up the word dracut because I’ve seen it through the boot process and didn’t know what that meant. Named after some city. Also Wayland, and… Not too useful naming conventions…
Guess dracut means, help booting.
Thank you. I had tried to use Agama, but when it gave the error, I figured it must have some other parameters and since I didn’t really understand what it did, I gave up. What does rd.live.image do?
I don’t understand the multi-user.target part, but probably don’t need to for my purposes. Is acting like the device doesn’t exist a bug? If I had a different disk instead of a different partition would it have been okay? I really have not understood the boot process and thought target space for installation wasn’t decided until chosen once the install program asks you. Maybe you are talking about something else than that.
Targets are part of systemd managed operating system booting. Think of targets like stages on a rocket, except there are many, not just two or three. One finishes, after which the next starts, but Leap installation due to this intervention pauses after reaching multi-user.target instead of continuing on to the last, graphical.target, which starts the GUI, in which the installation application program itself runs in a Firefox web browser. I paused the boot process, via an added linux kernel boot parameter, in order to perform an administrative task that avoided a known “bug”, umounted the target disk, then continued the boot process by switching on the final stage, graphical.target, using command systemctl isolate graphical.target.
I would consider it a bug, but it is likely just that Agama’s capabilities don’t measure up to its predecessor’s yet. I expect that obstacle will disappear before 16.1 is released, if it hasn’t already.
As long as nothing else on that other disk is required for your installation to proceed as desired, I would expect yes.
All target space allocation can be done 100% in advance of starting Leap’s retired installer, and installers of various other operating systems. As a multi- multibooter, I am in strict habit of doing exactly that. All I need an installer’s partitioner to do is let me specify which existing filesystems need to get mounted where. Less experienced users can’t be expected to know how or why to partition, much less how to decide on optimal space allocation, so the installer must be setup to default to doing such things without an unclueful user needing to know. Connecting those diverse needs and others together in a well working installation program obviously takes programming effort that is short of perfection in 16.0’s Agama version.
Ah. Just because I discovered partitions doesn’t mean everyone else has. I forget that, and that the installation may assume most users are using their whole disk. I feel I need to know more about all this, but guess I’m less experienced about the target space. I found something about multi-user.target that said it was analogous to what used to be runlevels. I remember that and thought those still existed.
And I may need to learn more specifics about this multi-user.target that you do as I when I changed the install parameters, I get a list of things, dracut said finished, then I get waiting for a job to complete, and it doesn’t. Something about /dev/gpt-auto-root start job. It happens both on the following and my modified Agma entry.
menuentry "Leap-16.0-offline-installer-x86_64-Build171.1 ISO install" {
set isofile="/path-to-LinuxISO/Leap-16.0-offline-installer-x86_64-Build171.1.install.iso"
set root=(hd0,gpt7)
loopback loop $isofile
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile iso-scan/filename=$isofile verbose nosplash showopts
initrd (loop)/boot/x86_64/loader/initrd
}
Runlevels have functional equivalents now, with 3 equating to multi-user.target and 5 equating to graphical.target. Thus to avoid graphical.target from being directly reached, in order to apply some setup maintenance first, one may simply strike E key at the boot menu, append 3 to the linu line, instead of the new way, appending systemd.unit=multi-user.target, then proceed with boot to text mode login prompt.
As already indicated, I’ve only done Agama to completion once. My experience has been with the now replaced installer and linuxrc in alphas, betas and GAs of previous releases and TW, where the only files needed locally to start an installation were linux and initrd. As I’ve gathered since, that still may be true, but yet to be tried here. Agama is new, and I’ve spent little time with it, guided by a few bits here and there by (mostly) @arvidjaar when I asked for help.
Why that start job thing happened to you I don’t know. The linu line in my first comment here was limited to necessary bits for a normal startup, and not a match for the actual boot that succeeded. I left my boot stanza in /boot/grub2/custom.cfg untouched, and when boot menu appeared, I struck the E key, appended <spacebar> 3 to the linu line, then F10 to boot to multi-user.target shell prompt.
I’m learning more! Too much to remember during boot when I don’t have access to my note files. But I can remember the “3”. And then maybe the systemctl isolate graphical.target. I’ll give it a try.
Is there a way, and do you think it might be helpful to use chainloader to the isofile? Things have changed and I no longer know how to use chainloader.
I have no idea how chainloader might be anything more than a complication. Booting with 3 was simply a way to avoid an issue with the partitioner that worked. Agama runs on an extensively functional openSUSE operating system that from what I have been able to tell so far includes many if not most or all cmdline tools that facilitate common system administration tasks.
I tried appending “3” on the linux line and also “systemd.unit=multi-user.target”, but still get the waiting for starting job /dev/gpt-auto-root. It counts down for a minute and a half, then redoes some steps and waits again. Guess I’ll have to make an USB stick.
Most I pasted above was facilitated by having current TW version of systemd-networkd rpm in same location as build 9.20 .iso, rpm installing it from tty8 (where root shell is active/ready), configuring and starting systemd-networkd.service, so that I could redirect output to a file on my LAN server for copy and paste here.
or when it goes in the job wait cycling on install? I do not know how to enter any commands. I figured out that by pressing Alt+SysRq then Ctrl, it gives some options, but “Crash” is the only thing I accomplished.
I have no idea which one is which. I requested the data from the system with /dev/gpt-auto-root. This should have been fairly obvious from the context.
I’m sorry, but it is not obvious to me how to enter the command,
“lsblk -o name,parttype”
during the install process when it is cycling through the waiting for the start job. I do not know how to get a prompt to enter commands.
Using a LAN server and tty8 as mrmazda did, is beyond my understanding and capabilities.
Sorry, if this is not exactly the same topic, but I have been trying to move boot to its own partion from root in sles16 without success, it worked fine in sles15, but now it seems to be hard to me to get that worked, has anyone succeeded with this?