some curious menuentry ordering

[a-schaefers]

$ ls /boot/vmlinuz*

vmlinuz-4.18.20-gentoo  vmlinuz-4.18.20-gentoo.old  vmlinuz-4.19.4-gentoo  vmlinuz-4.19.4-gentoo.old

Notice, the ".old" entry appears above the most current kernel on the list.

Also, one last thing while I'm here, what purpose do the menuentries without kernel versions serve?

Only minor quibbles.

Thank you.

[johnramsden]

The menus without the kernel versions are the 'default' configurations, whereas the ones with the name are the 'advanced' ones. It was what was done in 10_linux, so I just continued on with having the two configurations, I tried to follow their generator as close as possible. Do you find them a bit too overwhelming when having a lot of boot environments?

The other thing is you have a bit more of a customized configuration then I would usually use, and as a result have the .old entries as well as multiple kernels in the one directory. As a result you end up with more entries.

My test arch VM looks like this for example.

---  ---

If you find it a bit much I could see what I could do to add another configuration flag to zedenv-grub, which would allow you to specify not to list the advanced configurations, (or the other way around)? I could also sort them list old entries after everything else. What exactly is the purpose of the `old` entries anyway? Are they essentially backups of your last kernel? Maybe they aren't necessary with boot environments since you can just boot into an old one? Just a thought. If you don't like seeing the `.old` entries in there I could exclude them as well, what do you think? Happy to hear any thoughts on design choices.

[a-schaefers]

The .old entries are expected, they are in my /boot , therefore they should appear.

The problem is the first ".old" entry appears in position "0" (top of the list) when it should be below the the entry without ".old". And if you look closely, the second kernel version, 4.18.20, got this correct, and is displaying a different behavior (the ".old" entry is at the bottom.)

Regarding the menuentry without the kernel version, I assumed it was 10_linux actually, and was baffled at how it appeared since I had already chmod -x 10_linux. Maybe there could be a way for us to turn off this feature? ;-)

[johnramsden]

So preference would be the ability to disable the simple entries, and order the old entries after the regular ones?

[a-schaefers]

So preference would be the ability to disable the simple entries, and order the old entries after the regular ones?

I would say so, we need to do our best to keep menuentries ordered alpha numerically and at least in a predictable way, for servers and headless situations, so that a sysadmin can easily edit his /etc/default/grub and specify which menuentry should load by default, and that being most often "0" which I believe should always be the newest menuentry.

Ability to disable the "simple" (non-kernel version in title) entries is not mandatory, they are fine, I suppose, it only feels a bit overly redundant, but it's less important and more for aesthetics that I desire that.

[a-schaefers]

I am concerned this maybe should be classified "bug." I have started using only one kernel version at a time as you do, so am unaffected, but I'm worried about people who have more than one kernel around (e.g. on redhat or ubuntu/debian)-- maybe they will not always have the most recent kernel version appear at the top in position 0 of the grub menu, which could lead to confusion or unreliable situations.

As it is, I am not sure, if the newest kernel version is consistently always at the top. I think it usually is, but I'm not sure with the naming conventions of other distros, and how exactly the python generation of the menu works.

Thoughts?

[johnramsden]

Right now the activated boot environment should be the default, so the behavior should be fairly consistent. If you notice otherwise please let me know.

This is still on my list of things to fix.

[a-schaefers]

Right now the activated boot environment should be the default, so the behavior should be fairly consistent. If you notice otherwise please let me know.

This is still on my list of things to fix.

Awesome, and don't get me wrong, zedenv is the greatest thing for zfsonlinux since sliced bread. :)

[johnramsden]

@a-schaefers I haven't had time to test it yet but, if you feel like trying it I have started a little bit of work on it johnramsden/zedenv-grub/sortedentries. I'm not sure how it's going to treat the suffixes yet, but at least it will always sort plain old version numbers correctly.

[a-schaefers]

I will try to get to this soon for testing

[johnramsden]

I will try to get to this soon for testing

I actually got around to testing and it's got some issues, so don't worry about it for now. I'll let you know when I get it in a state where I'm ready for some feedback.

[johnramsden]

I'm now actually questioning whether it makes since to do any ordering. Other than for appearance I'm not sure if there's any functional reason. The active boot environment should always be the default, so you can get a deterministic boot by activating a BE. I wouldn't say no to a contribution if someone wanted to write the code, but looking at it there are a bunch of side cases that need to be dealt with when it comes to ordering.

