Tails

#3 Updated by beta-tester 2018-12-24 07:11:32

mercedes508 wrote:
> … but also a solid usecase that fits Tails missions. Which I don’t see for the moment
hi @mercedes508
the usecase is to offer an additional channel for running Tails on computers, then you have DVD, USB, and then PXE-boot…
indeed, it is not a solid usecase and from point of view of security and trust, it is only a solution, when your PXE-server is under your control and on a securely trusted local network with only a gateway to the internet.

sorry, then i fully understand your point that i is not on the roadmap of Tails.
i was thinking only to my project to offer as much interesting Linux Live systems as possible,
but i forgot what the mission is behind Tails.

was the PXE boot possibility actively been removed for security/trust reason
or was it simply gone lost, because of an forgotten option by accident?
do you know?

#4 Updated by patpat 2019-01-24 19:02:30

PXE servers are always run on controlled environments then booting Tails live from a PXE server
is always a very handy option.

Tails PXE problem is Debian live distro initrds are not complete from a network point of view.
Debian refused adding/fixing net/CIFS support to their live initrd files time ago:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705748

Serva adds PXE support to Tails by creating an small additional initrd that includes
some missing kernel modules and scripts allowing to access CIFS shares at boot
for net transferring and run the big filesystem.squashfs file.

Serva just added support for 3.11 see here
https://www.vercot.com/~serva/an/NonWindowsPXE3.html

Tails could very well add the missing files to its initrd before releasing a new version.

#5 Updated by beta-tester 2019-05-05 15:39:56

patpat wrote:
> Tails PXE problem is Debian live distro initrds are not complete from a network point of view.
> Debian refused adding/fixing net/CIFS support to their live initrd files time ago:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705748
Debian is already able to PXE boot (at least its Live ISOs) out of the box - i tested it with Debian 7.x .. 9.9.0.
PXE boot with those Live ISOs were never a problem and was possible out of the box - wihtout adding any modules by hand.

> Tails could very well add the missing files to its initrd before releasing a new version.
that’s what i don’t understand…
when Tails based on Debian, and Debian is able to get PXE boot out of the box, why isn’t that possibility not there in Tails…

#6 Updated by intrigeri 2019-05-05 16:20:09

> when Tails based on Debian, and Debian is able to get PXE boot out of the box, why isn’t that possibility not there in Tails…

Debian tries to be “universal” and tons of staff-power, while Tails has a more narrow scope and a small team that needs to focus its resources on stuff that matters to our target user base; it’s quite clear that the vast majority of our users have no clue what PXE is :)

#7 Updated by beta-tester 2019-05-07 05:50:49

intrigeri wrote:
> > when Tails based on Debian, and Debian is able to get PXE boot out of the box, why isn’t that possibility not there in Tails…
>
> Debian tries to be “universal” and tons of staff-power, while Tails has a more narrow scope and a small team that needs to focus its resources on stuff that matters to our target user base; it’s quite clear that the vast majority of our users have no clue what PXE is :)

i always thought that Tails is a modified version of Debian by “simply” removing/replacing stuff that is not “secure”/necessary. and the team simply removed the PXE part by accident (and other distributions based on Debian still are able to PXE boot).
that’s why i still so unhappy with the issue status “rejected” / “won’t fix”.
from my point of view it is a one shot fix, once PXE option is back in again from Debian, it will work to the end of life (until Debian decided to not include that option anymore).

#8 Updated by intrigeri 2019-05-07 06:39:29

Some of our code relies on the implicit assumption that we’ve started from local physical media.

#9 Updated by patpat 2019-05-07 14:57:50

