IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 12 August 2020 (all times are UTC)
| 01:13 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 05:23 | woernie has left IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 06:52 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
| 07:14 | RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro) | |
| 09:05 | enaut[m] has left IRC (enaut[m]!enautmozil@gateway/shell/matrix.org/x-ztrwcxnalotwcziz, Quit: killed) | |
| 09:06 | enaut has left IRC (enaut!enautmatri@gateway/shell/matrix.org/x-ouxhsempunuapekd, Quit: killed) | |
| 09:12 | enaut[m] has joined IRC (enaut[m]!enautmozil@gateway/shell/matrix.org/x-reaccowfchzsqolp) | |
| 09:24 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 09:31 | enaut has joined IRC (enaut!enautmatri@gateway/shell/matrix.org/x-dhlkiyyblsjjisbi) | |
| 10:09 | kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net) | |
| 11:20 | woernie 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:36 | mgariepy 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:04 | woernie 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:15 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 14:20 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving) | |
| 14:25 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 265 seconds) | |
| 14:25 | <kvaps> :q
| |
| 14:59 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 15:26 | ghaoil has joined IRC (ghaoil!~ghaoil@hs-user-138.wia.cz) | |
| 15:35 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 15:42 | kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection) | |
| 16:47 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Read error: Connection reset by peer) | |
| 16:48 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 17:49 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 260 seconds) | |
| 18:03 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 18:16 | RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.) | |
| 18:20 | enaut has left IRC (enaut!enautmatri@gateway/shell/matrix.org/x-dhlkiyyblsjjisbi, *.net *.split) | |
| 18:20 | quinox has left IRC (quinox!~quinox@ghost.qtea.nl, *.net *.split) | |
| 18:22 | enaut[m] has left IRC (enaut[m]!enautmozil@gateway/shell/matrix.org/x-reaccowfchzsqolp, Remote host closed the connection) | |
| 18:25 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 256 seconds) | |
| 18:26 | quinox has joined IRC (quinox!~quinox@ghost.qtea.nl) | |
| 18:26 | enaut[m] has joined IRC (enaut[m]!enautmozil@gateway/shell/matrix.org/x-zslgontzybutzwaq) | |
| 18:38 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 18:46 | enaut has joined IRC (enaut!enautmatri@gateway/shell/matrix.org/x-eehjpkndvwydttrw) | |
| 19:13 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 19:14 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Client Quit) | |
| 19:42 | ghaoil has left IRC (ghaoil!~ghaoil@hs-user-138.wia.cz, Quit: Leaving) | |
| 22:02 | shored has left IRC (shored!~shored@87-100-202-16.bb.dnainternet.fi, Quit: ZNC 1.7.2+deb3 - https://znc.in) | |
| 22:03 | shored has joined IRC (shored!~shored@87-100-202-16.bb.dnainternet.fi) | |