I will however add a flag so that the simple entries can be disabled, but other than that I think I'm going to leave the ordering for now.

[a-schaefers]

My worry is that many boot environments contain multiple kernel versions, especially enterprise distributions, and while it is predictable which boot environment loads, it is apparently unpredictable which kernel version in the boot environment will be loaded-- atleast in my tests as shown in my original screen shot.

Edit: and when I say "it is apparently unpredictable which kernel version in the boot environment will be loaded", I am referring to in position 0 of the grub menu. Not all sysadmins have IPMI, so for example, they could select which menuentry to load using the /etc/grub/default variable:

GRUB_DEFAULT=0 or GRUB_DEFAULT=1

etc...

Or perhaps I am missing a piece of how this all works?

[a-schaefers]

For example if my boss were to require, "the newest kernel version of each boot environment must always be in position zero (GRUB_DEFAULT=0)" I am not sure zedenv autogenerated grub.cfg's would meet this requirement.

Again, If i'm misunderstanding the issue, apologies.

[johnramsden]

Oh I see what you mean. I guess we do need a way of specifying which kernel version. Or at least making sure the most recent one is at the top. I was thinking more in terms of boot environments.

[a-schaefers]

Now the funny thing is that sometimes the most recent one does appear at the top-- just.not.always. I am not sure what exactly is going on / how this works within the python. :yum:

[johnramsden]

@a-schaefers So I think I've got the ordering sorted out. Since I don't really have a machine with numbered kernels I just made copies of my existing one named as yours are above. If you don't mind testing https://github.com/johnramsden/zedenv-grub/commit/dfc8dd0b046d35a1af4d8c35a71ded2ee0aed3f1 on a real machine that would be great, but I think it does what you are looking for.

It sticks any .old or .bak entries at the end.

I also added the org.zedenv.grub:simpleentries property which can be set to no in order to disable the simple entries.

[a-schaefers]

That sounds really nice, I'll try to get to this tonight and tomorrow. I'd like to do testing not only on my gentoo, but also on ubuntu boot environments--which I do not have setup yet.

[a-schaefers]

Hi, I ended up using some dummy entries, too. Regretfully I did use an overly complicated test, but I do have useful results:

This test used ubuntu entries, gentoo entries from genkernel, and gentoo entries from "make install".

If you want to test with the entries in question that I used, here's a list I used with "touch" to put dummy entries in /boot

(chroot) root@e6430 /boot # ls -l /boot
total 20434
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.17.1-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.17.2-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.17.3-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.17.5-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.18.1-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.18.2-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.18.3-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.18.5-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.19.1-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.19.2-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.19.3-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.19.4-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initramfs-genkernel-x86_64-4.19.5-gentoo
-rw-r--r-- 1 root root 5192860 Dec 14 12:42 initramfs-genkernel-x86_64-4.19.9-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 initrd.img-4.15.0-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 initrd.img-4.15.1-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 initrd.img-4.15.2-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 initrd.img-4.15.3-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 initrd.img-4.15.4-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 initrd.img-4.15.5-42-generic
-rw-r--r-- 1 root root 5241856 Dec 10 17:45 intel-uc.img
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.1-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.1-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.2-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.2-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.3-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.3-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.4-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.4-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.5-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.5-gentoo.bak
-rw-r--r-- 1 root root 9330736 Dec 15 00:34 kernel-genkernel-x86_64-4.19.9-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.14.1-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.14.2-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.14.3-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.14.4-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.14.5-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.15.0-42-generic
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.1-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.1-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.2-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.2-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.3-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.3-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.4-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.4-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.5-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.17.5-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.1-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.1-gentoo.old
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.2-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.2-gentoo.old
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.3-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.3-gentoo.old
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.4-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.4-gentoo.old
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.5-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 vmlinuz-4.18.5-gentoo.old
(chroot) root@e6430 /boot #

First of all, I really like the ability to set simple menuentries-- nice work!

The sorting isn't quite right yet. For simplicity, Let's focus on the ubuntu entries:

The menu display contains:

vmlinuz-4.14.1-42-generic
vmlinuz-4.14.2-42-generic
vmlinuz-4.14.3-42-generic
vmlinuz-4.14.4-42-generic
vmlinuz-4.14.5-42-generic
vmlinuz-4.15.0-42-generic