beta-tester wrote:
> patpat wrote:
> > Tails PXE problem is Debian live distro initrds are not complete from a network point of view.
> > Debian refused adding/fixing net/CIFS support to their live initrd files time ago:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705748
> Debian is already able to PXE boot (at least its Live ISOs) out of the box - i tested it with Debian 7.x .. 9.9.0.
> PXE boot with those Live ISOs were never a problem and was possible out of the box - wihtout adding any modules by hand.
>
>
> > Tails could very well add the missing files to its initrd before releasing a new version.
> that’s what i don’t understand…
> when Tails based on Debian, and Debian is able to get PXE boot out of the box, why isn’t that possibility not there in Tails…

Debian has PXE issues
1) Their booting initrd does not include CIFS support (Problem for Windows based PXE servers)
2) Their ipconfig was/is? for long time buggy https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733988
3) Their ipconfig handling makes no distinction between “dhcp” and “bootp” DHCP servers as i.e. Ubuntu does

then
1) Debian is not completely PXE ready
2) Tails must be PXE compatible; who uses pendrives or DVDs today?

#10 Updated by beta-tester 2019-05-07 20:24:46

patpat wrote:
> Debian has PXE issues
> 1) Their booting initrd does not include CIFS support (Problem for Windows based PXE servers)
> 2) Their ipconfig was/is? for long time buggy https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733988
> 3) Their ipconfig handling makes no distinction between “dhcp” and “bootp” DHCP servers as i.e. Ubuntu does
>
> then
> 1) Debian is not completely PXE ready
> 2) Tails must be PXE compatible; who uses pendrives or DVDs today?

i only use PXE - when it is available, it is so much easier … :)
i didn’t know and didn’t notice that Debian has/had those PXE issues.
on my PXE enwironment i never hat an issue with it (https://github.com/beta-tester/RPi-PXE-Server)

#11 Updated by patpat 2019-05-07 20:41:04

beta-tester wrote:
> patpat wrote:
> > Debian has PXE issues
> > 1) Their booting initrd does not include CIFS support (Problem for Windows based PXE servers)
> > 2) Their ipconfig was/is? for long time buggy https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733988
> > 3) Their ipconfig handling makes no distinction between “dhcp” and “bootp” DHCP servers as i.e. Ubuntu does
> >
> > then
> > 1) Debian is not completely PXE ready
> > 2) Tails must be PXE compatible; who uses pendrives or DVDs today?
>
> i only use PXE - when it is available, it is so much easier … :)
> i didn’t know and didn’t notice that Debian has/had those PXE issues.
> on my PXE enwironment i never hat an issue with it (https://github.com/beta-tester/RPi-PXE-Server)

Please consider Debian should consider the different PXE scenarios as other serious distros like RHEL, SuSee, etc. do
1) if your PXE Server runs on Windows initrd CIFS support is needed (Debian doesn’t have it)
2) depending on your DHCP server ipconfig will fail as indicated at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733988
3) depending on your DHCP server ipconfig will fail because Debian fails to make the distinction between dhcp and bootp
The idea here is to provide Tails with the needed know-how in order to offer a “solid” PXE support.

#12 Updated by beta-tester 2019-05-08 04:45:23

patpat wrote:
> Please consider Debian should consider the different PXE scenarios as other serious distros like RHEL, SuSee, etc. do

you got openSUSE-Leap-15 or CentOS-7 to PXE boot without any customizations of the init script?!
would be interesting to me to know how you did it… with those Live-OS’es i am struggleing to find the right PXE boot parameters as well. (dracut does not know how to handle NFS nor HTTP sources)

if you know more about those, would you please open an issue on my https://github.com/beta-tester/RPi-PXE-Server repository and explain me details how you got those OS’es to PXE boot.
thank you.

#13 Updated by beta-tester 2019-05-08 04:55:41

to my PXE boot problem of openSUSE and CentOS see also https://github.com/SUSE/kiwi/issues/796

#14 Updated by ivan623 2020-04-05 12:38:02

Hi,
I read carrefully ticket Bug #11044 and this one.

As far as I understand, there are two reasons to the actual problem with PXE:

1) The technical one: Tails blacklists network drivers (https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/80-block-network) and protocols from the initramfs (and possibly other things I’m not aware of). If I understand correctly, this is done to reduce the attack surface during boot. Once the kernel is loaded, the network drivers are then loaded with a systemd script.

So I unpacked the actual initramfs to remove the file etc/modprobe.d/all-net-blacklist.conf, and then packed it again; the problem is however still there:

Waiting for ethernet card(s) up... If this fails, maybe the ethernet card is not supported by the kernel...

Then, I tried to load manually the network drivers (e1000 for example) and checked with lsmod: no success, e1000 isn’t listed. (I made these modification in lib/live/boot/9990-select-eth-device.sh line 42)

I suspect therefore some other obstacle. I checked in lib/modules/5.3.0-3-amd64/modules.alias, the “e1000” driver doesn’t appear. Did you add an additional obstacle by blacklisting network drivers AND removing also the aliases to prevent someone from loading these drivers in the Linux kernel ?

2) The security-model reason: to ask and/or provide a technical solution to PXE booting is not good enough, as Mercedes508 wrote: “please not only come up with technical solution but also a solid use-case that fits Tails missions.” The change needs to be supported with a solid use-case. Here is one:

Consider a collective space like a hackerspace where people can come by and freely use computers. Make security and privacy a top priority. Assume there is full control over the local network; many network security best practices are deployed.

Assume many users there have a use for Tails (they are also being taught how to use it correctly). Some observations:

- many of them aren’t technically-oriented and they don’t know how to install Tails on USB drives. It can sometimes happen that people who are more knowledgeable aren’t available around to help them;

- they often don’t realize how to update the system, and thus use old versions;

- they might loose or alter their Tails key;

- many of them just pass by (e.g. travelers), and they typically don’t have any USB drive (or at least not one they are prepared to erase).

A way to improve the situation could be to provide them with the latest (and verified) Tails version served any time through the secure local network, that is, without the need for someone technically knowledgeable to stick around. Of course, this wouldn’t mean that the technical people would disappear; they would still be there helping as much as they can.

As long as the local network infrastructure is under control, it seems to me that this feature could benefit a bunch of such collective spaces like hackerspaces.

Let me add that I am not a Debian developer; however I have some technical knowledge and would be willing to spend some time on this.

In any case, even if the Tails development team believes this is a bad idea in view of their security model, then in addition to understanding better this security model, I’d still be interested in some explanation regarding the various changes made to the initramfs that are currently preventing from booting with PXE.

Best,

#15 Updated by beta-tester 2020-04-13 16:49:55

i got tails pxe boot working …

… kind of.

1. first of all there are no kernel drivers modules for networking in the official /live/initrd.img on tails.
to solve that issue, i have to create an additional initrd.img that contains all the missing modules and overlay it to the original initrd.img.
> 1’st, boot into tails from an USB/DVD image
> 2’nd, open a terminal window and create the custom initrd.img with:
>

<code class="sh">
find /lib/modules/$(uname -r)/kernel/drivers/net/phy/ /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/ -type f -print0 | \
cpio --null --create --verbose --format=newc | \
gzip --best > /tmp/tails-net.img
</code>

> 3’rd, copy that /tmp/tails-net.img file to your PXE-server.
> 4’th, look with lsmod, what kernel drivers modules were loaded for your network and with modinfo its dependencies. in my case it was libphy, realtek, r8169

2. then i have to put the tails-net.img file to a place, where the pxe-client will have access to, to be able to load the file.

3. then you have to add the tails-net.img for the INITRD entry of the pxe-menu as last additional file.

<code class="text">
LABEL tails-x64
    MENU LABEL Tails x64 (start network by hand)
    KERNEL http://192.168.1.1/srv/nfs/tails-x64/live/vmlinuz
    INITRD http://192.168.1.1/srv/nfs/tails-x64/live/initrd.img,http://192.168.10.193/srv/nfs/tails-net.img
    APPEND fetch=http://192.168.1.1/srv/nfs/tails-x64/live/filesystem.squashfs ro boot=live config break \
