|00:02||map7_ has joined IRC (email@example.com)|
|00:20||bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection)|
|00:42||map7_ has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|00:46||telex has left IRC (email@example.com, Remote host closed the connection)|
|00:48||telex has joined IRC (firstname.lastname@example.org)|
|01:30||n0ps has left IRC (n0ps!3aa5e1dd@gateway/web/freenode/ip.18.104.22.168, Quit: Page closed)|
muppis: yeah - that's why we just went the straight ubuntu install with puppet. Works out well. I just miss LTSP, what can I say. :P
|02:02||freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer)|
|03:19||AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-owpzhwriyfxjckht, Quit: Connection closed for inactivity)|
|04:36||FGXR6 has joined IRC (FGXR6email@example.com)|
|04:37||F-GT has left IRC (F-GTfirstname.lastname@example.org, Ping timeout: 264 seconds)|
|04:51||vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)|
the kernel version sorting in ltsp 5.5.4 is borked in Debian :(
went to test what i needed to fix for the 486 -> 586 switch, and it's all kinds of borked.
|04:53||andygraybeal has joined IRC (email@example.com)|
|05:07||NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 265 seconds)|
well, figured out a one-line that's using the debian-specific linux-version tool...
at least, i think i've got it...
work_alkisg: definitely struggling with the kernel sorting code again...
linux-versions isn't 32/pae/64 aware, of course...
|06:27||adrianorg has left IRC (firstname.lastname@example.org, Ping timeout: 240 seconds)|
|06:30||adrianorg has joined IRC (email@example.com)|
|06:30||elias_a has joined IRC (firstname.lastname@example.org)|
|06:37||zamba has left IRC (email@example.com, *.net *.split)|
|06:37||elias_a_ has left IRC (firstname.lastname@example.org, *.net *.split)|
|06:39||zamba has joined IRC (email@example.com)|
|07:34||mealstrom has joined IRC (mealstrom!~Thunderbi@22.214.171.124)|
|07:43||mealstrom has left IRC (mealstrom!~Thunderbi@126.96.36.199, Ping timeout: 264 seconds)|
|08:15||mealstrom has joined IRC (mealstrom!~Thunderbi@188.8.131.52)|
|08:23||ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)|
|08:30||freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun)|
|08:36||work_alkisg is now known as alkisg|
|08:36||* alkisg waves to vagrantc|
|08:36||* vagrantc waves|
What's the new kernel name like?
well, i was thinking about upgrades, and it turns out the old ones always showed up first
so i tested with a full set of real-world package names ...
We want to sort like this: "least capable cpu, newer kernel version" > "least capable cpu, older kernel version" > "most capable cpu, newer kernel version" > "most capable cpu, older kernel version"
3.2.0-4-486, 3.16-4-486, 3.16.0-4-586, 3.16-0.bpo.3-486, 3.17-1-486, 3.17.0-trunk-586
And it happened so that natural sorting was good enough at the time we wrote it
alkisg: well, it got rewritten significantly since wheezy
the version in wheezy is *more* reliable, but still has issues
Wait, the last code is the one with the sed line, isn't it?
That separates the kernel name, version etc?
yeah, and the separate functions for kernel_split, kernel_versions, kernel_variants ?
if it split the upstream version from the abi, it might be possible to make more reliable.
# A sed expression that matches all kernels and returns $FILE $NAME $VERSION $FLAVOR
# Example: ls /boot | sed -n "$KERNEL_NAMES" | sort -V -k 4,4 | sort -r -k 3,3
KERNEL_NAMES='s/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p'
So, what do we want in the examples you pasted above?
To sort 486 first, and 586 last?
well, strictly speaking, 586 is just a more accurate name in debian... it hasn't supported genuine 486s for quite some time
what i don't want is on upgrade to jessie, you find you're still running the wheezy kernel
i also think between wheezy and jessie the sorting rules got flip-flopped ... it seems to consistantly put the oldest kernel first, no matter what
But can you say that in a form of a rule?
gah, i shut down the machine i was testing on ...
Otherwise, we'd need a function with special cases depending on the specific names, and when those change, to update the function ...
Is there a use case where someone upgrading from wheezy => jessie would need to keep the 486 kernel?
Maybe it should be solved with a Conflicts/Replaces somewhere?
i think in theory, adding 586 to the KERNEL_LIST_32 would be fine ... except the overall sorting function is borked
no, conflicts is a bad idea.
Let's phrase the function first, and check it after that
What I proposed and thought that I implemented, was: "sort FLAVOR in an increasing order, and VERSION in decreasing"
I.e. that a random client would boot with 486 if you had both 486 and 586 installed
the logic has gotten messy with the evolution of these names...
If I install jessie and then install 486, then that's still what I want
The logic didn't cover "left over kernels"
here's the one that messes with my mind:
vagrantc: give me a paste of ls /boot to test with
The sorting there in your paste is wrong though
It's not decreasing within the same flavor
thanks for taking a look at it ... i keep thinking i understand this bit of code, and then my head starts spinning again
The 2 sorts at the end seem broken, they don't work like they're supposed to
sed -n 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p' | sort -V -k 4,4 ==> sorts OK with flavor
Ah, sort -r should be numeric, -rn or somethin
i think the following sort breaks it
i.e. the first sort sorts one way, but then scrambles the previous sort
ls /opt/ltsp/i386/boot/ | sed -n 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p' | sort -V -k 4,4 -k 3,3
that seems better
It needs -r
"sort FLAVOR in an increasing order, and VERSION in decreasing"
but i think calling two sorts undoes the second sort entirely
Well, we could temporarily merge $FLAVOR$VERSION in order to do it, but let's see if `sort` can do it without that trick...
I thought that sort didn't change the order of the lines that had the same value in "key"
KERNEL_LIST_32="586 486 686" ... maybe that's what i'll want on upgrade ...
686 is ancient legacy
vagrantc: sed -n 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p' | sort -k 4,4V -k 3,3rV
That was what I intented to do, sorry for the bug
But now with 586 you're saying it doesn't fit anymore
won't that be fixed with KERNEL_LIST_32 ?
is that sorting only working because 486 < 586 < 686-pae ?
it's certainly better than what we've got, but will fail with 3.2.0-4-486 and 3.16.0-4-586 on upgrade...
I don't consider that a failure
If I install jessie with 586 and after that install 486, don't I end up in the same use case, but prefer 486 there?
The logic is "I prefer my clients to have the oldest flavor that I currenty have installed" - it doesn't check about how they got installed
Is 486 available in jessie?
Or completely gone?
alkisg: but if you upgrade a chroot, that won't remove the kernel.
That's a problem with the upgrade, not with our logic
When I upgrade from 12.04 to 14.04 I still have the 3.2 kernel
or even without a chroot
...and xorg doesn't work there
But ltsp would correctly prefer the 3.2 kernel for the clients
It's still a problem with the upgrade, it should have removed the older kernel
well, other boot loaders just boot the highest available kernel
and leaving the old kernels around is a non-issue
granted, we have a more complicated use-case...
i guess i'm second guessing the logic of preferring an older kernel in any case
Not older kernel, older flavor
sed -n 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/& \1 \2 \3/p' | sort -k 4,4rV -k 3,3rV
That would sort both flavor and version in decreasing order
...but my clients wouldn't boot with amd64 first
|09:21||* vagrantc installs a few more kernels for comparison|
Btw, ubuntu doesn't have a non-pae kernel currently
so using "sort -k 4,4V -k 3,3rV" resulted in the correct "default" of 3.17.0-trunk-586 ... but then also selected that for pae and 64-bit
yeah, so thanks for drudging through a debian-specific featre :)
And the package name is the same, "generic", in both 32 and 64 bit
So the ifcpu64 detection code would have to be very smart to work correctly
"I see an ubuntu chroot... and it has 3.12 generic.. let me check `$CHROOT dpkg --print-architecture` to decide if it's 32 or 64 bit..." :P
vagrantc: so, an idea for the future, is to create symlinks for each variant like we do now, e.g. vmlinuz-pae, vmlinuz-486 etc,
and when someone wants ifcpu64, he can do it himself using the symlinks
I.e. to strip all our ifcpu64 code
hrm. now it always picks the amd64 variant for everything
vagrantc: forget the code, let's first agree on what we want
I'm still voting for "sort FLAVOR in an increasing order, and VERSION in decreasing", but I can find workaround if you want something else, like "always decreasing"
i have a hard time abstracting this
the flavor increasing order is essentially by luck with the current set of known kernel names?
Currently the only case where I need multiple kernels is when someone has non-pae client, there he installs a kernel from debian, either -486 or now maybe -586, that should be preferred over ubuntu's "generic"
well, 386<486<586 etc isn't completely luck
But 586 < amd64 is luck, yeah
and this is x86 specific code, sure.
arm32 < arm64
though if the -k6 or -k7 variants ever come back, or something liek that
It might get lucky on other cases too
armmp > arm64
What is armmp?
the other arches aren't really sortable without knowing the sort order
for armhf, 32-bit
...doesn't 64 bit also get multiplatform?
in armhf on debian, there are only two kernels, armmp and armmp-lpae
and in arm64 so far there's only arm64
No need to compare between kernels that will never refer to the same image
But anyway, what's the alternative for a default sort? Always decreasing?
I don't think "always decreasing" has a clear benefit either, it's even worse
A distro can always special-case whatever it needs, we're only talking about the default here
But e.g. hardcoding 586 in ubuntu doesn't make sense...
so yeah, overall your assertion holds reasonably well. it's a bit awkward for upgrades.
i guess which gets sorted first also matters
e.g. sorting so that VERSION always appears first, and flavor as a secondary consideration... as long as you can refine it based on preferred flavors.
basically, i want to be able to say "give me the newest kernel that matches flavors x, y, z"
Where would you say that?
And, how would you update update-kernels.conf when needed?
in the code
OK, so instead of having a postinst that takes care of upgrades, you'd have "if wheezy... else if jessie..." inside the code
ugh. irc-question-response disarray.
If I step back for a moment and look at the big picture there, that sounds broken
i don't say anything like that at all.
the current code has lists of flavors for certain categories (32, pae, 64)
so i'd like to be able to get the list of newest kernels that meet the 32-bit criteria
(11:38:08 πμ) vagrantc: the current code has lists of flavors for certain categories (32, pae, 64) ==> in update-kernels.conf, right?
LIST_KERNELS_32="486 586 686"
(11:36:37 πμ) alkisg: In update-kernels.conf?
(11:36:46 πμ) alkisg: And, how would you update update-kernels.conf when needed?
i'm torn between trying to describe what i want without referring to the code ...
So, suppose you do a conffile update in jessie
And remove 486 from there
Is that ok with you then/
alkisg: same way we do now ... ship a new default update-kernels.conf in the package, and users may edit them
i don't see removing it as valid, necessarily
Or "586 486 686"
right, that seems more the right direction
I do think that conffiles are the correct way to handle distro-specific names
But unfortunately I don't think we use LIST_KERNELS_32 as you want it now
it used to work the way i want it to
the code in wheezy works for that, with my quick tests
But that logic doesn't apply anymore to distros like ubuntu
That's why it was changed
So we still need to find another logic. Yet another time :)
We can't use 32/pae/64 logic in ubuntu anymore, it doesn't apply
Let me describe an idea...
|09:43||* vagrantc just needs to fix a lingering RC bug in ltsp in jessie, which leaves the user at an ancient kernel on upgrade|
We already create symlinks with the latest version of every flavor
We can write those (the symlinks) in default/ltsp in increasing order
and generate a submenu there in default/ltsp with specific versions of them, sorted in "FLAVOR in an increasing order, and VERSION in decreasing"
The new idea here is that we'll also support a LIST_FLAVORS="" variable,
which can be used to override the default "FLAVOR in increasing order", and possibly limit the FLAVORS shown
That's the smallest diff that I can think of to do what you're asking...
i don't see how it even does what i'm asking
LIST_FLAVORS="586 486 686"
ah, got it
my head is still fuzzy thinking this over.
for some reason i always find this overwhelming, which is why i'm staring down another release cycle having not really fixed it yet
the recent switch of 486 to 586 made me think i'd need to look at it ... didn't realize what exactly that meant
i think i can just add an entry for 32 bit, pae, 64 bit by default, and not add the entry if no kernel matches...
and have 32 bit at the top
i think that's simpler than what i've been trying to do...
but that still doesn't solve the issue for arm ...
i'll have to give this a go tomorrow when i've had some rest
i had some linger linux-version calls in my code that might have ben mesing this up...
alkisg: well, i'm not much more use on this issue at the moment ... thanks for putting some effort into it!
|10:22||* vagrantc sleeps|
Good night :)
|10:25||vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)|
|10:27||khildin has joined IRC (firstname.lastname@example.org)|
|10:30||alkisg is now known as work_alkisg|
|10:41||andygraybeal has left IRC (email@example.com, Ping timeout: 255 seconds)|
|11:06||AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ukrvsdjrrmlatwsc)|
|11:53||adrianorg has left IRC (firstname.lastname@example.org, Ping timeout: 240 seconds)|
|11:55||adrianorg has joined IRC (email@example.com)|
|13:21||khildin has left IRC (firstname.lastname@example.org, Quit: I'm gone, bye bye)|
|13:23||david007co has joined IRC (email@example.com)|
|13:47||telex has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|13:48||telex has joined IRC (email@example.com)|
|14:50||david007co2 has joined IRC (firstname.lastname@example.org)|
|14:54||david007co has left IRC (email@example.com, Ping timeout: 250 seconds)|
|15:10||mealstrom has left IRC (mealstrom!~Thunderbi@184.108.40.206, Ping timeout: 264 seconds)|
Is it always necessary to have a Linux server in order to pxe clients that run windows via rdp(ts)?
And 1 pc that provides users to the clients. .
(Being that one the "server")
|15:51||mealstrom has joined IRC (mealstrom!~Thunderbi@220.127.116.11)|
|15:57||mealstrom has left IRC (mealstrom!~Thunderbi@18.104.22.168, Read error: No route to host)|
|16:02||mealstrom has joined IRC (mealstrom!~Thunderbi@22.214.171.124)|
|16:18||david007co2 has left IRC (firstname.lastname@example.org, Ping timeout: 240 seconds)|
|16:35||david007co2 has joined IRC (email@example.com)|
|16:56||david007co2 has left IRC (firstname.lastname@example.org, Ping timeout: 250 seconds)|
|16:58||adrianorg has left IRC (email@example.com, Quit: leaving)|
|17:01||david007co2 has joined IRC (firstname.lastname@example.org)|
|17:09||Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)|
|17:12||vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)|
work_alkisg: i think i've got code that's good enough now
work_alkisg: but it may not work the way you want it
essentially, it returns the listed kernels for the preferred variants first
the risk is if you have a newer version PAE or 64-bit kernel, you'll still be stuck with a 586 kernel
stuck with an older 586 kernel
hrm. seems to have some unintended consequences, though
it seems to be producing fewer pxelinux.cfg/ files
|17:30||david007co2 has left IRC (email@example.com, Ping timeout: 256 seconds)|
so i think passing LIST_KERNELS="foo bar *" kernel_versions has been broken for some time, as * gets expanded
|17:57||david007co2 has joined IRC (firstname.lastname@example.org)|
|18:19||Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)|
|18:19||ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)|
|18:48||adrianorg has joined IRC (email@example.com)|
work_alkisg: ok, i think i have it working, have a moment to review?
|18:58||david007co2 has left IRC (firstname.lastname@example.org, Ping timeout: 245 seconds)|
then i just need to set LIST_KERNELS_32="586 486 686" and it works at least on upgrades to jessie.
erm. i should've looked that you already committed some code... gah.
at, rebased fine...
|19:19||* vagrantc pushes|
|19:23||david007co2 has joined IRC (email@example.com)|
|21:28||mealstrom1 has joined IRC (mealstrom1!~Thunderbi@126.96.36.199)|
|21:30||mealstrom has left IRC (mealstrom!~Thunderbi@188.8.131.52, Ping timeout: 256 seconds)|
|21:50||david007co2 has left IRC (firstname.lastname@example.org, Ping timeout: 272 seconds)|
|22:20||mealstrom1 has left IRC (mealstrom1!~Thunderbi@184.108.40.206, Ping timeout: 255 seconds)|
|22:21||mealstrom has joined IRC (mealstrom!~Thunderbi@220.127.116.11)|
|22:30||freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer)|
|22:30||freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun)|
|22:44||mealstrom has left IRC (mealstrom!~Thunderbi@18.104.22.168, Ping timeout: 258 seconds)|
|22:49||effenberg has left IRC (email@example.com, Ping timeout: 240 seconds)|
|22:52||telex has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|22:54||telex has joined IRC (email@example.com)|
|22:55||david007co2 has joined IRC (firstname.lastname@example.org)|