pipe that list through | sort -r (reverse) and we can fix the results:

vmlinuz-4.15.0-42-generic
vmlinuz-4.14.5-42-generic
vmlinuz-4.14.4-42-generic
vmlinuz-4.14.3-42-generic
vmlinuz-4.14.2-42-generic
vmlinuz-4.14.1-42-generic

Likewise take a look at this genkernel set:

-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.1-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.1-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.2-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.2-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.3-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.3-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.4-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.4-gentoo.bak
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.5-gentoo
-rw-r--r-- 1 root root       0 Dec 16 12:23 kernel-genkernel-x86_64-4.19.5-gentoo.bak
-rw-r--r-- 1 root root 9330736 Dec 15 00:34 kernel-genkernel-x86_64-4.19.9-gentoo

This one did something weird in the test. 1. It appeared in two sections (each accompanying .old / .bak kernel should appear below it's associated new kernel). 2. Notice the numbers were also completely out of order:

# the genkernel test results
kernel-genkernel-x86_64-4.19.5-gentoo
kernel-genkernel-x86_64-4.19.3-gentoo
kernel-genkernel-x86_64-4.19.1-gentoo
kernel-genkernel-x86_64-4.19.2-gentoo
kernel-genkernel-x86_64-4.19.4-gentoo
kernel-genkernel-x86_64-4.19.9-gentoo

# accompanying .bak's were in a different section entirely, and in a different order:
kernel-genkernel-x86_64-4.19.2-gentoo.bak
kernel-genkernel-x86_64-4.19.5-gentoo.bak
kernel-genkernel-x86_64-4.19.4-gentoo.bak
kernel-genkernel-x86_64-4.19.3-gentoo.bak
kernel-genkernel-x86_64-4.19.1-gentoo.bak

Again fixed with a reverse sort,

cat << EOF | sort -r
> kernel-genkernel-x86_64-4.19.5-gentoo
kernel-genkernel-x86_64-4.19.3-gentoo
kernel-genkernel-x86_64-4.19.1-gentoo
kernel-genkernel-x86_64-4.19.2-gentoo
kernel-genkernel-x86_64-4.19.4-gentoo
kernel-genkernel-x86_64-4.19.9-gentoo
kernel-genkernel-x86_64-4.19.2-gentoo.bak
kernel-genkernel-x86_64-4.19.5-gentoo.bak
kernel-genkernel-x86_64-4.19.4-gentoo.bak
kernel-genkernel-x86_64-4.19.3-gentoo.bak
kernel-genkernel-x86_64-4.19.1-gentoo.bak
EOF

# fixed:
kernel-genkernel-x86_64-4.19.9-gentoo
kernel-genkernel-x86_64-4.19.5-gentoo.bak
kernel-genkernel-x86_64-4.19.5-gentoo
kernel-genkernel-x86_64-4.19.4-gentoo.bak
kernel-genkernel-x86_64-4.19.4-gentoo
kernel-genkernel-x86_64-4.19.3-gentoo.bak
kernel-genkernel-x86_64-4.19.3-gentoo
kernel-genkernel-x86_64-4.19.2-gentoo.bak
kernel-genkernel-x86_64-4.19.2-gentoo
kernel-genkernel-x86_64-4.19.1-gentoo.bak
kernel-genkernel-x86_64-4.19.1-gentoo

I think if we solve these two sections here, the whole thing will likely be resolved. Thanks for all your hard work, I wish I was a python coder to assist better with this.

edit: I do think also it would be best not to put .old and .bak entries at the bottom forcefully, but to just let them sort naturally below their associated kernel versions, as the sort utility examples do.

[a-schaefers]

Followup, when I said (end of last post),

edit: I do think also it would be best not to put .old and .bak entries at the bottom forcefully, but to just let them sort naturally below their associated kernel versions, as the sort utility examples do.

Ironically, in the example, you notice the ".bak" actually appear "above" the associated kernel version without ".bak". This is just the sort utility doing the right thing. Now I see why you are putting them at the end of the menu. I think this is fine, if there is not a simple way to intersperse them "below". The most important thing however is getting a proper reverse sort.

Please don't kill me. :rofl:

[johnramsden]

So I had written my own sort function because I thought the entries wouldn't get sorted correctly based on kernel version using the regular sort. I guess I shouldn't have just assumed that. After just testing using the regular sorted() it seems to give us the expected output:

genkerns = [ "kernel-genkernel-x86_64-4.19.9-gentoo", "kernel-genkernel-x86_64-4.19.5-gentoo.bak", "kernel-genkernel-x86_64-4.19.5-gentoo", "kernel-genkernel-x86_64-4.19.4-gentoo.bak", "kernel-genkernel-x86_64-4.19.4-gentoo", "kernel-genkernel-x86_64-4.19.3-gentoo.bak", "kernel-genkernel-x86_64-4.19.3-gentoo", "kernel-genkernel-x86_64-4.19.2-gentoo.bak", "kernel-genkernel-x86_64-4.19.2-gentoo", "kernel-genkernel-x86_64-4.19.1-gentoo.bak", "kernel-genkernel-x86_64-4.19.1-gentoo" ]

vmlinuz = [ "vmlinuz-4.14.1-42-generic", "vmlinuz-4.14.2-42-generic", "vmlinuz-4.14.3-42-generic", "vmlinuz-4.14.4-42-generic", "vmlinuz-4.14.5-42-generic", "vmlinuz-4.15.0-42-generic" ]

for en in [ genkerns, vmlinuz ]:
    for entry in sorted(en, reverse=True):
        print(entry)
    print("\n")

kernel-genkernel-x86_64-4.19.9-gentoo
kernel-genkernel-x86_64-4.19.5-gentoo.bak
kernel-genkernel-x86_64-4.19.5-gentoo
kernel-genkernel-x86_64-4.19.4-gentoo.bak
kernel-genkernel-x86_64-4.19.4-gentoo
kernel-genkernel-x86_64-4.19.3-gentoo.bak
kernel-genkernel-x86_64-4.19.3-gentoo
kernel-genkernel-x86_64-4.19.2-gentoo.bak
kernel-genkernel-x86_64-4.19.2-gentoo
kernel-genkernel-x86_64-4.19.1-gentoo.bak
kernel-genkernel-x86_64-4.19.1-gentoo

vmlinuz-4.15.0-42-generic
vmlinuz-4.14.5-42-generic
vmlinuz-4.14.4-42-generic
vmlinuz-4.14.3-42-generic
vmlinuz-4.14.2-42-generic
vmlinuz-4.14.1-42-generic

New code on the way.

---

When you have a problem, it's better you speak up and let me fix it at the time rather than letting it bother you, so no worries, no murdering will occur. I appreciate all your help in testing the fixes, not all contributions have to be code.

On another note, you should really learn python :wink:, it's a fun language that is easy to learn, and is also very powerful.

[a-schaefers]

Awesome, and yes, thank you! I'm glad this is coming.

Re: Python... It's on my list. Most of all I am very happy to help test this project, it is something that Linux has needed badly for some time. :smile: I'm currently working to get my posix sh and awk into better shape, but I do see python is used frequently for many applications and do intend to learn at least the fundamentals of python. Thank you.

[johnramsden]

Scratch that, it looks like when the multiple types of kernels are there it is not going to sort the versions together.

We would end up with something like this:

Current generic sort

``` vmlinuz-linux vmlinuz-4.19.4-gentoo vmlinuz-4.19.4-gentoo.old vmlinuz-4.18.5-gentoo vmlinuz-4.18.5-gentoo.old vmlinuz-4.18.4-gentoo vmlinuz-4.18.4-gentoo.old vmlinuz-4.18.3-gentoo vmlinuz-4.18.3-gentoo.old vmlinuz-4.18.20-gentoo vmlinuz-4.18.2-gentoo vmlinuz-4.18.2-gentoo.old vmlinuz-4.18.1-gentoo vmlinuz-4.18.1-gentoo.old vmlinuz-4.17.5-gentoo vmlinuz-4.17.5-gentoo.bak vmlinuz-4.17.4-gentoo vmlinuz-4.17.4-gentoo.bak vmlinuz-4.17.3-gentoo vmlinuz-4.17.3-gentoo.bak vmlinuz-4.17.2-gentoo vmlinuz-4.17.2-gentoo.bak vmlinuz-4.17.1-gentoo vmlinuz-4.17.1-gentoo.bak vmlinuz-4.15.0-42-generic vmlinuz-4.14.5-42-generic vmlinuz-4.14.4-42-generic vmlinuz-4.14.3-42-generic vmlinuz-4.14.2-42-generic vmlinuz-4.14.1-42-generic kernel-genkernel-x86_64-4.19.9-gentoo kernel-genkernel-x86_64-4.19.5-gentoo kernel-genkernel-x86_64-4.19.5-gentoo.bak kernel-genkernel-x86_64-4.19.4-gentoo kernel-genkernel-x86_64-4.19.4-gentoo.bak kernel-genkernel-x86_64-4.19.3-gentoo kernel-genkernel-x86_64-4.19.3-gentoo.bak kernel-genkernel-x86_64-4.19.2-gentoo kernel-genkernel-x86_64-4.19.2-gentoo.bak kernel-genkernel-x86_64-4.19.1-gentoo kernel-genkernel-x86_64-4.19.1-gentoo.bak ```

I assume you would want the following ordering right?

versions together

``` vmlinuz-linux kernel-genkernel-x86_64-4.19.9-gentoo kernel-genkernel-x86_64-4.19.5-gentoo kernel-genkernel-x86_64-4.19.5-gentoo.bak vmlinuz-4.19.4-gentoo vmlinuz-4.19.4-gentoo.old kernel-genkernel-x86_64-4.19.4-gentoo kernel-genkernel-x86_64-4.19.4-gentoo.bak kernel-genkernel-x86_64-4.19.3-gentoo kernel-genkernel-x86_64-4.19.3-gentoo.bak kernel-genkernel-x86_64-4.19.2-gentoo kernel-genkernel-x86_64-4.19.2-gentoo.bak kernel-genkernel-x86_64-4.19.1-gentoo kernel-genkernel-x86_64-4.19.1-gentoo.bak vmlinuz-4.18.5-gentoo vmlinuz-4.18.5-gentoo.old vmlinuz-4.18.4-gentoo vmlinuz-4.18.4-gentoo.old vmlinuz-4.18.3-gentoo vmlinuz-4.18.3-gentoo.old vmlinuz-4.18.20-gentoo vmlinuz-4.18.2-gentoo vmlinuz-4.18.2-gentoo.old vmlinuz-4.18.1-gentoo vmlinuz-4.18.1-gentoo.old vmlinuz-4.17.5-gentoo vmlinuz-4.17.5-gentoo.bak vmlinuz-4.17.4-gentoo vmlinuz-4.17.4-gentoo.bak vmlinuz-4.17.3-gentoo vmlinuz-4.17.3-gentoo.bak vmlinuz-4.17.2-gentoo vmlinuz-4.17.2-gentoo.bak vmlinuz-4.17.1-gentoo vmlinuz-4.17.1-gentoo.bak vmlinuz-4.15.0-42-generic vmlinuz-4.14.5-42-generic vmlinuz-4.14.4-42-generic vmlinuz-4.14.3-42-generic vmlinuz-4.14.2-42-generic vmlinuz-4.14.1-42-generic ```

@a-schaefers Since I'm going to be writing a custom sort anyway, where would you expect to see the genkernels compared to the non genkernels? Would you want to see vmlinuz-4.19.4-gentoo or kernel-genkernel-x86_64-4.19.4-gentoo first in the above examples? Does it matter?

[a-schaefers]

I'm not sure we have a use-case that necessitates the need for your second example. My opinion is the first "generic sort" example from you is simple and good enough. The typical workflow is a machine standardizes on one distribution and its kernel, and perhaps keeps a handful of backup older kernel versions in /boot. We just need to make sure the new one is always first (top) in position 0. Right?

[a-schaefers]

One more thing again, take for example these two entries:

kernel-genkernel-x86_64-4.19.5-gentoo kernel-genkernel-x86_64-4.19.5-gentoo.bak

if after running through sort it puts ".bak" or ".old" is "above" it in the list, I think that is minor, and maybe not even an "issue". I mean, who really uses ".bak" or ".old" aside from gentoo ricers in 2018??? I could be wrong though?

So I am saying, if it's too much Python, keep the code simple and leave out that bit probably also. And just let the sort do the sort as-is. Of course, knock yourself out if you desire.

All my opinions! Thanks so much!

[johnramsden]

Oh well, it's pretty much written now :smile: . Another thing, if we have an unversioned kernel do you think it should be first or last?

[a-schaefers]

Oh well, it's pretty much written now . Another thing, if we have an unversioned kernel do you think it should be first or last?

Cool! The gnu "sort -r" default is as follows, so I guess that would be my best guess. But I also wonder what GRUB default scripts would actually do.

adam@e6430 ~ $ cat << EOF | sort -r 
> vmlinuz-4.14.2-42-generic
vmlinuz-4.14.1-42-generic
vmlinuz
linux
linuz-4.14.2-42-generic
EOF

> > > > > 
vmlinuz-4.14.2-42-generic
vmlinuz-4.14.1-42-generic
vmlinuz
linux-4.14.2-42-generic
linux

[johnramsden]

I'm not actually sure the grub scripts do any sorting. At least if they do I couldn't find it in the source code.

Anyway I've got in the sorting working https://github.com/johnramsden/zedenv-grub/commit/e89d00aab1a42bf9d7ec8a04fe45dbcbf8c2a625, I don't know if you wanted to try it again before I committed it to master? It seems to work in my limited testing though. I am sticking un-versioned kernels at the end currently, I wasn't sure what you thought of that?

It orders all of the backup entries directly after all of the corresponding versions. So the backup entries won't come directly after their corresponding file, but they will come before any other versions. It was the most convenient way to do it based on my sorting.

Let me know what you think.

[a-schaefers]

As far as I can, e89d00a is really great. Nice work!

I think it just looks spectacular and orderly, especially when set with:

zedenv set org.zedenv.grub:simpleentries=no

[a-schaefers]

@johnramsden can you confirm single name kernel entries like "linux" or "vmlinuz" are showing up on your menu? I do not see it on my dummy menu anywhere.

[a-schaefers]

grubtest.txt

(chroot) root@e6430 /boot # ls -al vmlinuz
-rw-r--r-- 1 root root 9330736 Dec 16 23:53 vmlinuz
(chroot) root@e6430 /boot # ls -al linux
-rw-r--r-- 1 root root 9330736 Dec 16 23:53 linux

(chroot) root@e6430 /boot # grub-mkconfig -o ./testgrub.cfg
Generating grub configuration file ...

testgrub.cfg attached

[johnramsden]

I don't think they would be considered valid entries.

At least according to 10_linux, these are entries that are accepted:

machine=`uname -m`
case "x$machine" in
    xi?86 | xx86_64)
    list=`for i in /boot/vmlinuz-* /vmlinuz-* /boot/kernel-* ; do
                  if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
              done` ;;
    *) 
    list=`for i in /boot/vmlinuz-* /boot/vmlinux-* /vmlinuz-* /vmlinux-* /boot/kernel-* ; do
                  if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
         done` ;;
