Client Networking support

[hdwipe]

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.

[PartialVolume]

Could be a missing driver, I'll take a look at the hardware specs and get back to you.

[hdwipe]

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: @.***>

[PartialVolume]

Can you post the output of ls -1 /sys/class/net thanks.

[hdwipe]

[hdwipe]

Or do you need it from inside of something like Ubuntu live?

[PartialVolume]

No that's fine, thanks. I'll follow up shortly with a few extra commands so we can figure out what the issue is.

[PartialVolume]

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.

[hdwipe]

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

[PartialVolume]

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 +e at 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.

[PartialVolume]

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

[PartialVolume]

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

[PartialVolume]

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.

[hdwipe]

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.

[PartialVolume]

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.

[hdwipe]

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)

[hdwipe]

The output of nohup.out looks useful.

[PartialVolume]

Yes, that is useful. I'll boot up my system and take a look at that -f option and the read error.

[hdwipe]

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: @.***>

[PartialVolume]

@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.

[PartialVolume]

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

[hdwipe]

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: @.***>

[hdwipe]

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.

[PartialVolume]

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.

[hdwipe]

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: @.***>

[hdwipe]

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?

[PartialVolume]

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.

[hdwipe]

Ok, this is where we are now.

[hdwipe]

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.

[PartialVolume]

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.

[PartialVolume]

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

[hdwipe]

I've actually never really used GIT beyond pulling so I'm a little hesitant to dive in at this particular juncture. I'm just working on shell scripts, so if they useful and get integrated, I'd definitely get going with git to stay involved as appropriate. I'm actually quite familiar with BusyBox (one of my first business automations involved imaging hard drives with linux on a floppy back in '01, lol) but not so much with buildroot. I really just made that adaptation in the hopes of deriving a different result. In all cases, it finally compiled and I deployed a clean setup into my test rig. I'll post now what happens . . . Yeah, that same image I just posted with SIOCSIFFLAGS errors on repeat. I'd call it fruitless, but we both know how important increased certainty is in troubleshooting :-) Thoughts?

[PartialVolume]

I've never seen that error on ShredOS before. Sounds like maybe there is a conflict and something else is using the same Interrupts. I've seen some suggestions to disable plug and play in the bios although I have my doubts it's that as surely I would have come across it before now. Worth a try though. Are you now running the busybox versions of ifdown or the other version?

[PartialVolume]

If you download the .img or .iso images and burn to USB/CD do they show the same problem? If not then it's got to be in your build configuration being different somehow.

[hdwipe]

OK, so, while I am certain it will not work, I cannot say that it will not work in the same way, so here goes nothing, LOL. This is from the image file of the posted build, PXE booted, coming from this link: https://github.com/PartialVolume/shredos.x86_64/releases/download/v2021.08.2_21_x86-64_0.32.023/shredos-2021.08.2_21_x86-64_0.32.023_20220123.img Annnnnd, we have. . .the same error, word for word. That's from nohup.out. Yes, busybox versions. That I wasn't was only a result of an earlier attempt to troubleshoot. Encountering same problem in now all 3 versions, one that I had modified and then cleaned, one I just recently built from scratch from git and now the one straight out of the package. Very strange business. Stranger still that it's across the very specific brand of very main-stream servers that it is; and a maker that is extremely open-source friendly to boot. I'm using FTP to pull the main shredos once file once grub has loaded. Is there any way that has anything to do with it vs. using tftp? It seems unlikely and moreover, like it definitely should not. Which do you use for your netboot?

[hdwipe]

OK, so, of the posts I've glanced over, this seems the most promising so far (only in so much as that it's the first one that mentions something other than wireless). Of course, his solution means nothing to me in the context of Buildroot. Does this mean anything to you? User Sebi94 on LinuxQuestions posted: I found the mistake... It was a missing firmware (the second one, but it needs the first one also): firmware-linux-nonfree firmware-linux Here: https://www.linuxquestions.org/questions/linux-networking-3/ifconfig-eth0-up-doesn%27t-work-cause-of-no-such-file-or-directory-4175422879/ Should I just start haphazardly cutting different coloured wires or does this mean something to you in this context?

[PartialVolume]

Can you post the output of lspci for one of the machines with the problem. Maybe we are missing some firmware for that hardware.

[hdwipe]

I assume this would be the segment we are looking for. Almost everything else pertains to the Xeon 5600 Series CPU and the stuff it does

[PartialVolume]

Can you run make menuconfig, then navigate to TARGET PACKAGES > HARDWARE HANDLING > FIRMWARE > LINUX-FIRMWARE > ETHERNET FIRMWARE > BROADCOM NETEXTREME II and enable all the options with asterisk, in particular the Broadcom NetXtreme II in your particular case. Save then exit. Run the following

make savedefconfig
make clean
make shredos_defconfig
make

Go and have a very long lunch 2hrs+, fingers crossed, ethernet should now work.

[hdwipe]

I would love to, but for one thing. Both my clean "vanilla copy" that I just made via your instructions (including linux and busybox menu makes, with no changes) give me THIS menu under TARGET PACKAGES > HARDWARE HANDLING > FIRMWARE. Perhaps you have made your flavor of build pegged to a particular revision or group of settings not included in the deploy? More likely there's something I do not know that I should . Clue me in :-)

[PartialVolume]

You need to select linux-firmware then the sub-directory will expand so you can then select ethernet firmware. The sub directory won't show until you select linux-firmware i.e. a asterisk appearing next to linux-firmware.

[hdwipe]

