PartialVolume
Client Networking support
I cannot get networking to work with the Dell R510, R210 II or the R710, but it works fine on the 720 and 720xd and intermittently on others. We have a lot of each of these and the absence of functional networking is consistent across all. What's odd is that the network interface (all of them) are very clearly visible in the OS. I feel like it's somehow tied to the S40 network script, but I don't understand what you're doing well enough to tweak it to make it work. If it's some sort of driver issue, it'd be stellar if there were some manner of guidance as to how to include them with the build. The inner workings of buildroot are somewhat beyond my current reach.
Could be a missing driver, I'll take a look at the hardware specs and get back to you.
FYI: ifconfig -a presents 4x eth (0-3), loopback, and sit0
On Thu, May 26, 2022, 9:38 AM PartialVolume @.***> wrote:
Could be a missing driver, I'll take a look at the hardware specs and get back to you.
— Reply to this email directly, view it on GitHub https://github.com/PartialVolume/shredos.x86_64/issues/105#issuecomment-1138590348, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSYFM5MFDAX3G2Q5W65ZQ3VL55GXANCNFSM5XBCQYGQ . You are receiving this because you authored the thread.Message ID: @.***>
No that's fine, thanks. I'll follow up shortly with a few extra commands so we can figure out what the issue is.
Can you plug in a network lead into either eth0 or eth1 (but not both) and run the following command
more /etc/network/interfaces
And post the output.
All the ethx devices listed in the output you previously posted should all be present, i.e eth0 and eth1 in /etc/network/interfaces.
Also the -1 in ls -1 /sys/class/net was a numeric 1 not a lower case L so the output should not have been a long listing but should have been..
eth0
eth1
lo
site
You may want to rerun that command ls -1 /sys/class/net and check it is outputing the devices in the format above.
If /etc/network/interfaces does indeed contain eth0 and eth1 then we'll look at device link status values which tell us whether we have an uplink.
Make sure you only connect one network lead during these tests. ShredOS will only work with one network cable connected. At least I've only tested it with one.
ls -1 came up as expected Results of 'more' follow. This machine was booted via pxe from the same server hosting the ftp server. This is the typical post-boot network outcome for my PowerEdges from this gen booting shredos.
sh-5.1# more /etc/network/interfaces
# interface file auto-generated by buildroot
auto lo
iface lo inet loopback
Interesting, just the fact that the line interface file auto-generated by buildroot even exists in /etc/network/interfaces means we are never even getting to the third command rm /etc/network/interfaces in the script.
So there are a few possibilities:
- The script never starts.
- The script starts but fails before it gets to the command that removes the /etc/network/interfaces file and therefore the script exits. This can be prevented, I should really have a
set +eat the beginning of the script to prevent it exiting on failure and I should really test the exit codes of ifdown, ifup and rm.
Edit /usr/bin/shredos_net.sh and put set +e after the first line. Kill shredos_net.sh if it's still running then restart it with /usr/bin/shredos_net.sh, unplug a network lead give it a few seconds then plug it back in. Look at /etc/network/interfaces see if it contains any references to ethx devices. If it does check /sbin/ifconfig for a valid IP address assigned via your DHCP router.
On a working system /etc/network/interfaces should look like this, consisting of 5 lines , the third line being empty. The contents of this file is altered dynamically by shredos_net.sh and will alter each time you unplug and plug into a different ethernet port. So references to eth0 may change to eth1/eth2/eth3/enp0 etc depending upon which ethernet port you are plugging into.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
Also check /usr/bin/shredos_net.sh is actually running using ps -ef | grep -i shredos_net.sh If it is running you should see something similar to ..
158 root {shredos_net.sh} /bin/bash /usr/bin/shredos_net.sh
After killing /usr/bin/shredos_net.sh, assuming it was running and then having edited /usr/bin/shredos_net.sh by putting set +e on the second line. Rerunning it from the command line cd /usr/bin;shredos_net.sh should give you a lot more info about what it's doing. On a working system it should look like this..
sh-5.1# shredos_net.sh
[OK] eth0 is down
more: read error: Invalid argument
udhcpc: started, v1.33.1
udhcpc: sending discover
udhcpc: sending select for 192.168.0.70
udhcpc: lease of 192.168.0.70 obtained, lease time 86400
deleting routers
adding dns 192.168.0.254
[OK] eth0 is up
Following on from my previous comment, with shredos_net.sh running in the terminal try unplugging the network lead and monitor the messages as shown above. If there are no messages, check shredos_net.sh is running with the command ps -ef | grep -i shredos_net.sh. Hopefully any messages that appear should give us a clue to any problems.
Ok, so 2 things. First I need to clean up (and am mortified by the fact) that the results I sent you (second half) were from having tinkered with the config in an attempt to remedy the matter. So, unfortunately, the problem is probably not as interesting and I apologize for all the time you spent on an amazingly detailed and precise response. Here are the correct results.
Now, on a separate topic, I just spent several weeks crafting a beautiful interactive wrapper around nwipe only to be completely thwarted by the buildroot (or some aspect of it) environment. Pause won't count down unless a key is being pressed, for example, and pieces of my code that work perfectly on my dev machine won't work at all on there, which is so odd since I'm using the same version of bash. Viz:
If there is anything important that differentiates buildroot from bash in a desktop environment (perhaps the reason you crafted the network the way you did), your insights would be much appreciated.
If you want to post the wrapper script or modified launcher I'm happy to take a look. If the bash versions are the same I would imagine it might have something to do with the bash environment being different.
Will do, the most basic example I can offer is dialog --pause. Even without my wrapper, just inserted from the command line, it doesn't count down, at all. I managed to figure my way through some of the stuff by wrapping certain calls in more parentheses, lol, but the pause counter won't work no matter what I try: dialog --pause "test of the dialog pause box" 30 30 30 Only counts down if you move the cursor back and forth across the options (not the expected behavior)
Yes, that is useful. I'll boot up my system and take a look at that -f option and the read error.
I'll put together a wrapper I think would be useful to the general public and send it over. What I've put together is extremely use-case specific.
On Sat, Jun 18, 2022, 5:30 AM PartialVolume @.***> wrote:
Yes, that is useful. I'll boot up my system and take a look at that -f option and the read error.
— Reply to this email directly, view it on GitHub https://github.com/PartialVolume/shredos.x86_64/issues/105#issuecomment-1159407500, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSYFM3KEM7Z5HVDLGQ4G3LVPWJJRANCNFSM5XBCQYGQ . You are receiving this because you authored the thread.Message ID: @.***>
@gputils This is odd. When I run ifdown -h it shows the available options, one of which is -f Force. If I run which -a ifdown it lists two locations which the binary exists at, both however are the same binary and version which were verified with sha1sum.
When you get a chance can you run ifdown -h on the command line and confirm it says -f is actually an option. Thanks. I'm not seeing those ifdown: invalid option --- 'f' errors in my nohup.out file.
Here's what I'm seeing for my version of ifdown.
# ifdown -h
ifdown: invalid option -- 'h'
BusyBox v1.33.1 (2022-01-26 22:36:58 GMT) multi-call binary.
Usage: ifdown [-nmvf] [-i FILE] -a | IFACE...
-a Deconfigure all interfaces
-i FILE Use FILE instead of /etc/network/interfaces
-n Dry run
(note: doesn't disable mappings)
-m Don't run any mappings
-v Print out what would happen before doing it
-f Force
#
This is what my nohup.out file looks like when I disconnect and reconnect the RJ45 network connector.
# tail -f nohup.out
more: read error: Invalid argument
udhcpc: started, v1.33.1
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending select for 192.168.0.75
udhcpc: lease of 192.168.0.75 obtained, lease time 86400
deleting routers
adding dns 192.168.0.254
[OK] eth0 is up
[OK] eth0 is down
more: read error: Invalid argument
udhcpc: started, v1.33.1
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending select for 192.168.0.75
udhcpc: lease of 192.168.0.75 obtained, lease time 86400
deleting routers
adding dns 192.168.0.254
[OK] eth0 is up
I've been compiling from the newest distro of buildroot but I've had this problem on multiple machines even when I was using the stock shredos distro in February when I was bulk wiping machines for disposal. I wanna say over half the machines I ran shut down after wiping with no upload, and I ran a hodgepodge of models of over 100 desktops. The ones that worked, worked consistently, for the most part. oddly enough, I have encountered this problem -intermittently- on certain machines I've had running in production and R&D. Specifically with the PowerEdge R210 II, I think. Anyway, I'll go ahead and check. The R720 works very reliably without the error.
On Sun, Jun 19, 2022, 3:21 PM PartialVolume @.***> wrote:
Here's what I'm seeing for my version of ifdown.
ifdown -h
ifdown: invalid option -- 'h' BusyBox v1.33.1 (2022-01-26 22:36:58 GMT) multi-call binary.
Usage: ifdown [-nmvf] [-i FILE] -a | IFACE...
-a Deconfigure all interfaces -i FILE Use FILE instead of /etc/network/interfaces -n Dry run (note: doesn't disable mappings) -m Don't run any mappings -v Print out what would happen before doing it -f Force— Reply to this email directly, view it on GitHub https://github.com/PartialVolume/shredos.x86_64/issues/105#issuecomment-1159796143, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSYFM2JSV2Y4RPTJTNFQGTVP5XM3ANCNFSM5XBCQYGQ . You are receiving this because you were mentioned.Message ID: @.***>
Funny story, you'll notice that ifdown -h is -not- a valid option in your version, but it gives you a list of what is anyway, it actually is valid in mine, but -f is not, whereas --force is. Kinda silly things to change really. Seems wildly unnecessary.
Attached are my results.
Well that explains the cause of that particular problem. Can you run which -a ifdown. You should see two directories listed. Then run ifdown but include the paths. Is there a difference?
/sbin/ifdown -h
/usr/sbin/ifdown -h
I'm just wondering if you have two different versions of ifdown. Mine are both the same.
Same version for both. I'm going to correct any instance of ifdown in the code to ifdown --force and let you know if anything changes. Sure wish I was generally more familiar with buildroot. If we can get this working, I'm definitely going to make it so that the code pulls a single generic shell script from the server after booting, before initiating nwipe so I can modify my shell scripts without having to re-make the entire package every time, along with a local shell script that pulls named files from the server so I can even do it in place. . .
On Wed, Jun 22, 2022, 1:16 AM PartialVolume @.***> wrote:
Well that explains the cause of that particular problem. Can you run which -a ifdown. You should see two directories listed. Then run ifdown but include the paths. Is there a difference?
/sbin/ifdown -h /usr/sbin/ifdown -h
I'm just wondering if you have two different versions of ifdown. Mine are both the same.
— Reply to this email directly, view it on GitHub https://github.com/PartialVolume/shredos.x86_64/issues/105#issuecomment-1162652209, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSYFM4CC3TKUEHOETRXL4DVQKORPANCNFSM5XBCQYGQ . You are receiving this because you were mentioned.Message ID: @.***>
Ugh, this again. So, in order to make troubleshooting sane, I am going back through menuconfig. I downloaded a separate clone of your x86_64 deployment and am going through submenu by submenu and lining mine up with yours. I eliminated ifupdown from mine which I trust was the source of the discrepancy, though, as I keep saying, upload failed in the same way before I even tried doing my own build. So, without further ado, I've made clean and am recompiling the whole thing, just to be safe. Separately, I've changed my user name to hdwipe because the previous name was associated with a defunct enterprise and I'll post results from an updated build shortly.
On a separate note, I look forward to continuing to support the work you are doing on this project and hope I can contribute something in the way of an integrated nvme and secure wiping solution via the wrapper I am building.
How do you feel about including node.js in your build in order to achieve this?
So, in order to make troubleshooting sane, I am going back through menuconfig.
Good luck, it can be quite tedious and time consuming as their are so many subdirectories in the config menus. It can be easy to miss something, as I know to my cost.
You may already know this, but don't forget it's not just make menuconfig (followed by make savedefconfig) but also make busybox-menuconfig (followed by make busybox-update-config) and of course make linux-menuconfig (followed by make linux-update-defconfig).
Interestingly I noted that my ifdown is provided by busybox (as shown in the help ifdown -h) where your version makes no mention of busybox so I'm guessing you included ifdown in make menuconfig rather than make busybox-menuconfig
Over the years vanilla ShredOS has lots of changes to all these configs so you will need to go through all three configs. ShredOS has had lots of drivers installed to support a wide range of hardware that it's easy to miss out if you are starting from a vanilla buildroot.
Personally I would start with the standard ShredOS and make changes to that otherwise there is a good chance you will miss out many drivers.
On a separate note, I look forward to continuing to support the work you are doing on this project and hope I can contribute something in the way of an integrated nvme and secure wiping solution via the wrapper I am building. How do you feel about including node.js in your build in order to achieve this?
I'm happy to take a look and include anything that adds and improves ShredOS, however having said that you would definitely want to start with the vanilla ShredOS and make changes to that using git and submit pull requests for review based on the existing code base.
OK, so, based on this convo, I've gone and done the following, into a totally fresh directory: $ git clone https://github.com/PartialVolume/shredos.x86_64.git (or shredos.i686.git for 32bit) $ cd shredos $ mkdir package/shredos $ touch package/shredos/Config.in $ make clean $ make shredos_defconfig $ make menuconfig $ make savedefconfig $ make busybox-menuconfig $ make busybox-update-config $ make linux-menuconfig $ make linux-update-defconfig
Now, I'd never made any changes to the last 2 previously, I did, however, previously add the ifupdown utility (along with wget, dialog, http support, and a couple others), so I did not do that this time. In any case, I made all 3 in addition to the initial instructions. I am now doing the final compile and will deploy that on my test rig and provide the results and we'll see what comes up then.
On the note of using the vanilla build in order to contribute, is that a no to including dialog and/or node.js to the default buildroot config? I haven't touched node, just exploring.
On the note of using the vanilla build in order to contribute, is that a no to including dialog and/or node.js to the default buildroot config? I haven't touched node, just exploring.
I have no problem adding dialog and/or node.js as long as they don't increase the size significantly. It's just that if you are working with version control in the form of git it makes seeing the changes and history so much easier Not to mention unlimited number of people can work on different parts of the code simultaneously without getting in a complete mess and makes my job easier when reviewing and committing the changes to the main branch. And to use git you have to be working with a clone of shredos as you have done above.
I could be misunderstanding what you want though, do you want me to add dialog and node.js without you doing the formal commits and pull requests to add those items? I don't mind adding those small changes on the next release if you are not really interested in the git side of things.
Apologies if I'm explaining stuff you already know. I don't know how much you have worked with git and github. Working with git isn't every bodies cup of tea and has a steep learning curve. But once you get the hang of it, it's great for tracking changes.
Now, I'd never made any changes to the last 2 previously, I did, however, previously add the ifupdown utility (along with wget, dialog, http support, and a couple others),
Before adding extra binaries using make menuconfig it's a good idea to run make busybox-menuconfig and make sure the binary is not already included in busybox. Something to note, busybox combines it's commands into a single binary, so in shredos if you want to see a list of commands provided by busybox do a /bin/busybox
Here's a list of commands provided by busybox in ShredOS.
# /bin/busybox
BusyBox v1.33.1 (2022-03-22 21:10:37 GMT) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.
Usage: busybox [function [arguments]...]
or: busybox --list[-full]
or: busybox --show SCRIPT
or: busybox --install [-s] [DIR]
or: function [arguments]...
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as.
Currently defined functions:
[, [[, addgroup, adduser, ar, arch, arp, arping, ash, awk, base32, base64,
basename, bc, beep, blkdiscard, blkid, bunzip2, bzcat, cat, chattr, chgrp, chmod,
chown, chroot, chrt, chvt, cksum, clear, cmp, cp, cpio, crond, crontab, cut, date,
dc, dd, deallocvt, delgroup, deluser, depmod, devmem, df, diff, dirname, dmesg,
dnsd, dnsdomainname, dos2unix, du, dumpkmap, echo, egrep, eject, env, ether-wake,
expr, factor, fallocate, false, fbset, fdflush, fdformat, fdisk, fgconsole, fgrep,
find, flock, fold, free, freeramdisk, fsck, fsfreeze, fstrim, ftpd, ftpget,
ftpput, fuser, getopt, getty, grep, gunzip, gzip, halt, hdparm, head, hexdump,
hostid, hostname, hwclock, i2cdetect, i2cdump, i2cget, i2cset, i2ctransfer, id,
ifconfig, ifdown, ifup, inetd, init, insmod, install, ip, ipaddr, ipcrm, ipcs,
iplink, ipneigh, iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5,
klogd, last, less, link, linux32, linux64, linuxrc, ln, loadfont, loadkmap,
logger, login, logname, losetup, ls, lsattr, lsmod, lsof, lspci, lsscsi, lsusb,
lzcat, lzma, lzopcat, makedevs, man, md5sum, mdev, mesg, microcom, mim, mkdir,
mkdosfs, mke2fs, mkfifo, mknod, mkpasswd, mkswap, mktemp, modinfo, modprobe, more,
mount, mountpoint, mt, mv, nameif, netstat, nice, nl, nohup, nologin, nproc,
nslookup, ntpd, nuke, od, openvt, partprobe, passwd, paste, patch, pidof, ping,
pipe_progress, pivot_root, poweroff, printenv, printf, ps, pwd, rdate, readlink,
readprofile, realpath, reboot, renice, reset, resize, resume, rm, rmdir, rmmod,
route, run-init, run-parts, runlevel, sed, sendmail, seq, setarch, setconsole,
setfattr, setfont, setkeycodes, setlogcons, setpriv, setserial, setsid, sh,
sha1sum, sha256sum, sha3sum, sha512sum, shred, sleep, sort, start-stop-daemon,
strings, stty, su, sulogin, svc, svok, swapoff, swapon, switch_root, sync, sysctl,
syslogd, tail, tar, tc, tee, telnet, telnetd, test, tftp, time, top, touch, tr,
traceroute, true, truncate, ts, tty, ubirename, udhcpc, uevent, umount, uname,
uniq, unix2dos, unlink, unlzma, unlzop, unxz, unzip, uptime, usleep, uudecode,
uuencode, vconfig, vi, vlock, w, watch, watchdog, wc, wget, which, who, whoami,
xargs, xxd, xz, xzcat, yes, zcat