live-media=removable nopersistence noprompt timezone=Etc/UTC block.events_dfl_poll_msecs=1000 noautologin \
module=Tails slab_nomerge slub_debug=FZP mce=0 vsyscall=none page_poison=1 init_on_alloc=1 init_on_free=1 mds=full,nosmt
    TEXT HELP
        Boot to Tails x64 Live
        You have to start network by hand
    ENDTEXT
</code>

it is important, that the option break is in the APPEND list, because the network isn’t loading the modules automatically.
(the \ means, that there is a line-break. you have to remove the \ so the APPEND is one singel long line)

4. now i can pxe-boot my pxe-client into tails.

5. the boot process will break into a initramfs console just before the init process will mount any devices.
because the network kernel drivers modules are not loaded automatically, i have to do it by hand now.
in my case libphy, realtek, r8169:

<code class="text">
insmod /lib/modules/$(uname -r)/kernel/drivers/net/phy/libphy.ko
insmod /lib/modules/$(uname -r)/kernel/drivers/net/phy/realtek.ko
insmod /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/r8169.ko
</code>

6. the fetch=... procedd will use wget to load the filesystem.squashfs. but for unknown reason in the original initrd.img of tails /bin/wget was replaced by a script that expects a running torsocket. at this time there is no torsocket active. so i have to change the script to use the wget from busybox.
and just after the filesystem.squashfs was fetched i have to “revert” every network related stuff i manually loaded.
so putting all together to the new /bin/wget script. to create the script from the console type in:

<code class="text">
cat << EOF > /bin/wget
#!/bin/sh
unset http_proxy
unset HTTP_PROXY
unset https_proxy
unset HTTPS_PROXY

busybox wget --passive-ftp "\$@"

# bring down the network interface
ip link set eth0 down

#unload network kernel drivers modules
rmmod /lib/modules/\$(uname -r)/kernel/drivers/net/phy/libphy.ko
rmmod /lib/modules/\$(uname -r)/kernel/drivers/net/phy/realtek.ko
rmmod /lib/modules/\$(uname -r)/kernel/drivers/net/ethernet/realtek/r8169.ko
EOF
</code>

don’t worry, after the pxe boot is finished, the changed /bin/wget script is overwritten back to the original tails one.

7. now i can type exit to the initramfs console and the boot process will continue:
> it initialize the network,
> then it will fetch the filesystem.squashfs by using our wget script,
> and our wget script shuts down the network interface and unload the modules after its use.

8. now you should be in tails welcome screen.

conclusion/issues:

• there is the issue, that even i provide the missing network kernel drivers modules they don’t will be loaded automatically. i have no knowledge, how to load those modules automatically.
• the next issue is that in the initrd.img the /bin/wget is replaced by a script that expects torsocket. at initrd, i don’t see a reason, why it is not using the default wget, because at boot process we are in our local network of trust.
• the last issue is, why do i need to shutdown the network interface before tails finishes booting to get tails & tor working?
• with fetch=... tails behaves like booted from a DVD as read-only. none of the changes will stay persistent. (it is not an issue)
• tails ignores the following boot options locales=de_DE.UTF-8 keyboard-layouts=de. it would be nice, when tails would put those settings into account of the welcome screen as presets for language and keyboard preferences like Debian is doing.

i really would like to get tails pxe-booting out of the box. so i can pxe-boot tails from my RaspberryPi, that acts as a PXE-Server https://github.com/beta-tester/RPi-PXE-Server .
i have no knowledge to fix the issues above, but i hope one of the developer could help, so that it is not necessary to add the modules by hand and changing the wget script…

#16 Updated by beta-tester 2020-04-13 17:26:40

i forgot to tell…
i tested the solution above with tails-amd64-4.5.iso

#17 Updated by patpat 2020-04-13 18:20:42

Hi Guys

