https://github.com/Whonix/Whonix/commit/400827e09b3158618686b151229684f6e4fe7e85
https://github.com/Whonix/Whonix/commit/54fa6e8d1d02912c5328b619eb973e79fd83c674
In whonix-stuff/2950_create_iso_sketch at master · onions-knight/whonix-stuff · GitHub why did you put some commands into ( )?
For example
(cd $RAW_DIRECTORY/image/ && \
cp /usr/lib/ISOLINUX/isolinux.bin isolinux/ && \
cp /usr/lib/syslinux/modules/bios/menu.c32 isolinux/ && \
cp /usr/lib/syslinux/modules/bios/hdt.c32 isolinux/ && \
cp /usr/lib/syslinux/modules/bios/ldlinux.c32 isolinux/ && \
cp /usr/lib/syslinux/modules/bios/libutil.c32 isolinux/ && \
cp /usr/lib/syslinux/modules/bios/libmenu.c32 isolinux/ && \
cp /usr/lib/syslinux/modules/bios/libcom32.c32 isolinux/ && \
cp /usr/lib/syslinux/modules/bios/libgpl.c32 isolinux/ && \
cp /usr/share/misc/pci.ids isolinux/ && \
cp /boot/memtest86+.bin live/memtest
)
What is the first ( and last ) used for?
I don’t remember. I don’t think they are necessary.
Great. Therefore simplified the code https://github.com/Whonix/Whonix/commit/9b5cfadc82cca8c615ccec51112d7544f6d2cd85 (and hopefully not introduced any bugs).
Wondering about these 3 [and fortunately only] generated source files now.
- /grub-embedded.cfg
- /image/boot/isolinux/isolinux.cfg
- /image/boot/grub/grub.cfg
Is there a more suitable place for grub-embedded.cfg other than the root / directory?
Would /image/boot/grub/grub-embedded.cfg be a good place?
Can we drop /imagefrom path to be compliant with FHS?
Would it be appropriate if these 3 files were shipped by some package?
- If yes, great.
- If no: Rather than generating these source files I would prefer putting them into standalone files.
Just recognized that /boot/grub/grub.cfg is not a great idea to be owned by a package that stays installed. That would break the usual upgrade-grub mechanism during apt dist-upgrades.
/image/boot however (or otherwise) would be ok?
haven’t seen any results on that. Worth trying then see if package changes break anything.
/usr/lib/whonix-libvirt/install has some issues.
systemd partonizing
systemctl --no-pager status libvirtd
Running in chroot, ignoring request: status
And
systemctl --no-pager start libvirtd
Running in chroot, ignoring request: start
(We probably don’t want to use systemd-nspawn since we don’t want to fully boot the system We only want to selectively start a required daemon but otherwise start as few daemons as possible.)
But this can be worked around by manually starting and stopping libvirtd.
Anyhow. This is the output of /usr/lib/whonix-libvirt/install. Please let me know if the output of the virsh commands looks ok.
+ set -e
++ mktemp --directory
+ temp_dir=/tmp/tmp.WYdLjzteDc
+ cp -r /usr/share/whonix-libvirt/xml /tmp/tmp.WYdLjzteDc
+ sed -i '1 s/^.*$/<domain type='\''qemu'\''>/' /tmp/tmp.WYdLjzteDc/xml/Whonix-Gateway.xml
+ sed -i '1 s/^.*$/<domain type='\''qemu'\''>/' /tmp/tmp.WYdLjzteDc/xml/Whonix-Workstation.xml
+ systemctl --no-pager status libvirtd
Running in chroot, ignoring request: status
+ true 'libvirtd is running.'
+ virsh -c qemu:///system net-autostart default
Network default marked as autostarted
+ virsh -c qemu:///system net-start default
2019-05-13 08:12:59.025+0000: 21886: error : dnsmasqCapsRefreshInternal:733 : Cannot check dnsmasq binary /usr/sbin/dnsmasq: No such file or directory
error: Failed to start network default
error: Cannot check dnsmasq binary /usr/sbin/dnsmasq: No such file or directory
+ true
+ virsh -c qemu:///system net-define /usr/share/whonix-libvirt/xml/Whonix-External.xml
Network Whonix-External defined from /usr/share/whonix-libvirt/xml/Whonix-External.xml
+ virsh -c qemu:///system net-define /usr/share/whonix-libvirt/xml/Whonix-Internal.xml
Network Whonix-Internal defined from /usr/share/whonix-libvirt/xml/Whonix-Internal.xml
+ virsh -c qemu:///system net-autostart Whonix-External
Network Whonix-External marked as autostarted
+ virsh -c qemu:///system net-start Whonix-External
2019-05-13 08:12:59.689+0000: 21885: error : dnsmasqCapsRefreshInternal:733 : Cannot check dnsmasq binary /usr/sbin/dnsmasq: No such file or directory
error: Failed to start network Whonix-External
error: Cannot check dnsmasq binary /usr/sbin/dnsmasq: No such file or directory
+ true
+ virsh -c qemu:///system net-autostart Whonix-Internal
Network Whonix-Internal marked as autostarted
+ virsh -c qemu:///system net-start Whonix-Internal
Network Whonix-Internal started
+ virsh -c qemu:///system define /tmp/tmp.WYdLjzteDc/xml/Whonix-Gateway.xml
Domain Whonix-Gateway defined from /tmp/tmp.WYdLjzteDc/xml/Whonix-Gateway.xml
+ virsh -c qemu:///system define /tmp/tmp.WYdLjzteDc/xml/Whonix-Workstation.xml
Domain Whonix-Workstation defined from /tmp/tmp.WYdLjzteDc/xml/Whonix-Workstation.xml
+ '[' '' = true ']'
+ mkdir --parents /var/lib/whonix-libvirt
+ touch /var/lib/whonix-libvirt/install.doneI am not sure what you mean here. These files are configuration files for grub/syslinux in the iso. They are generated in the build environment only, i.e. in the $RAW_DIRECTORY, which can be whatever the build script wants it to be. It is not the root / directory of the target (nor the build system).
This is how the iso content looks like:
.
├── boot
│ ├── grub
│ │ └── grub.cfg
│ └── isolinux
│ ├── cat.c32
│ ├── chain.c32
│ ├── cmd.c32
│ ├── cmenu.c32
│ ├── config.c32
│ ├── cptime.c32
│ ├── cpu.c32
│ ├── cpuid.c32
│ ├── cpuidtest.c32
│ ├── debug.c32
│ ├── dhcp.c32
│ ├── disk.c32
│ ├── dmi.c32
│ ├── dmitest.c32
│ ├── elf.c32
│ ├── ethersel.c32
│ ├── gfxboot.c32
│ ├── gpxecmd.c32
│ ├── hdt.c32
│ ├── hexdump.c32
│ ├── host.c32
│ ├── ifcpu64.c32
│ ├── ifcpu.c32
│ ├── ifmemdsk.c32
│ ├── ifplop.c32
│ ├── isolinux.bin
│ ├── isolinux.cat
│ ├── isolinux.cfg
│ ├── kbdmap.c32
│ ├── kontron_wdt.c32
│ ├── ldlinux.c32
│ ├── lfs.c32
│ ├── libcom32.c32
│ ├── libgpl.c32
│ ├── liblua.c32
│ ├── libmenu.c32
│ ├── libutil.c32
│ ├── linux.c32
│ ├── ls.c32
│ ├── lua.c32
│ ├── mboot.c32
│ ├── meminfo.c32
│ ├── menu.c32
│ ├── pci.c32
│ ├── pcitest.c32
│ ├── pmload.c32
│ ├── poweroff.c32
│ ├── prdhcp.c32
│ ├── pwd.c32
│ ├── pxechn.c32
│ ├── reboot.c32
│ ├── rosh.c32
│ ├── sanboot.c32
│ ├── sdi.c32
│ ├── sysdump.c32
│ ├── syslinux.c32
│ ├── vesa.c32
│ ├── vesainfo.c32
│ ├── vesamenu.c32
│ ├── vpdtest.c32
│ ├── whichsys.c32
│ └── zzjson.c32
├── EFI
│ ├── boot
│ │ └── bootx64.efi
│ └── efiboot.img
├── isolinux
│ ├── hdt.c32
│ ├── isolinux.bin
│ ├── ldlinux.c32
│ ├── libcom32.c32
│ ├── libgpl.c32
│ ├── libmenu.c32
│ ├── libutil.c32
│ ├── menu.c32
│ └── pci.ids
└── live
├── filesystem.squashfs
├── initrd
└── vmlinuz
And this is the root filesystem in the filesystem.squashfs file:
bin home lib64 nonexistent run tmp vmlinuz.old
boot initrd.img lost+found opt sbin usr
dev initrd.img.old media proc srv var
etc lib mnt root sys vmlinuz
There is no
/grub-embedded.cfg
/image/boot/isolinux/isolinux.cfg
/image/boot/grub/grub.cfg
there.
Ah, cool!
Note to self:
From whonix-stuff/2950_create_iso_sketch at master · onions-knight/whonix-stuff · GitHub
where does $RAW_DIRECTORY/grub-embedded.cfg end up currently?
From whonix-stuff/2950_create_iso_sketch at master · onions-knight/whonix-stuff · GitHub
$RAW_DIRECTORY/image/boot/isolinux/isolinux.cfg
From whonix-stuff/2950_create_iso_sketch at master · onions-knight/whonix-stuff · GitHub
$RAW_DIRECTORY/image/boot/grub/grub.cfg
Alright, I got that wrong.
Looks really good!
As a side note - good info here on syslinux, also how to customize the boot menu (allows for some graphical customization):
https://wiki.archlinux.org/index.php/syslinux
Just instead of syslinux.cfg we want to modify the isolinux.cfg file.
Currently reading up on isolinux also, might be useful:
https://wiki.syslinux.org/wiki/index.php?title=ISOLINUX
(examples with mkisofs are now deprecated. we use xorriso -as mkisofs instead)
And this is the full command used by debian to generate debian-9.3.0-amd64-netinst.iso (see RepackBootableISO - Debian Wiki)
xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1,sha256,sha512
-V 'Debian 9.3.0 amd64 n'
-o /srv/cdbuilder.debian.org/dst/deb-cd/out/2amd64/debian-9.3.0-amd64-NETINST-1.iso
-jigdo-jigdo /srv/cdbuilder.debian.org/dst/deb-cd/out/2amd64/debian-9.3.0-amd64-NETINST-1.jigdo
-jigdo-template /srv/cdbuilder.debian.org/dst/deb-cd/out/2amd64/debian-9.3.0-amd64-NETINST-1.template
-jigdo-map Debian=/srv/cdbuilder.debian.org/src/ftp/debian/ -jigdo-exclude boot1
-md5-list /srv/cdbuilder.debian.org/src/deb-cd/tmp/2amd64/stretch/md5-check
-jigdo-min-file-size 1024 -jigdo-exclude 'README*' -jigdo-exclude /doc/
-jigdo-exclude /md5sum.txt -jigdo-exclude /.disk/ -jigdo-exclude /pics/
-jigdo-exclude 'Release*' -jigdo-exclude 'Packages*' -jigdo-exclude 'Sources*'
-J -J -joliet-long -cache-inodes
-isohybrid-mbr syslinux/usr/lib/ISOLINUX/isohdpfx.bin -b isolinux/isolinux.bin
-c isolinux/boot.cat -boot-load-size 4 -boot-info-table -no-emul-boot
-eltorito-alt-boot -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat
-isohybrid-apm-hfsplus boot1 CD1
Might be useful to study this awfully long command (link above describes it all). Not saying we need all this stuff though (it works as it is now).
chroot $CHROOT_DIRECTORY mkdir /var/log/tor
chroot $CHROOT_DIRECTORY chown -R debian-tor:adm /var/log/tor
Why would that be required? I guess let’s be adventurous, try to drop this?
(Otherwise we can add to https://github.com/Whonix/whonix-initializer/blob/master/usr/lib/anon-dist/chroot-scripts-post.d/80_cleanup.)
As far as I remember by default on debian the Tor log directory is owned by debian-tor:adm. When we empty the /var/log/ directory we need to recreate the tor directory with right owner and group permissions otherwise Tor will fail to start. Maybe it has changed. Or maybe you already have better options to clean the build target at the end of the build process?
The way to clean the build image is to not make it dirty in the first place as much as possible. By not starting any daemons inside it as far as possible. And also https://github.com/Whonix/whonix-initializer/blob/master/usr/lib/anon-dist/chroot-scripts-post.d/80_cleanup. Just now checked. In my build (still only raw image) permissions are ok.
I guess this was an issue for you since you booted the image and made changes manually? That would explain /home/user/.Xauthority which I never saw before.
Running the virsh commands to import KVM XML files in chroot remains to be a challenge but maybe I got it now.
Yes, you are right, I must have booted it or started X services therefore the .Xauthority file.
There is no reason the cleaning part should any different from classic Whonix builds.
The difference with other builds is that in the “Desktop” version libvirtd needs however to be started in order to configure the VMs.