IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 12 August 2020   (all times are UTC)

01:13vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
05:23woernie has left IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de, Remote host closed the connection)
06:52woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
07:14RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro)
09:05enaut[m] has left IRC (enaut[m]!enautmozil@gateway/shell/matrix.org/x-ztrwcxnalotwcziz, Quit: killed)
09:06enaut has left IRC (enaut!enautmatri@gateway/shell/matrix.org/x-ouxhsempunuapekd, Quit: killed)
09:12enaut[m] has joined IRC (enaut[m]!enautmozil@gateway/shell/matrix.org/x-reaccowfchzsqolp)
09:24gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
09:31enaut has joined IRC (enaut!enautmatri@gateway/shell/matrix.org/x-dhlkiyyblsjjisbi)
10:09kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net)
11:20woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection)
12:18
<kvaps>
alkisg: didn't you face with the following problem:Could not parse output of: ip -o route get 192.168.67.2LTSP command failed: test MAC_ADDRESS= != MAC_ADDRESS=Aborting ltspLTSP boot error! Enable DEBUG_SHELL to troubleshoot!
12:29
<alkisg>
kvaps: no, I haven't seen that, what's the output of that command on the client, does the client have ipv6?
12:29
ip -o route get 192.168.67.2
12:31
<kvaps>
I can't get into client, this is happening on the booting time. It seems the interface is going up before the /scripts/init-bottom is called
12:31
the DEBUG_SHELL=1 is not working
12:34
<alkisg>
kvaps: did you put that in ltsp.conf under [clients]? Did you run `ltsp initrd`?
12:35
(or under [common])
12:36
<kvaps>
I put it to common
12:36
<alkisg>
[ 44.807513] mlx4_en: eno1d1: Link Up ==> that shows after networking is up and the root device is connected? How?
12:37
<kvaps>
let's move this discussion to gihub https://github.com/ltsp/ltsp/issues/144
12:40
<alkisg>
This doesn't sound like an ltsp bug but like a customization bug...
12:43
<kvaps>
Yep agree
12:50
alkisg: I just thinking about the better option to fix it, do we need network_vars for the initrd-bottom applet?
12:50
<alkisg>
kvaps: at the initrd_bottom, the network devices should already be up
12:51
I'll remove "configure_networking" later on when I have time to review the code;
12:51
the proper place for it is an initramfs hook, not the ltsp code...
12:51
The race condition with udev is normally taken care of by initramfs-tools, but you need to tell configure_networking to wait for udev appropriately...
12:52
"do we need network_vars for the initrd-bottom applet?" ==> yes, for [mac:address] POST_INITRD_BOTTOM=x commands to work...
12:52
<kvaps>
but this check is happens before calling the initrd-bottom script, isn't it?
12:53
<alkisg>
kvaps: only because you are not using initramfs-tools properly
12:53
<kvaps>
OK, I see
12:53
<alkisg>
You're doing network boot without telling them to initialize the network via a kernel command line
12:54
<kvaps>
without telling them to initialize the network via a kernel command line - it is not working anyway :)
12:54
<alkisg>
kvaps: check the code for nfs or nbd boot, you're supposed to write similar code for http too, as part of an initramfs-tools hook
12:55
initramfs-tools doesn't support "general netbooting", it only supports specific protocols
12:57
<kvaps>
the problem is that `configure_networking` function should explicitly called before you need the network itself, actually I don't need it before the `intird-bottom`, but ltsp itself is needed to perform `network_vars` correctly
12:57
One of possible solution is to move root mount preparation on upper level
12:58
<alkisg>
ltsp shouldn't call configure_networking at all, since it expects initramfs-tools to call it at "mount"
12:58
So when ltsp runs at initrd-bottom, a mac address is always there
12:59
<kvaps>
I'm about the case if we downloading rootfs-image via HTTP
12:59
<alkisg>
Yes, the code there is wrong
12:59
It shouldn't be implemented inside ltsp, but outside it, as an initramfs-tools mount hook
12:59
Not at initrd bottom
13:01
<kvaps>
OK then by following this logic the copying image from NFS to the RAM should also be moved to upper level of initramfs.
13:01
<alkisg>
No. The key is that "ltsp should not care about networking and root file system mounting"
13:01
These should be done by initramfs-tools
13:01
Once you have NFS root from initramfs-tools, then you're free to copy it around in initrd-bottom
13:02
In ram, or to loop-mount squashfs etc
13:02
or to apply overlay... all the things that we do
13:02
That way the ltsp code will be able to run under dracut too, with minimal modifications
13:03
<kvaps>
I wrote that you need to call `configure_networking` function explicitly, before you need the network configured. If you're not using nfs root, the initramfs will never configure it by itself, even if you specify `ip=dhcp` for the commandline
13:03
here is a report https://bugs.launchpad.net/bugs/1463846
13:04
<alkisg>
configure_networking is an internal function of initramfs-tools, we shouldn't call that
13:05
People that write initramfs-tools extensions (hooks) could call that; that's where http booting belongs
13:05
And if you write such a hook, then you should not use ip=dhcp
13:06
You should use httproot= similar to how nbdroot or nfsroot do it
13:08
<kvaps>
if you're writing code for the initramfs you should to, there is no other option, for example nfsroot module developers are calling it explicitly
13:09
<alkisg>
Exactly, but then it's not part of ltsp code so we dont need to troubleshoot it ;)
13:09
<kvaps>
>You should use httproot= similar to how nbdroot or nfsroot do ityep. maybe thats the way
13:11
I just do not like this idea, what the difference between the `cp /nfsshare/some.img /run/initramfs/some.img` and `wget http://server/some.img -O /run/initramfs/some.img`?
13:14
and this is pity that I forced to write new initramfs-module for such minor change, just because `configure_networking` should be explicitly called to make ltsp code working :-/
13:16
<alkisg>
kvaps: initramfs-tools processes root, nbdroot, nfsroot etc at the "mount" stage
13:16
ltsp has no "mount" hook; if you want to put one, you can, but "initrd-bottom" is after "mount", see `man initramfs-tools`
13:17
That's why we have "nfsroot=xx ltsp.img=yyy" and not just "ltsp.image=nfs:/xxyy"
13:17
So that nfsroot is processed by initramfs-tools at mount
13:17
<kvaps>
Yes, I understand this
13:17
<alkisg>
10+ years ago, ltsp had mount code itself, it broke too frequently, that's why we removed that code
13:18
(root mounting, that is, not loopback mounting)
13:18
Changes in initramfs-tools both in debian and ubuntu break that part too frequently, and then we need to send SRUs all the time to fix such issues, we shouldn't have root mounting code in ltsp
13:19
<kvaps>
fully agree on this
13:22
actually I don't need to mount any root in my case. I just thinking to provide the following script for the LTSP https://askubuntu.com/a/103225/327437
13:23
It should solve the problem with loading network configuration on the upper stages and will not break anything
13:24
alkisg: many thanks for the productive discussion :)
13:24
<alkisg>
That askubuntu questions just provides a quick hack, not a good implementation... but whatever works for you :)
13:27
Note that if you call configure_networking, you don't need to pass an ip= parameter
13:27
But if you do pass an ip=, then configure_networking respects it
13:27
<kvaps>
Oh, cool, thanks for it!
13:35
I just thinking about this situation from the oposit side.
13:35
Does the `initrd-bottom` applet requires configured networking? Normaly don't, because it resues already mounted root=.
13:36
Does the `ltsp` main binary requires configured networking? It is, because it loading network variables via `network_vars`.
13:36
Initramfs defines that `configure_networking` should be explicitly called before you actually need the network.
13:36
If we're not using `nfsroot=` then we don't need any network, and the boot will be failed by the `ltsp` main binary because it will try to load `network_vars`.
13:36
<alkisg>
(04:35:55 PM) kvaps: Does the `initrd-bottom` applet requires configured networking? ==> yes, to process POST_INITRD_BOTTOM=blah
13:36
<kvaps>
solution? Call `configure_networking` before calling the ltsp binary, because it is required
13:36mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 256 seconds)
13:37
<alkisg>
(04:36:16 PM) kvaps: Initramfs defines that `configure_networking` should be explicitly called before you actually need the network. ==> initramfs says that root should be mounted at "mount"
13:37
<kvaps>
no, I'm meant the applet itself
13:37
<alkisg>
kvaps: if you want to create an /usr/share/initramfs-tools/scripts/local-top/http script, similar to local-top/nbd, you can then ship it via ltsp.img
13:37
But we need to respect the "mount" stage
13:38
We must not mount root at bottom. We must mount it at "mount".
13:38
You can put mount code at initrd-bottom, but it's wrong, then you do not respect the initramfs-tools design
13:39
In other words, if you wanted http boot with dracut and ltsp, you wouldn't need configure_networking, and you wouldn't even *have* configure_networking, as dracut doesn't have that
13:39
<kvaps>
Agree, that's why IMAGE_TO_RAM=1 is also kind of workaround
13:40
<alkisg>
Yeah, I didn't have time to give proper feedback for that then either
13:40
When I'll get time, I'll remove all calls to configure_networking and suggest proper solutions instead
13:40
On the other hand, if one has nfsroot=... and image_to_ram, they don't need configure_networking
13:41
As the root is already there and we can copy it without configure_networking calls
13:41
So IMAGE_TO_RAM is ok, but the configure_networking call is not OK
13:44
<kvaps>
Ok, let's assume we can have some root which can be mounted without network. Not real case but just imagine that you have already properly mounted root on the `local-top` stage.
13:44
Will ltsp code fail then?
13:44
<alkisg>
It can fail then, yes; it should NOT invoke configure_networking, but it should state that in this case, [mac:address] sections will not be evaluated
13:45
E.g. if you call configure_networking and the user has no ethernet cable, you wait for nothing
13:47
<kvaps>
OK, to solve this abstract situation you can simple to change re to ro on this line https://github.com/ltsp/staging/blob/41ab409c7e54999603301ac749943b5a9cd41f10/ltsp/common/ltsp/55-config.sh#L289
13:48
<alkisg>
You mean rw?
13:48
<kvaps>
yep, sorry
13:48
It will solve my problem, but I want to make ltsp respect client mac addresses settings, that's why I want to create this dirty workaround to just call configure_networking before the ltsp
13:48
<alkisg>
What will /etc/machine_id contain then?
13:49
Currently, it contains the mac address
13:49
<kvaps>
nothing good I guess xD
13:49
<alkisg>
ltsp-client currently relies on the mac address too much to ignore it
13:50
If we ever need "booting without a mac address", then it'll be a big patch :)
13:55
<kvaps>
I think we can use `/sys/devices/virtual/dmi/id/product_uuid`
13:58
sha1sum /sys/devices/virtual/dmi/id/product_uuid | cut -c -32
13:58
<alkisg>
"Surprisingly, the UUID was same for all the VM's I had, which caused the name collision and changing the UUID resolved the issue."
13:58
It's not just about machine-id, we use mac address in a lot of places
13:59
There's no need to add hacks just to avoid creating a file at the proper place...
13:59
The correct place for configure_networking is at mount; you can easily do that, there's no need to change the uuids just to avoid that
13:59
<kvaps>
I know, it was just an idea :)
14:00
My case is different, I need always configured networking
14:01
<alkisg>
You need to implement http booting for initramfs-tools. Casper and dracut already have it.
14:01
There's no need to implement that inside ltsp, but you can surely ship that file from ltsp
14:01
You can even implement that inside ltsp, but it'll need to be in a new applet, `ltsp initrd-mount`
14:02
<kvaps>
dracut has no support, I wrote the module for dracut https://github.com/kvaps/livenetsquash
14:03
> You can even implement that inside ltsp - no way, ltsp code will fail before execution any applet
14:03
<alkisg>
https://man7.org/linux/man-pages/man7/dracut.cmdline.7.html ==> root=live:<url> Boots a live image retrieved from <url>. Requires the dracut livenet module. Valid handlers: http, https, ftp, torrent, tftp.
14:03
Is this your module?
14:04woernie has joined IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de)
14:05
<alkisg>
kvaps: this is where the initramfs-tools hacks go: ltsp/client/initrd-bottom/initramfs-tools/ltsp-hook.conf:install_ltsp_hooks() {
14:06
You can easily add a configure_networking call to "mount" from there
14:07
(or better yet, just symlink your httproot script to initramfs-tools from there)
14:07
<kvaps>
> Is this your module? - not really, i don't remember why I wrote my own
14:08
probably it wasn't working correct with overlayfs or had no this functional
14:08
<alkisg>
Overlayfs support was added in dracut in 2018
14:09
<kvaps>
hmm, commit is created 5 years ago, my script is 3 years old
14:09
<alkisg>
I haven't tested dracut much, I can't comment more :)
14:10
I'll need to go, so, to sum up: I propose that you clone /usr/share/initramfs-tools/scripts/local-top/nbd to http, you put your code there, and you use ltsp-hook.conf to install it when you see httproot= in the kernel cmdline
14:10
This way you mount at the "mount" stage, and everything works fine
14:11
And the code clearly shows that it's initramfs-tools specific
14:11
<kvaps>
OK, thanks for that!
14:11
<alkisg>
np, have fun :)
14:12
<kvaps>
👍
14:13
<alkisg>
So your script would go to: ./ltsp/client/initrd-bottom/initramfs-tools/httproot
14:15mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
14:20gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
14:25mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 265 seconds)
14:25
<kvaps>
:q
14:59mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
15:26ghaoil has joined IRC (ghaoil!~ghaoil@hs-user-138.wia.cz)
15:35vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:42kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection)
16:47mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Read error: Connection reset by peer)
16:48mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
17:49mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 260 seconds)
18:03mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
18:16RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.)
18:20enaut has left IRC (enaut!enautmatri@gateway/shell/matrix.org/x-dhlkiyyblsjjisbi, *.net *.split)
18:20quinox has left IRC (quinox!~quinox@ghost.qtea.nl, *.net *.split)
18:22enaut[m] has left IRC (enaut[m]!enautmozil@gateway/shell/matrix.org/x-reaccowfchzsqolp, Remote host closed the connection)
18:25mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 256 seconds)
18:26quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
18:26enaut[m] has joined IRC (enaut[m]!enautmozil@gateway/shell/matrix.org/x-zslgontzybutzwaq)
18:38mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
18:46enaut has joined IRC (enaut!enautmatri@gateway/shell/matrix.org/x-eehjpkndvwydttrw)
19:13gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
19:14gvy has left IRC (gvy!~mike@altlinux/developer/mike, Client Quit)
19:42ghaoil has left IRC (ghaoil!~ghaoil@hs-user-138.wia.cz, Quit: Leaving)
22:02shored has left IRC (shored!~shored@87-100-202-16.bb.dnainternet.fi, Quit: ZNC 1.7.2+deb3 - https://znc.in)
22:03shored has joined IRC (shored!~shored@87-100-202-16.bb.dnainternet.fi)