Disregard. I see I needed to select linux-firmware, and once I did, the necessary sub-menu appeared. I added qlogic FC firmware for good measure too (for other reasons). Crossing my fingers!

[hdwipe]

I guess I figured it out just as you were politely supporting me in drawing the conclusion that I'm an idiot ;-)

[PartialVolume]

Too harsh on yourself, there's plenty of times I've been an idiot over the years. 😁

[PartialVolume]

I think I'll commit the following ethernet firmware additions to ShredOS

Broadcom NetXtreme/Tigon3
Broadcom NetXtremeII
Chelsio T4
Chelsio T5
Intel e100 825xx
Microchip VSC85xx PHYs
QLogic FastLinQ 4xxxx
Realtek 816

[hdwipe]

What's that supernatural comedy movie where the main character has to utter a couple of specific words in a specific order or very bad things happen, and the other lead is all, did you say the words and our guy says, well, of course, mostly or sort of or something to that effect. I feel like it's a Bill Murray movie. shrug. anyway, I didn't make clean or make shredosconfig before making again, so I have a very large still non-working result which gives us a troubleshooting result of null. Back with you shortly.

[PartialVolume]

What's that supernatural comedy movie where the main character has to utter a couple of specific words in a specific order or very bad things happen, and the other lead is all, did you say the words and our guy says, well, of course, mostly or sort of or something to that effect. I feel like it's a Bill Murray movie. shrug. anyway, I didn't make clean or make shredosconfig before making again, so I have a very large still non-working result which gives us a troubleshooting result of null. Back with you shortly.

I watch a lot of movies but that's not one I recognise, the first one that came to mind was Beetlejuice...Beetlejuice .... but then you say that incantation to make bad things happen in the form of Micheal Keaton not the other way round :-)

I always do that sequence (not the bettlejuice one). There's too many times when I've not done a make clean and then make bombs out after hours of compiling. So the magic incantation for me is always ..

1. Make your changes with make menuconfig or the linux or busybox configs
2. ALWAYS run the appropriate make save command for the config you changed.
      i.e. `make savedefconfig` or `make linux-update-defconfig` or `make busybox-update-config`

then

make clean
make shredos_defconfig (restores your newly modified changes)
make

And that works for me 100% of the time. Missing any of the specific make save commands means your changes won't get saved to the shredos defconfig file and so when you restore the configuration by doing a make shredos_defconfig you will be restoring a config you have not actually altered. So that sequence is really important for a reliable build.

[PartialVolume]

BTW, if you get the following error near the end of the build after having added more software to the build, you need to expand the size of shredos's vfat disc.

bzImage' '::boot/shredos'" (stderr):
Disk full
INFO: vfat(boot.vfat): cmd: "rm -f "/xxxxxxxxxxxxxxxx/Software/shredos/2021.08.2/buildroot-2021.08.2/output/images/boot.vfat"" (stderr):
ERROR: vfat(boot.vfat): failed to generate boot.vfat
make[1]: *** [Makefile:823: target-post-image] Error 1
make: *** [Makefile:84: _all] Error 2

To increase the size of the vfat disc, edit ../board/shredos/genimage.cfg and change the following line

size = 60000000

Increase by 5 or 10 Mbytes. so it becomes

size = 70000000

Try restarting the build by just doing a make without a make clean. If you get any errors do a full clean make, using the full build sequence of commands.

[hdwipe]

Yeah, I encountered that one early on in my experimentation. Had me stumped for a couple hours til I found the relevant error detail and then a useful response to it. Lot of arm flailing before I found it

On Fri, Jun 24, 2022, 5:08 AM PartialVolume @.***> wrote:

BTW, if you get the following error near the end of the build after having added more software to the build, you need to expand the size of shredos's vfat disc.

bzImage' '::boot/shredos'" (stderr): Disk full INFO: vfat(boot.vfat): cmd: "rm -f "/xxxxxxxxxxxxxxxx/Software/shredos/2021.08.2/buildroot-2021.08.2/output/images/boot.vfat"" (stderr): ERROR: vfat(boot.vfat): failed to generate boot.vfat make[1]: [Makefile:823: target-post-image] Error 1 make: [Makefile:84: _all] Error 2

To increase the size of the vfat disc, edit ../board/shredos/genimage.cfg and change the following line

size = 60000000

Increase by 5 or 10 Mbytes. so it becomes

size = 70000000

Try restarting the build by just doing a make without a make clean. If you get any errors do a full clean make, using the full build sequence of commands.

— Reply to this email directly, view it on GitHub https://github.com/PartialVolume/shredos.x86_64/issues/105#issuecomment-1165368758, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSYFM3GFC3XBZD33WBJWGTVQV3HRANCNFSM5XBCQYGQ . You are receiving this because you were mentioned.Message ID: @.***>

[hdwipe]

I thought that I had already sent this BUT, still no dice. Same error, exactly, nothing has changed. Is there something we might need to do to link the 'firmware' to the card or, load it or whatever? Is what they're calling 'firmware' just a 'driver' or . . .when I think of firmware, I generally think of the software on an EEPROM chip that a particular device boots from, so I'm not entirely clear on what it means in this particular context.

[PartialVolume]

I thought that I had already sent this BUT, still no dice. Same error, exactly, nothing has changed. Is there something we might need to do to link the 'firmware' to the card or, load it or whatever? Is what they're calling 'firmware' just a 'driver' or . . .when I think of firmware, I generally think of the software on an EEPROM chip that a particular device boots from, so I'm not entirely clear on what it means in this particular context.

So you are still getting the SIOCSIFFLAGS errors on repeat?