Booting working linux image UEFI / PXE / GRUB

Question

I am trying to set up a server to boot opensuse-15.5 via PXE on an UEFI environment and GRUB2. I found this tutorial for Suse that worked quite well. I've got a client getting an IP address, downloading few files from the TFTP on the same machine, and I also have a NFS server set up.

The issue is, every tutorial I found seems focus on installing a new OS in the client, and that is not what I need. What I do need, is for a very basic, minimalist OS to be loaded in order to be able to run few commands from the terminal. Nothing else. I don't need to load a Live image or run an installer.

Following the instructions in the tutorial I get to the point where the client fails connecting to the repositories to start installing the OS. What I did after that, was to replace the initrd and linux images for those I got from an OS installation in the same client I am trying to boot. Also, I made an image of the root file system in the client (the same installation) and placed it in the server, in order to make it accessible through NFS. After this, the result was that the client loaded initrd, then linux, but it stopped before finishing at a point where it's (probably) trying to set up the graphics card. The line mentions drm and i915 (Apologies, I don't have the client in front of me right now but I will update with the right message tomorrow).

I am not even sure of the linux image I have to load and the parameters I have to pass to GRUB in order to make it all work. I've been trying to understand from the GRUB's manual and other sources, but I've got more questions than certainties. Can anybody tell me...: which commands should I add to grub.cfg (and which ones should I get rid of)? which linux image should I use? and probably any source of information that come to mind?

Thanks very much for your time.

Gabs.

EDIT: The crashing point had nothing to do with graphics/drm/i915. The last message displayed (for about a minute) would show graphics/drm/i915 but the issue would actually be immediately after that, at dracut initqueue hook. As far as I understand, it would somehow start to look for a memory stick that was mounted and included in fstab at the moment of making the image of the root partition with dd.

After remaking the image (and sending it to the server via NFS this time), I can see that issue is sorted (see picture)

The issue now, as seen in the next picture, is at switch root stage. Which I really don't know the meaning of but I'll do some research about.

The next picture is net/grub.cfg. I edited this file and got rid of the install and instsys commands because I thought they were irrelevant (as I am not trying to install an OS). I also tried this grub.cfg without the root and nfsroot commands which (according to my understanding) would use the file system in the hard drive, instead of the one in the server, and the whole set up seems to work. It is only when it needs to get the root file system from the NFS server that I've got the error in the second picture. Apologies, the 3rd picture is blurry.

At this point in time, I imagine there is something wrong with the file system. I made the image with dd, moved it to the server, and mount it with mount -o loop /image /srv/tftpboot/openSUSE-XXX/rootfs. I read it's not the same to image a partition as to image a whole disk. Also, that btrfs is somehow special in regards to imaging. Is there a particular way to do this? Apologies for the delay to update. Thanks again for your help and time to comment.

Answer 1

The Linux kernel is up and running, so GRUB's job is done. The next step is for the kernel and whatever tools & scripts are included in the initrd/initramfs file to mount the actual root filesystem and transition the kernel to using it.

You have specified kernel boot parameters for NFS root:

root=/dev/nfs nfsroot=192.168.20.1:openSUSE-Leap-15.5-x86_64/rootfs

That would mean the 192.168.20.1 system would have to have a valid root directory structure exported for sharing over NFS. If using NFSv4, it probably would have to be under /srv, e.g. at /srv/openSuSE-Leap-15.5-x86_64/rootfs/, unless you have configured NFSv4 sharing in a non-default way. With NFSv3, it would have to be literally at /openSuSE-Leap-15.5-x86_64/rootfs/ and exported as such in /etc/exports.

Basically, you should be able to mount it for testing/verification with

mount 192.168.20.1:openSUSE-Leap-15.5-x86_64/rootfs /mnt

from any Linux or other modern unix-like computer that is allowed to mount that NFS share (as dictated by options at /etc/exports on host 192.168.20.1). After successfully running that command, you should see directories like /mnt/bin/, /mnt/lib/, /mnt/sbin/, /mnt/usr/ and /mnt/var/ with the expected contents. There should also be empty directories at /mnt/dev/, /mnt/proc/ and /mnt/sys/, ready to act as mount points for virtual devtmpfs, procfs and sysfs filesystems, respectively.