For an “automated” PXE boot of Tails 4.4.1 and 4.5 please see:
https://www.vercot.com/~serva/an/NonWindowsPXE3.html

As Beta-tester mentioned before the original initrd does not include the net drivers but they can be obtained from the initrd within
https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-cinnamon.iso
Kernel=5.4.0-4-amd64
The previous link is a weekly build then the version of the included kernel will surely change in the future.

The approach is creating a complementary INITRD_N26.5.GZ that:

1. includes all the missing net drivers
2. calls kmod version of depmod (allows the kernel to automatically load the corresponding net driver/s when needed)
3. replaces wget script (no need to recreate the original after the init script finishes calling “run-init” (sort of chroot))
4. erase the net driver black list
5. etc

It works very well, but the testing was limited.

#18 Updated by beta-tester 2020-04-13 20:46:30

@patpat, thank you for the information with the black-list and kmod…
and i didn’t realized, that om the webpage of “Serva PXE” the tails version 4.5 is uptodate now.

i would prefere to take all the original files from the same source from the tails iso to be sure everything matches.

i can extract the missing modules files directly from the /live/filesystem.squashfs of the tails iso by using the squashfs-tools on the PXE-server.
(skipping my steps 1.1. to 1.4. above)
in my case:

<code class="text">
sudo unsquashfs -d /tmp/tails-net -f /srv/nfs/tails-x64/live/filesystem.squashfs -e /lib/modules/5.4.0-4-amd64/kernel/drivers/net/phy -e /lib/modules/5.4.0-4-amd64/kernel/drivers/net/ethernet
</code>

and from there:

<code class="text">
cd /tmp/tails-net; find . -type f -print0 | cpio --null --create --verbose --format=newc | gzip --best | sudo tee /tmp/tails-net.img &>/dev/null
</code>

maybe i make things unnecessarily more complicated… :|

#19 Updated by beta-tester 2020-04-14 17:42:37

@patpat: i tried the INITRD_N26.5.GZ from the serva webpage, but i run into a kernel panic at some point.
and i also always prefer to not download a modified initrd image from somewhere… specially not for tails.

everything should be transparent, to see, that is in that initrd image…
so i tried to make my own better version…

update
here a script to create an modified initrd image with the additional network kernel drivers modules.

the script expects a mounted tails-4.5 ISO image.
and that you have the following packages installed
squashfs-tools (for unsquashfs), initramfs-tools (for cpio) and xz-utils (for xz).

<code class="text">
#!/bin/sh

# requires:
#   squashfs-tools  (unsquashfs)
#   initramfs-tools (cpio)
#   xz-utils        (xz)


# place, where to store temporary files
TMP=/tmp/tails-net

# place, where the tails ISO image is mounted    
SRC=/srv/nfs/tails-x64

# place, where the hotfix-pxe image will be stored
DST=/srv/nfs/tails-x64-hotfix-pxe.cpio.xz

# kernel version of tails
KVER=5.4.0-4-amd64


# extract missing network kernel drivers modules from tails
sudo unsquashfs \
    -d $TMP \
    -f $SRC/live/filesystem.squashfs \
    -e /lib/modules/$KVER/kernel/drivers/net/phy \
    -e /lib/modules/$KVER/kernel/drivers/net/ethernet \
    ;

sudo mkdir $TMP/usr/
sudo mv $TMP/lib $TMP/usr/ 


# add hotfix for pxe boot 
sudo mkdir -p $TMP/scripts/init-top/
sudo cat << EOF | sudo tee $TMP/scripts/init-top/hotfix-pxe-init &>/dev/null
#!/bin/sh

# comment out all blacklist entries
sed "s/^install/# install/g" -i /etc/modprobe.d/all-net-blacklist.conf

# replace wget script by busybox, for normal behavior
ln -sf /bin/busybox /usr/bin/wget

# replace depmod, for normal behavior
ln -sf /bin/kmod /usr/sbin/depmod

