You are not logged in.
Pages: 1
He's dead nuts on. I knew years ago that Poettering was an MS fanboy. "Let's build a huge, undocumented, all-encompassing pile of shit, polish it, market it as the best thing since sliced bread, and slowly take over the Linux world." Wannabe Roman, except he doesn't have the fortitude. The Romans didn't conquer territories; rather, they killed all who opposed them and filled the void.
Before I ever willingly work with systemd, I'll extend sysvinit to do what systemd was supposed to do: provide fast system startup and better daemon monitoring. Systemd is the same as every other project/device/invention where the inventor decided it would become all things to all people, but ends up doing very little mediocrely for most people.
NetworkMangler has its place: non-experts who just want networking to work. I sometimes add 1 or 100 or 1000 primary and secondary IP addresses to an IF for testing. The Mangler says, "Hey! I didn't put these addresses here! Delete! Delete! Delete! Hey! If you want to make a change to networking, *ASK ME*! Don't try to go around me!"
I used to jokingly quip, "How may I hinder you today?" I never realized a few loudmouthed bullies would take it to heart (or whatever they have that passes for one).
MHO.
I haven't tried this, but it ought to work: https://gist.github.com/shamil/62935d9b456a6f9877b5.
In short:
modprobe nbd
Create the QCOW2 image same (virtual) size as the HD.
Connect to the QCOW2 (see link above).
Mount the HD's filesystems.
On each of these FSen, dd if=/dev/zero of=null.zero bs=1024k; sync; rm null.zero to use up all free blocks, fill them with nulls, then erase the file. Neither perfect nor complete, but it'll zero most free blocks. You will have to <CTRL/C> dd if it doesn't quit when it exhausts free space. (This'll work on all FSen, not just EXT[234].) Also be aware that some FSen may still have limits on the maximum file size; you might have to create several nullX.zero files.
Unmount the HD's filesystems.
As root, dd --sparse the raw HD device to the QCOW2 NBD device.
Disconnect from the QCOW2 (see link above)
rmmod nbd
Given the price and size of storage these days (and sufficient funds), it might be better to buy a large SSD or NVME and copy the HD onto a corner of it. If, of course, the above doesn't work well.
Whichever way you use, it will take quite some time. 500GB at 1.5 Gb/s ain't fast. And you're doing it twice (once to zero free blocks, and again to copy the drive).
What's the shortest book ever published?
"1,000 Years Of German Humor"
What's the name of the Irishman sitting on the back deck?
Paddy O'Furniture.
What do you call three Irishmen sitting on a lawn?
Fertilizer.
[I type a lot and have lots of thoughts, so this will be kind-of long.]
I'm the Smoothwall Express project leader. I had the temerity back in the early teens to modernize v3.0; in 2014, the project was plopped in my lap. Oops; I was just trying to be a nice guy. I updated much of the software (around 250 packages), fixed many latent bugs (many found while looking for something else [scroll, scroll, scroll, wait, what was that? Off-by-one? Oho! *That* explains that instability. Fix. Now where was I?]), fixed and twerked the web UI, made the build system re-entrant, make it installable and usable in VMs, and did other things. Through 11 updates in the following six years. The result has been a rock-stable firewall that runs for years without problems (for most users; a few have encountered oddities that I haven't yet figured out).
Smoothwall Express is a purpose-built firewall. The software is deliberately limited to minimize attack vectors. It was, and continues to be, designed for non-experts to use.
I'm attempting to 'port' Smoothwall Express to Devuan for two primary reasons. I despise systemd and the black hole it has become. Second, I just can't keep up with the changes to foundation pkgs (binutils, gcc, linux, etc.); it takes me far too long to update them. In time, I'll create a derivative of Devuan that is a, mmm, subset of Devuan, but makes use of Devuan's security updates.
So, I want to use Devuan. And it hasn't been so easy. I'm finally making some progress in making a smoothwall-express .deb that has dependencies for everything it uses by default (the usual instruction in the Debian documentation is 'find a similar package and adapt it for your purpose' which is rather less than useful. Alas, there are no pkgs (that I've found) similar to what I want to do. Debuild creates a .deb that mostly works; presently it stumbles when it tries to replace files that other pkgs have installed (inittab, dnsmasq.conf, et alia). Is there a recommended way to do that without having to worry about updates wiping out my changes?
Eventually, I'll have to change a lot of stuff to do it 'the modern way'. (It was open-sourced over 20 years ago, and sort-of based on linux-from-scratch.) For now, I'm trying to avoid having to do *everything* all at once. There are a few smoothwall-specific programs in use; the UI handles most of the daemon/feature controls via a setuid daemon that restricts access to things that require root access.
There is no desktop environment; I'd even eliminate dbus if I could. There are two users defined: 'root' and 'nobody'. I wish to build on others' work (Devuan) so I can concentrate on improving and expanding the firewall and filter capabilities.
So, are there any references that would help me figure out how to do what I'm trying to accomplish? Words of wisdom? Words of encouragement?
Neal
----
One thing I've been pondering for more than a few years is to extend sysvinit. The first computer I bought, in 1986, was an AT&T UNIX PC (SysV, demand-paged virtual memory, loadable drivers, etc.); I taught myself UNIX, C and KSH on it (which took a while because they are very different from TOPS-20, AOS/VS and VMS and the languages I knew up to that point). I've often wondered why no one ever used sysvinit the way it was intended: to start and control daemons and keep them running. Rather, they just used the Berzerkely way.
Extend inittab's 'ID' field to near-arbitrary length so daemons can be referenced by their names
Expand the run levels to 256 (levels 2-5 and 7-10 would be dead; 0, 1 and 6 would retain their traditional meanings)
All daemons in a run level would be started in parallel
Add command line options to init/telinit to stop/start/restart/enable/disable daemons, and extend that field in inittab
&cetera
This would, of course, mean that daemons would not be allowed to daemonize themselves; their stdout and stderr would have to be dumped or directed to log files. Signals would have to be well-handled so daemons cannot interfere with each other. I know, 'tis a silly notion.
Once the installer gave up and fell into a command prompt, I looked and verified that /lib/modules/XXXX/kernel/drivers/virtio/ is missing. But .../block/virtio_blk.ko and .../scsi/virtio_scsi.ko *are* present.
Peculiar. I just looked in the ISO's initrd.gz; the .../drivers/virtio directory is there and populated. Is something erasing it after boot?
*What* the message means: when the installer wrote the new partition table to the SSD, the usual course of events is to inform the kernel that that drive's partition table changed so that the kernel can trigger actions to ensure that the nodes in /dev are updated. I don't know *why* it sometimes fails, but I have seen it on occasion.
You might try restarting the installer after that happens. If the partition table is as you set it last time, don't write the changes (i.e., use the drive as-is). (I *think* this is possible.)
Once the installer gave up and fell into a command prompt, I looked and verified that /lib/modules/XXXX/kernel/drivers/virtio/ is missing. But .../block/virtio_blk.ko and .../scsi/virtio_scsi.ko *are* present.
Here's my qemu command for VIRTIO (used to boot ISO and HD):
qemu-system-x86_64 \
-nographic \
-machine type=q35,accel=kvm,smm=on \
-cpu host \
-smp 4 \
-device virtio-scsi-pci \
-drive if=none,file=/media/envme/vdisk.d/vm26-working.qcow2,index=0,id=gvd0 \
-device scsi-hd,serial=1110,drive=gvd0 \
-drive if=none,format=raw,file=/kvm/iso.d/devuan_daedalus_5.0.0_amd64_netinstall.iso,index=5,id=gsr0,readonly=on \
-device scsi-cd,drive=gsr0,serial=1120 \
-drive if=none,format=raw,file=/dev/sr0,index=6,id=gsr1,readonly=on \
-device scsi-cd,drive=gsr1,serial=1121 \
-nic tap,ifname=tapRD001a,script=/etc/network/qemuUP,downscript=/etc/network/qemuDOWN,model=virtio-net-pci,mac=52:54:00:00:1a:00 \
-nic tap,ifname=tapGN001a,script=/etc/network/qemuUP,downscript=/etc/network/qemuDOWN,model=virtio-net-pci,mac=52:54:00:00:1a:01 \
-nic tap,ifname=tapOR001a,script=/etc/network/qemuUP,downscript=/etc/network/qemuDOWN,model=virtio-net-pci,mac=52:54:00:00:1a:02 \
-nic tap,ifname=tapPU001a,script=/etc/network/qemuUP,downscript=/etc/network/qemuDOWN,model=virtio-net-pci,mac=52:54:00:00:1a:03 \
-serial tcp:127.1.26.1:23,server=on,wait=off,nodelay \
-chardev socket,id=mon_26,port=23,host=127.1.26.2,ipv4=on,server=on,wait=off,telnet=on \
-mon chardev=mon_26 \
-display vnc=:26,share=ignore \
-device qemu-xhci,id=xhci1 \
-nodefaults \
-name 'iso:Smoothwall-Devuan Daedalus Testing' \
-boot menu=on \
-m 2048 \
-vga std \
-rtc clock=vm,base=localtime \
-device usb-tablet,bus=xhci1.0
I found that the x86_64 netinst ISO doesn't boot in qemu when using VIRTIO or AHCI. In fact, none of the block devices are there. When I switched to SCSI (lsi53c895a), the install proceeded. And the resulting installed system boots OK using VIRTIO, SCSI and AHCI.
To be specific, the install menu appears and the installer tries to run, but it cannot find the CD/ISO to mount it. And I am not using UEFI (haven't figured out how to tell qemu to use it).
I suspect something may be missing from the initramfs.
[ Update: I finally converted my VM startup script from IDE to AHCI. The installer does start with AHCI. Looks like just the VIRTIO stuff may be missing from the initramfs.]
Pages: 1