If you've stripped down the directory tree, the standard SuSE initramfs/initrd would attempt to run /usr/lib/systemd/systemd after switching to the real root filesystem, which would in your case be that NFS share. So, if you ran that test mount command listed above, then /mnt/usr/lib/systemd/systemd had better be there, or else the transition to the NFS-mounted root filesystem would fail pretty much exactly like it's doing for you now.

But you've actually mounted the filesystem image to /srv/tftpboot/openSUSE-XXX/rootfs, so your /etc/exports would need to have an entry like:

/srv/tftpboot/openSUSE-XXX/rootfs    *(rw,no_root_squash)

You would have to run exportfs -a to make it effective.

Then, your nfsroot= option should be:

nfsroot=192.168.20.1:/srv/tftpboot/openSUSE-XXX/rootfs

and the test mount command, respectively:

mount 192.168.20.1:/srv/tftpboot/openSUSE-XXX/rootfs /mnt

As the root filesystem will be accessed over the network using the NFS protocol, the type of the actual underlying filesystem (btrfs or whatever) at the NFS server is essentially irrelevant, as long as it supports Unix-style file ownerships and permissions.

---

By the way, please don't post pictures of text when you can avoid it. With your first two pictures it's somewhat excusable as capturing the boot output in text form can be difficult unless you're already familiar with serial consoles. But with your third picture, that excuse won't apply.

We have several very knowledgeable people here with sight issues that make pictures of text either difficult to read or completely useless for them. By posting pictures of text, you both opt out of receiving their advice, and make your post less useful to other readers with sight issues.

Answer 2

I'm not going to get into details because there are things I really don't get to understand. But I'll try to explain what I did to make it work, and probably provide some guidance to anybody facing the same problem.

In the first place, it is important to establish whether it is going to be PXE over BIOS or UEFI. As far as I understand, -and strictly speaking-, the latter doesn't really exist or it is really called differently. For a person without the knowledge, articles on internet can be misleading to this regard. In my case, the boot loader is GRUB. And depending on whether you are actually on BIOS or UEFI, not only the files GRUB needs are different, but also are the directory structures, names and files extensions.

SUSE / OpenSUSE has few tutorials and packages that make the configuration of the server pretty straightforward. The issue arises when you need to decide what type of booting you need. Most tutorials I found are focused on booting for the purposes of installing an OS, but if what you need is just to boot a diskless machine -probably just to run few commands- you won't be interested in the system running an installer once it has finished loading the OS. This was my case.

Once you're able to call GRUB the tricky parts are two:

• First, you need to find a kernel image, initrd and root filesystem that work together. My mistake was to believe that simply copying the first two from a working installation, and make an image of the root filesystem (in the same installation) to be mounted via NFS, should be enough to boot via network. It wasn't.

• Second, what parameters need to be passed to the kernel when loaded from GRUB.

Solution: As I mention before, deciding exactly what type of system you want to boot is paramount. Understanding the differences among the different options is a must. From SUSE's documentation website, KIWI-NG is a piece of software that makes the creation of kernel image, initrd and root filesystem quite easy in just few steps. It uses one XML file to configure the building process. The docs are very well explained and up-to-date. From there, is pretty easy to figure out exactly the type of system you need and how to create it. There are also few examples already configured and ready to be built. The result of the building process is a filesystem of the chosen type, containing all you need to boot via network. Kernel and initrd included. Since KIWI-NG uses Dracut to create the initrd, there are some parameters of the dracut's command line to be added to the kernel line in GRUB. This depends on the type of system you are trying to boot. I advise on reading a bit of Dracut but not have it as a reference. The options I needed I found them on a forum, as I found difficult to understand Dracut's documentation.

Mi final setup is as follows:

• DHCP server: option 93, next-server and filename options in dhcpd.conf (apart from all the minimum requirements to set up a DHCP server).
• TFTP server: To download boot loader files. In my case, bootx64.efi and grub.cfg. Kernel, initrd and root filesystem ARE ALSO loaded from TFTP server -at least with my configuration-. There is an option to load the filesystem via ATA over Ethernet but I didn't use it.

Best of luck and happy (long) readings :)