esac

and initramfs:

  initrd=
  for i in "initrd.img-${version}" "initrd-${version}.img" "initrd-${version}.gz" \
       "initrd-${version}" "initramfs-${version}.img" \
       "initrd.img-${alt_version}" "initrd-${alt_version}.img" \
       "initrd-${alt_version}" "initramfs-${alt_version}.img" \
       "initramfs-genkernel-${version}" \
       "initramfs-genkernel-${alt_version}" \
       "initramfs-genkernel-${GENKERNEL_ARCH}-${version}" \
       "initramfs-genkernel-${GENKERNEL_ARCH}-${alt_version}"; do
    if test -e "${dirname}/${i}" ; then
      initrd="$i"
      break
    fi

[a-schaefers]

Oh, good. See I thought that was how you did an entry without version, but I don't actually use non-version named kernels-- so, that makes sense. My mistake on that one then :relieved:

[johnramsden]

Oh, just anything without a version, as in:

vmlinuz-linux
vmlinuz-linux-lts
vmlinuz-linux-zen
initramfs-linux.img
initramfs-linux-lts.img
initramfs-linux-zen.img

Right now they show up last, what do you think, last or first.

[a-schaefers]

I don't feel qualified to say definitively, but if last means "at the bottom" of the menu, then I think that is probably the right decision, since it is the default of a reverse-sort. In the end it probably doesn't matter, I don't think people would use both versioned and unversioned kernel naming conventions. Pick a style and be consistent, right?

[johnramsden]

Yeah I think that makes sense. I'll commit the changes to master, thanks for all your help.