# rebulid dependencies for added network kernel drivers modules 
depmod -b /usr
EOF
sudo chmod +x $TMP/scripts/init-top/hotfix-pxe-init

# enqueue hotfix script to be executed as very first 
sudo cat << EOF | sudo tee $TMP/scripts/init-top/ORDER &>/dev/null
/scripts/init-top/hotfix-pxe-init "\$@"
[ -e /conf/param.conf ] && . /conf/param.conf
/scripts/init-top/all_generic_ide "\$@"
[ -e /conf/param.conf ] && . /conf/param.conf
/scripts/init-top/blacklist "\$@"
[ -e /conf/param.conf ] && . /conf/param.conf
/scripts/init-top/keymap "\$@"
[ -e /conf/param.conf ] && . /conf/param.conf
/scripts/init-top/udev "\$@"
[ -e /conf/param.conf ] && . /conf/param.conf
EOF


# create an image to overlay at boot time 
sudo rm $DST
cd $TMP
find . -type f -print0 | cpio --null --create --verbose --format=newc | xz --compress --extreme --check=crc32 | sudo tee $DST &>/dev/null
cd -


# clean up temporary files
sudo rm -rf $TMP
</code>

and this is the pxe menu

<code class="text">
LABEL tails-x64
  MENU LABEL Tails x64
  KERNEL http://192.168.1.1/srv/nfs/tails-x64/live/vmlinuz
  INITRD http://192.168.1.1/srv/nfs/tails-x64/live/initrd.img,http://192.168.1.1/srv/nfs/tails-x64-hotfix-pxe.cpio.xz
  APPEND fetch=http://192.168.1.1/srv/nfs/tails-x64/live/filesystem.squashfs ro boot=live config live-media=removable ipv6.disable=1 \
nopersistence noprompt timezone=Etc/UTC block.events_dfl_poll_msecs=1000 noautologin module=Tails slab_nomerge slub_debug=FZP mce=0 \
vsyscall=none page_poison=1 init_on_alloc=1 init_on_free=1 mds=full,nosmt
  TEXT HELP
    Boot to Tails x64 Live
  ENDTEXT
</code>

but there is still one issue i have…
after you passed the welkome screen, TOR does not activates. you have to turn off the network interface and turn it on again, then TOR will activate after few seconds.
i don’t know, what is going on there / why i have to do it to get TOR working.
maybe someone can explaine what is missing there.

#20 Updated by patpat 2020-04-14 18:05:07

I have used INITRD_N26.5.GZ and never gave a kernel panic; can you identify where/when it does it?

Regarding transparency you can easily open INITRD_N26.5.GZ and see all its internals; there’s not any secret there.

Regarding your own initrd attempt there are other patches in INITRD_N26.5.GZ regarding
1) networking; i.e. Debian does not consider if you are performing an ipconfig on a bootp or dhcp environment
2) 1) needs the parsing of a new kernel command line parameter defining bootp or dhcp
3) scripts at usr/lib/live/boot/* from Tails initrd do not produce a PXE booting initrd; just used Debian’s instead from he link I quoted before
4) it could be something else just look the INITRD_N26.5.GZ internals

#21 Updated by beta-tester 2020-04-14 22:37:39

i used the boot options from the pxe-menu above.
but instewad of using my initrd image (tails-x64-hotfix-pxe.cpio.xz) i used that initrd image INITRD_N26.5.GZ.

the kernel panic came up just after the wget would happen. wget is not downloading anything.

in INITRD_N26.5.GZ the fake /usr/bin/@wget@ is replaced by /usr/bin/@wc@.
so maybe the filesystem.squashfs could not be fetched so mounting failed and the kernel fell in panic

in my tails-x64-hotfix-pxe.cpio.xz i replace the fake /usr/bin/@wget@ with /usr/bin/@busybox@.
there the filesystem.squashfs file was fetched by the wget command.

#22 Updated by patpat 2020-04-14 23:38:36

Well your PXE boot options do not include the required
ipby=dhcp or ipby=bootp
as Serva does, then ipconfig will fail (3 times),
next wget will also fail, in my case saying"
ipconfig: invalid protocol `eth1`
and the run should neatly end with a Busybox prompt.
I do not see here a kernel panic but you might get it if ipconfing crashes because of its badly conformed command line.

In INITRD_N26.5.GZ the wget link pointing to Busybox is created by
cp /usr/bin/wc /usr/bin/wget
quick way to create wget link to Busybox based on wc’s
this works

just try again now adding ipby=dhcp or bootp

#24 Updated by patpat 2020-04-15 17:06:12

Are you PXE booting a multihomed client? Please try adding
ipappend = 2
to the syslinux PXE stanza

Here testing on a VMWare VM (e1000) and an HP 2570p (e100e)
Tor gets activated as soon as the GUI gets up.
But I do see some Network quirks; i.e. when initially clicking on the network
icon I see “connected to eth1” (or eth0) and also “wired connection”
clicking the last one Tor circuits are reinitialized (that’s where you get connected), the
eth0/1 connection option disappears and from that moment on I only see “Wired connection”.
Taking down the net devices and removing its corresponding drivers before init the squashfs
removes the previous behavior. This is done with a more generic code.

+for f in /sys/class/net/*; do

#set network devices down
dev=$(basename $f)
if [ “$dev” != “lo” ]; then
ip link set “$dev” down
fi

#remove used network drivers
driver=$(readlink $f/device/driver/module)
if [ $driver ]; then
driver=$(basename $driver)
modprobe -r “$driver”
fi
done+

Download the new INITRD_N26.5.GZ and give it a try.

Regarding “transparency” and “paranoia” I definatelly understand your point but
Tails team do not produce a PXE ready distro and that’s a problem.
Regarding binaries AFAIK they do not re-commpile kernels; they are Debian’s.

#25 Updated by patpat 2020-04-15 17:08:10

sorry

@for f in /sys/class/net/*; do

#set network devices down
dev=$(basename $f)
if [ “$dev” != “lo” ]; then
ip link set “$dev” down
fi

#remove used network drivers
driver=$(readlink $f/device/driver/module)
if [ $driver ]; then
driver=$(basename $driver)
modprobe -r “$driver”
fi
done@

#26 Updated by beta-tester 2020-04-15 22:38:40

@patpat, thank you for providing a generic code to shut down network interfaces and unload its modules.
thank you for your help.
i think i learned a lot.

my final solution

i redesigned my script for creating an initrd and i am very happy with it now.

it does not need to modify the /init script.
i found a location, where i can run additional scripts at a very early stage without touching/modifying any existing scripts… /conf/conf.d/.
the only thing that is a bit ugly is that i have add a function local_bottom right to the end of the existing /scripts/live script
to get rid of the network quirk issue.

but anyhow, all code is at one single spot concentrated, with no frills.
to my opinion, this is the most transparent script i was able to create, made for paranoid people…

<code class="text">
#!/bin/sh

# requires:
#   squashfs-tools  (unsquashfs)
#   initramfs-tools (cpio)
#   xz-utils        (xz)


# location, where to store temporary files
TMP=/tmp/tails-net

# full filename of the filesystem.squashfs from tails ISO
SRC=/srv/nfs/tails-x64/live/filesystem.squashfs

# full filename of the hotfix-pxe image
DST=/srv/nfs/tails-x64-hotfix-pxe.cpio.xz

# kernel version of tails
KVER=5.4.0-4-amd64


# extract missing network kernel drivers modules from tails
sudo unsquashfs \
    -d $TMP \
    -f $SRC \
    -e /lib/modules/$KVER/kernel/drivers/net/phy \
    -e /lib/modules/$KVER/kernel/drivers/net/ethernet \
    ;

# align the modules to the layout of initrd
sudo mkdir $TMP/usr/
sudo mv $TMP/lib $TMP/usr/ 



# add hotfix for pxe boot to initrd image 
sudo mkdir -p $TMP/conf/conf.d/
cat << EOF | sudo tee $TMP/conf/conf.d/1000-hotfix-pxe &>/dev/null
#!/bin/sh

# comment out all blacklist entries
sed "s/^install/# install/g" -i /etc/modprobe.d/all-net-blacklist.conf

# replace wget script by busybox, for normal behavior
ln -sf /bin/busybox /usr/bin/wget

# replace depmod, for normal behavior
ln -sf /bin/kmod /usr/sbin/depmod

# rebulid dependencies for added network kernel drivers modules 
depmod -b /usr


# append hotfix-pxe patch to live script
cat << EOT >> /scripts/live

local_bottom ()
{
    # hotfix-pxe for issue with network initialisation in tails
    for device_ in /sys/class/net/*; do
        device=\\\$(basename \\\$device_)
        if [ "\\\$device" != "lo" ]; then
            # set network devices down
            ip link set \\\$device down

            module_=\\\$(readlink \\\$device_/device/driver/module)
            if [ -n "\\\$module_" ]; then
                # remove used network drivers
                module=\\\$(basename \\\$module_)
                modprobe -r \\\$module 
            fi
        fi
    done
}
EOT
EOF
sudo chmod +x $TMP/conf/conf.d/1000-hotfix-pxe



# create an initrd image to overlay at boot time 
sudo rm $DST
cd $TMP
find . -type f -print0 | cpio --null --create --verbose --format=newc \
    | xz --compress --extreme --check=crc32 | sudo tee $DST &>/dev/null
cd -


# clean up temporary files
sudo rm -rf $TMP
</code>

#27 Updated by patpat 2020-04-16 15:53:10

ipconfig is a nasty tool and Debian networking script overlooks a couple of things.

1) we must use the -c variable defining bootp or dhcp
2) we must use ipconfig in a loop (3 times) considering it might timeout waiting for an IP specially with metal clients.
3) ipconfig can fail and quit running into recursion; in that case we must kill the left process before looping.

For all of the above if you want a robust handling of ipconfig please see our changes at:
/usr/lib/live/boot/9990-cmdline-old /usr/lib/live/boot/9990-networking.sh

@ #for interface in ${DEVICE}; do
for interface in ${DEVICE} ${DEVICE} ${DEVICE}; do
#ipconfig -t “$ETHDEV_TIMEOUT” “${interface}” | tee “/netboot-${interface}.config”
ipconfig -t “$ETHDEV_TIMEOUT” -c $IPBY “${interface}” | tee “/netboot-${interface}.config” &
jobid=$!
sleep “$ETHDEV_TIMEOUT” ; sleep 1
if [ -r /proc/“$jobid”/status ]
then
echo “Killing job $jobid for device $dev as ipconfig ran into recursion…”
kill –9 $jobid
fi

[ -e “/run/net-${interface}.conf” ] && . “/run/net-${interface}.conf”

if [ “$IPV4ADDR” != “0.0.0.0” ]
then
break
fi
done@

Your particular test can run OK w/o these mods but other users can easily run into
non-booting systems if they are not properly addressed.

#28 Updated by beta-tester 2020-04-16 16:58:06

ok, then it makes sense, why your changes are much moren than my and it is not frills…
sorry for that meaning before.
i still have to learn lot more.

that means not only the team Tails is careless with the support of pxe-boot but also the team Debian…
i guest the number of people is too small, that show interest in pxe-boot in general these days… :(

#29 Updated by patpat 2020-04-17 17:54:58

PXE is massively used but I found certain Linux distros do handle the topic well.
Even the small net ISOs many times fail PXE boot.

From a PXE point of view:
Ubuntu is better than Debian.
RHEL and derivatives are rock solid
etc.