The Post Biden Block- Twitter & Facebook Do A Streisand

I was thinking “Yeah, so what else is new?” about this story. We already know that Biden is dirty, that his kid is dirty, that they raked in $Buckets of money from China and likely others. Essentially that the corruption of the DNC is nearly complete and the Bidens are up to their ears in the resulting green. We also know that “Big Tech” are fully in bed with the DNC. (whether as Left Partisans or under TLA Influence is still unclear, perhaps both).

Given that, were’s the story?

Well, “The Story” is that a major Real News organization, the New York Post, is being censored by Twitter, Facebook, and likely Youtube. Since when did Twitter & Facebook become the Editorial Staff of The NY Post?

Here, The Quartering, does a good rant on the whole thing:

Particularly interesting to me was that a few Senators are actually writing letters to said Big Tech Honchos asking them, in essence, “What the hell are you thinking?”…

So, in keeping with the best aspects of The Streisand Effect, I figured I ought to do a “tag on” helping to spread The Story. Both the Biden’s Greed & Graft story, and, for me, the more important “Big Tech Censor’s The Mainstream News!” story (that in some ways I think is more important).

My position:

I’ve already stated before my position on this event. It isn’t your typical point of view. Simply put, there is not enough staff at Facebook & Twitter, and they are neither smart enough nor subtle enough, to censor ALL the “fake news” while also suppressing the politically sensitive (read “damaging to Democrats”) real stories. As a result, they are Ham Handed and focus on the “stuff that matters” (as all major corporation management does). The necessary consequence of this, much like the Streisand Effect, is that attempts to HIDE stories become advertising of the stories AND become strong evidence for the veracity of the Story. Essentially: Their actions are a negative indicator. The more they holler “Fake” the more we hear “Here Be Truth”.

Following the Chinese Communist Party Censorship model does not work. The bits will flow. The suppression becomes the story. In a world of ubiquitous cameras, microphones, networks and encryption, you can not hide a story, you can only draw attention to it.

Good luck with that, Twatter and Faceplant….

Here’s the original story:

https://nypost.com/2020/10/14/email-reveals-how-hunter-biden-introduced-ukrainian-biz-man-to-dad/

Subscribe to feed

W.O.O.D. – 14 October 2020

Intro

This is another of the W.O.O.D. series of semi-regular
Weekly Occasional Open Discussions.
(i.e. if I forget and skip one, no big)

Immediate prior one here:

https://chiefio.wordpress.com/2020/09/15/w-o-o-d-14-september-2020/
and remains open for threads running there (at least until the ‘several month’ auto-close of comments on stale threads).

Canonical list of old ones here:
https://chiefio.wordpress.com/category/w-o-o-d/

For just general FYI notices, use to “tips” pages. All the old ones remain for historical reference:
“Tips Pages”

Three Weeks To The End Of This Crap

And the start of new crap…

As of now, it is just 3 weeks until the election of the US President (along with a load of congress and others) is nominally over. Due to many Democrat Party ruined States going to massive “mail in ballots” it may well be 3 months before we know who, if anyone, is the President.

I suspect that election night will turn into chaos as the non-answer dawns. Or, if Trump is elected and it’s clear he is POTUS even without the other States reporting: Expect the Globalists / China paid Communists & Socialists / Soros funded Color Revolution folks like BLM & Antifa and others to have a complete emotional explosion and destroy their home cities even more. OTOH, if Biden “wins” it will most likely be an incredible fraud, and expect all sorts of legal issues and media hysterics.

So, for the next 3 weeks we will have increasing tension, increasing “shit storms for effect”, and ever less sleep. Sigh.

Three Days to 3 Weeks to 3 Months for Brexit to really, finally, this time for sure! be done. Maybe.

We’ve got the EU doing their best to sell fear and do nothing in the hope they can get “Brexit in name only”, but it is dawning on them oh so slowly that a WTO exit would be fine for the UK. Boris has, supposedly, said something along the lines of ~”this week is it, we’re off”, but he is having last minute (for the what, 20th time now?) “talks” with the EU.

For God’s Sake, man, just leave already. Take your sovereignty and leave. Do NOT compromise your fishing territorial waters, your law making ability, your National Choice and Control on regulations, your ability to conduct free trade with the rest of the world. Get your self free. NOW. Please. Sign a free trade deal with the USA before the end of the year and get on with it.

The EU is NEVER going to be a decent negotiating partner (they have demonstrated this many times already). They are wedded to the Globalist Abuse Platform. JUST WALK AWAY. Once Germany realizes it’s not selling as many cars into the UK, and once the reality of “no fishing for you” has been absorbed into the French and Spanish governments, then they will be much more flexible in their “demands”.

What’s Going On?

Chinese Wuhan Covid Lockdowns Unconstitutional and Failing – Again

The W.H.O. has even come out and said the time for lockdowns is over. It is now killing far more than the disease. We can effectively treat Chinese Wuhan Covid, and mortality is lowest while Vitamin D is highest and that is Right Now end of summer and sun.

It’s time to just get back to life and move on.

In Conclusion

I know. Short summary this time. But really, everything is on hold until the election happens. China and India and most of the rest of the Chinese neighbours are on the verge of war, but nobody will move until they know what the USA will become. Storms and such are causing lots of crop failures; but nothing will be stated as such until after the harvest season is done.

The whole world is just collectively marking time until the USA election is over and a Chinese Wuhan Covid vaccine is approve. Until that happens, it’s just circling the drain.

Companies are starting massive layoffs as the lockdowns exceed their ability to carry employees and no more bailout money is coming (thanks, Nancy… /sarc;) so we’ve had 5 figure layoffs in everything from Disney to other media to airlines and more. It’s the end game of the Democrat Party scorched earth plan to ruin the economy and blame it on Trump. But that blame redirection isn’t working. From riots to looting to burning city centers to forest fire arson: It has all happened in Democrat controlled cities and States. Similarly, the lockdowns leading to bankruptcy and layoffs. There’s a deep hatred for all things Democrat forming in the gut of Americans. Or at least those with a bit of clue.

In other news… it turns out that Democrats are about 80-90% scared of Covid and scared of going out to vote. Republicans are about 80-90% fine with going out, groups, voting in person.

Mail-in ballots have a MUCH higher rejection / error rate. Most of the mail-in ballots will be Democrats. Think about it… Recently California issued a plea to STOP disinfecting your mail in ballots as it smears the ink and the ballot is rejected. Fearful Democrats were alcohol washing them… Their push to promote mail-in ballots could very well cost Democrats the win just due to a few percentage higher rejection rate of predominantly Democrat voters ballots. Karma, it’s a thing ;-)

Let’s see. 3 Weeks. 21 Days. At 3 bottles a week, that’s 9 bottles. Call it $50 to $100 of “anaesthesia” budget. I think I can swing that. The bigger question is will it still be just 3 a week in 2 weeks…

Subscribe to feed

Making XU4 Devuan Starting From Ubuntu Kernel

I’m doing a “do over” of making a working Devuan, but starting from Ubuntu for the boot loader, kernel, etc.

Why? Because I suspect that the use of a FAT file system /boot may be common between the two, where Armbian has a very different approach. I’m curious to see if the process is in any way ‘easier’.

Firxt, get a copy of Ubuntu from:

https://wiki.odroid.com/odroid-xu4/os_images/linux/start

ems@XU4devuan2:/SG2/ext/XU4$ ls -l
-rw-r--r-- 1 root root 1303410760 Oct 13 16:57 ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img.xz

Uncompress it with the linux command “unxz”.

root@XU4devuan2:/SG2/ext/XU4# unxz ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img.xz 

Giving:

ems@XU4devuan2:/SG2/ext/XU4$ ls -l
-rw-r--r-- 1 root root 6453985280 Oct 13 16:57 ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img

Yes, almost 6 1/2 GB of stuff. Ubuntu is Very Fat… Now, put that onto a uSD card (in a USB adapter) via dd. I’m very fond of using gparted at this point to display the partition structure of all mounted disks and cards just to assure I really really know what device is the target, since using “dd” will nuke anything on the target. The use of the gparted graphical partition editor on Linux is a very nice way to see all disks all partitions in one go, but often you need to install it first with “apt-get install gparted” on Debian / Devuan / Ubuntu etc. You can use the “file” command to look at partitions one by one and that is often enough. I’ve bolded some bits:

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sda1
/dev/sda1: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x80), FAT (1Y bit by descriptor); NTFS, sectors/track 63, sectors 8388592, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 0fae20edde20e9e4f; contains Microsoft Windows XP/VISTA bootloader BOOTMGR

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sda2
/dev/sda2: Linux/i386 swap file (new style), version 1 (4K pages), size 524287 pages, LABEL=SG2_swap, UUID=cbf6b665-c6a2-49cc-9d46-b3ed9e2e6ba0

I happen to know that disk /dev/sda always shows up first as my major scratch disk on this system. This is also where having certain naming standards or habits is helpful. I leave an NTFS partition at the front of new real rotating media disks where I leave whatever stuff the vendor included (often backup software for Micro$soft and / or boot sectors for them). I use gparted to shrink that down to something small and add other partitions for Linux use in almost all of the space. Typically, I’ll put a “swap” partition in number 2 position. This makes it easy to know what target to aim the “file” command at.

Notice /dev/sda2 is a swap partion with the LABEL I gave it of “SG2_swap”. Each of my disks I name with a clear short flag. This is my SeaGate 2 GB disk. So I can easily know that /dev/sda is just not a disk I want to mess with in the copy as it is my MAIN daily driver disk for home directory, swap space, etc. Note that I mount it on /SG2 and in my command prompt you see my working directory is /SG2/ext/XU4. I’m currently using that disk, but another partition, for this Ubuntu image handling.

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sda14
/dev/sda14: Linux rev 1.0 ext3 filesystem data, UUID=f0302962-76a5-4859-9bbf-e7a73214df44, volume name "SG2_ext3" (needs journal recovery) (large files)

Yeah, the 14th partition… Having 2 TB you can go a bit nuts on partitions ;-) But this is not the disk we want…

The next one is the last one plugged in. It has a Linux file system on it, but I know I was using this chip for a generic Armbian install from about 2019 that I no longer want. It is not mounted at present so no mount point shows up. Also note that the next slot after it, sdc, is empty and nothing shows up. So sdb is my target device.

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=9e93ad0d-7a3f-4fb0-97f8-66dcb548a6da (extents) (large files) (huge files)

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sdc1
/dev/sdc1: cannot open `/dev/sdc1' (No such file or directory)

Confirmation can be had to some degree from ‘df’:

ems@XU4devuan2:~$ df

Filesystem      1K-blocks      Used  Available Use% Mounted on
udev                10240         0      10240   0% /dev
tmpfs              204484       492     203992   1% /run
/dev/mmcblk1p5    4062912   3424048     429152  89% /
tmpfs                5120         4       5116   1% /run/lock
tmpfs             1247820     76660    1171160   7% /run/shm
/dev/mmcblk1p1    6160512   3281828    2796760  54% /SD/Devuan
tmpfs             2097152        16    2097136   1% /tmp
/dev/sda12      103081248  15599304   82239064  16% /SG2/home
/dev/sda14     1757578792 112005792 1556286448   7% /SG2/ext
/dev/sda15        8190392   2518584    5252432  33% /sq/sq
tmpfs             1022404         0    1022404   0% /sys/fs/cgroup
tmpfs              204480        12     204468   1% /run/user/1600

The /dev/mmcblk1px slices are the uSD card currently booted. My “multiboot multisystem” 32 GB card. Devuan 1.0 is in the /dev/mmcblk1p1 partition (mmc for mmc card, which it isn’t but they use the name anyway, blk for block device, 1 as the second one the 0 of first one being the real mmc mount below the board that I’m not using, and then p1 for partition one.). I have it mounted as /SD/Devuan. The running OS mounted on ‘/’ is /dev/mmcblk1p5 so the 5th partition on the card. It’s a Devuan 2.0 but using the /boot and kernel from the p1 partition to boot up.

We can also see several /dev/sda partitions mounted as /SG2/home /SG2/ext and /sq/sq (where I was playing with read-only squashfs filesystems for things like /usr and /lib and such)

No mounts for /dev/sdbx or higher. So, OK, pretty clear we can proceed to toss the image of Ubuntu onto that card. Being VERY careful to get the drive letters Just Right and remembering we are using the whole device /dev/sdb not any one partition like /dev/sdb1.

This is the copy command, but I put the “time” command in front of it to give us some timing data on how long it runs. Yes, dd does that itself, but in seconds and I’m being lazy and avoiding the conversion to minutes ;-) With writing 6 GB to a slow uSD card, this takes a while, so get get lunch… or something:

root@XU4devuan2:/SG2/ext/XU4# time dd bs=10M of=/dev/sdb if=ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img 

The 10M says to use 10 MB buffer size. I’ve tried other sizes and this seems to be a decent one for both speed and reliability. On some slow systems, using a buffer like 100M can cause instability in the uSD writing process. Shoving a bit much at some cheap cards means they can’t keep up ;-) In any case, it seems to be very reliable to use 10M.

After it completes the copy:

root@XU4devuan2:/SG2/ext/XU4# time dd bs=10M of=/dev/sdb if=ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img 
615+1 records in
615+1 records out
6453985280 bytes (6.5 GB, 6.0 GiB) copied, 887.088 s, 7.3 MB/s

real	14m47.156s
user	0m0.001s
sys	0m48.725s

So about 15 minutes. I’d made a “backup” copy of my Devuan 2.0 standalone based on Armbian, but using a so-so Kodak uSD card and in a USB 3.0 adapter in the USB 3.0 port of the XU4, AND using 100M buffer size. It got about 16 MB/s write, 32 MB/s read. Then put “something else” on the card. When I tried restoring it, it was corrupted. So “something” in that set was ‘a problem’. Either the uSD card could not keep up with 100 MB at high speed, or the USB 3.0 adapter couldn’t take the speed or 100M buffer was just too big or “whatever”. I suspect it was the card at USB 3.0 speeds of 100MB size. Why? The copy on real disk was corrupted. That’s a read operation from the uSD card. It wasn’t limited by the peculiar write dynamics of uSD cards. At any rate, I’ve gone back to my old always reliable set of USB 2.0, Samsung or Sandisk uSD cards, and smaller buffer size for now. “Someday”, when I have nothing better to do, I’ll try the various parts individually and see what was the problem. But I figured if I’m making a new one, might as well try the Ubuntu starting point ;-)

FWIW I’ve used the Kodak card for various OS builds without issue before. But always using 10 MB buffer size in a USB 2.0 slot. I’ve also had “issues” with the USB 3.0 not working quite right on the XU4 in early OS releases (but fixed about a year+ ago). Finally, there’s also the point that I’m using a bastard mix of kernel, kernel modules, firmware, and Userland to do this work, so it’s possible one of them is just not up to the task. (BUT it did work fine at USB 2.0 / 10 MB …)

Now you can boot it up and let it do the new card file system expansion and such. At this point, you can also dd off a new copy of this uSD card to make restarting the process easier OR save it just as a working Ubuntu.

That’s what I’m going to do right now. So “back in a bit” as I only have one XU4 and can’t type this on it while I’m booting the chip ;-)

OK, after lunch and booting / shutting down the Ubuntu port. It worked and the card + image looks fine. In fact, it does put /boot on the first FAT partition (rather like the Devuan /etc/fstab expected. I went ahead and made a few more partitions (use the ‘move / shrink option of gparted to free up space at the end, then use the ‘new’ option to make some new partitions) on the uSD card.

Next up, we mount those partitions. Copy over the /boot /lib/modules and /lib/firmware from the Ubuntu partition to the save spaces. Then we can “blow away” the Ubuntu image, copy into that space the Devuan 2.0 tar files, and return the /boot /lib/modules and /lib/firmware bits to where they belong in the file system name space.

At that point, it ought to just boot and go. I’ll take ANOTHER dd image of the card anyway just to have a useful checkpoint / restart point and in case I want to try other things in the future without starting from scratch.

Here’s the spaces I made to mount things:

root@XU4devuan2:/# ls /SD
Armbian  Devuan2  Funtoo  Hyarm64  misc  slack	temp
Devuan	 ext	  Gentoo  Hyarmhf  ms	 sq	XU4
root@XU4devuan2:/# mkdir /SD/firmware
root@XU4devuan2:/# mkdir /SD/modules
root@XU4devuan2:/# mkdir /SD/boot
root@XU4devuan2:/# mkdir /SD/Ubuntu
root@XU4devuan2:/# mount /dev/sdb1 /SD/boot
root@XU4devuan2:/# mount /dev/sdb2 /SD/Ubuntu
root@XU4devuan2:/# mount /dev/sdb3 /SD/firmware
root@XU4devuan2:/# mount /dev/sdb5 /SD/modules
root@XU4devuan2:/# mount /dev/sdb6 /SD/temp

/SD is where I mount SD card file systems to work on them. Be they full sized SD cards or the small uSD. It tends to accumulate useful and meaningful mount point names over time ;-)

root@XU4devuan2:/# df

Filesystem      1K-blocks      Used  Available Use% Mounted on
udev                10240         0      10240   0% /dev
tmpfs              204484       592     203892   1% /run
/dev/mmcblk1p5    4062912   3424264     428936  89% /
tmpfs                5120         4       5116   1% /run/lock
tmpfs             1247820     63892    1183928   6% /run/shm
/dev/mmcblk1p1    6160512   3281828    2796760  54% /SD/Devuan
tmpfs             2097152         4    2097148   1% /tmp
/dev/sda12      103081248  15589936   82248432  16% /SG2/home
/dev/sda14     1757578792 142411428 1525880812   9% /SG2/ext
/dev/sda15        8190392   2518584    5252432  33% /sq/sq
tmpfs             1022404         0    1022404   0% /sys/fs/cgroup
tmpfs              204480        12     204468   1% /run/user/1600
/dev/sdb1          130798     16742     114056  13% /SD/boot
/dev/sdb2        25639236   4648024   20974828  19% /SD/Ubuntu
/dev/sdb3          999320      1320     945572   1% /SD/firmware
/dev/sdb5          999320      1320     945572   1% /SD/modules
/dev/sdb6         1014680      1304     961000   1% /SD/temp

So now I need to do a cd into the various directories, and copy their contents over to the mounted partitions where I’m going to save them. There are a dozen ways you could do this. For example, I could just ‘tar’ off the stuff into a tar file in /SG2/ext and have a saved copy, then restore it with “tar xvf FOO” into the new space. I often use a one line script to move things, of the form “(cd /FOO; tar cf – .) | (cd /BAR; tar xvf – ) as it does a good job with not following symbolic links and not screwing up ownership, permissions, and date stamps. HOWEVER, if you type “cd /BAR” wrong and the cd fails, it does the unpack wherever you are at the moment. This can have horrible effects… (Like if you are in /FOO at the time, overwriting the /FOO you are moving with partial blocks and screwing it all up so you get to start over…)

So I’m going to show the “safer” way of making a copy to a different disk, then doing the copy back.

root@XU4devuan2:/# mkdir /SG2/ext/Save_Ub
root@XU4devuan2:/# ls -ld /SG2/ext/Save_Ub/
drwxr-xr-x 2 root root 4096 Oct 13 21:03 /SG2/ext/Save_Ub/

Then the actual “make copies”.

root@XU4devuan2:/# cd /SD/boot
root@XU4devuan2:/SD/boot# ls
boot.ini		  exynos5422-odroidxu3-lite.dtb  uInitrd
config.ini		  exynos5422-odroidxu4.dtb	 zImage
exynos5422-odroidhc1.dtb  exynos5422-odroidxu4-kvm.dtb
exynos5422-odroidxu3.dtb  overlays
root@XU4devuan2:/SD/boot# tar cf /SG2/ext/Save_Ub/boot.tar .
root@XU4devuan2:/SD/boot# 

Notice you didn’t get much feedback? Add the -v option for verbose feedback. Here’s a partial on the modules file system:

root@XU4devuan2:/SD/Ubuntu# cd /SD/Ubuntu/lib/modules/
root@XU4devuan2:/SD/Ubuntu/lib/modules# ls
5.4.58-211
root@XU4devuan2:/SD/Ubuntu/lib/modules# tar cvf /SG2/ext/Save_Ub/Modules.tar .
[...]
./5.4.58-211/kernel/crypto/xor.ko
./5.4.58-211/kernel/crypto/lzo-rle.ko
./5.4.58-211/kernel/crypto/poly1305_generic.ko
./5.4.58-211/kernel/crypto/cast5_generic.ko
./5.4.58-211/kernel/crypto/rmd320.ko
./5.4.58-211/kernel/crypto/af_alg.ko
./5.4.58-211/kernel/crypto/wp512.ko
./5.4.58-211/kernel/crypto/deflate.ko
./5.4.58-211/kernel/crypto/tea.ko
./5.4.58-211/kernel/crypto/crypto_user.ko
./5.4.58-211/kernel/crypto/ansi_cprng.ko
./5.4.58-211/kernel/crypto/twofish_generic.ko
./5.4.58-211/modules.devname
./5.4.58-211/modules.alias
root@XU4devuan2:/SD/Ubuntu/lib/modules# 

/lib/firmware has a lot in it too, so only a partial listing:

root@XU4devuan2:/SD/Ubuntu/lib/modules# cd ../firmware
root@XU4devuan2:/SD/Ubuntu/lib/firmware# ls
1a98-INTEL-EDK2-2-tplg.bin   iwlwifi-8265-36.ucode
3com			     iwlwifi-9000-pu-b0-jf-b0-33.ucode
a300_pfp.fw		     iwlwifi-9000-pu-b0-jf-b0-34.ucode
a300_pm4.fw		     iwlwifi-9000-pu-b0-jf-b0-38.ucode
acenic			     iwlwifi-9000-pu-b0-jf-b0-41.ucode
adaptec			     iwlwifi-9000-pu-b0-jf-b0-43.ucode
advansys		     iwlwifi-9000-pu-b0-jf-b0-46.ucode
agere_ap_fw.bin		     iwlwifi-9260-th-b0-jf-b0-33.ucode
[...]

Here’s the command:

root@XU4devuan2:/SD/Ubuntu/lib/firmware# tar cvf /SG2/ext/Save_Ub/firmware.tar . 

Note that the trailing ‘.’ is vitally important. It says “copy from this, your current working directory”. You could get the same effect with an absolute path name like (scroll right to see the difference):

root@XU4devuan2:/SD/Ubuntu/lib/firmware# tar cvf /SG2/ext/Save_Ub/firmware.tar /SD/Ubuntu/lib/firmware

Useful if you do NOT “cd” into the target directory.

And now here’s the saved stuff:

root@XU4devuan2:/SD/Ubuntu/lib/firmware# ls -l /SG2/ext/Save_Ub/
total 591768
-rw-r--r-- 1 root root  17141760 Oct 13 21:04 boot.tar
-rw-r--r-- 1 root root 535879680 Oct 13 21:12 firmware.tar
-rw-r--r-- 1 root root  52336640 Oct 13 21:08 Modules.tar

In Theory, I can just leave the /boot as it stands (not copy back the saved bits from /SD/boot) and I’m going to try that. But, should I want to do this to some other uSD card, I’ve saved a copy. Or if I fumble finger it and blow away /SD/boot…

Next we copy in the Devuan 2.0 tar ball, set aside those /lib/modules and /lib/firmware bits, and make a final check no /boot/boot.ini and another stuff that might need a tweek. I’m going to copy the firmware.tar and modules.tar stuff back into those small /SD partitions just so that I have copies on file system bits on the uSD card. I don’t need to do it this way. I could just stuff it into the existing Devuan image. But this lets me have more flexibility about when, using what workstation, etc. “It’s all on the SD card”… so easy to get to and use, or not. I can test just mounting the file system over what’s there vs ‘blow away and replace’, for example. This takes a while as writes to uSD are slow and Ubuntu has a LOT of firmware for all sorts of devices stuck in here (including stuff for the R.Pi M3 so clearly leaving stuff useless for this board in the build – essentially the ‘kitchen sink’ approach leaving in drivers for everything in the world even if you can’t use it with this hardware):

root@XU4devuan2:/SD/Ubuntu/lib/firmware# cd /SD/firmware/
root@XU4devuan2:/SD/firmware# ls
lost+found
root@XU4devuan2:/SD/firmware# tar xvf /SG2/ext/Save_Ub/firmware.tar
[...]
./intel/dsp_fw_glk_v1814.bin
./intel/ibt-12-16.sfi
./intel/dsp_fw_bxtn_v2219.bin
./intel/ibt-18-16-1.sfi
./intel/ibt-19-16-4.sfi
./intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
./rt2860.bin
./myri10ge_rss_eth_z8e.dat
./iwlwifi-cc-a0-46.ucode
./dvb-usb-it9135-02.fw
./rtw88/
./rtw88/README
./rtw88/rtw8822b_fw.bin
./rtw88/rtw8822c_wow_fw.bin
./rtw88/rtw8723d_fw.bin
./rtw88/rtw8822c_fw.bin
./ctfw-3.2.1.1.bin
./dsp56k/
./dsp56k/bootstrap.bin
./v4l-cx25840.fw
./kaweth/
./kaweth/new_code.bin
./kaweth/trigger_code_fix.bin
./kaweth/trigger_code.bin
./kaweth/new_code_fix.bin
./atmel/
./atmel/wilc1000_wifi_firmware.bin
./atmel/wilc1000_p2p_fw.bin
./atmel/wilc1000_fw.bin
./atmel/wilc1000_ap_fw.bin
./regulatory.db
root@XU4devuan2:/SD/firmware# 

Then kernel modules:

root@XU4devuan2:/SD/firmware# cd /SD/modules
root@XU4devuan2:/SD/modules# ls
lost+found
root@XU4devuan2:/SD/modules# ls /SG2/ext/Save_Ub/
boot.tar  firmware.tar	Modules.tar
root@XU4devuan2:/SD/modules# tar xvf /SG2/ext/Save_Ub/Modules.tar
[...]
./5.4.58-211/kernel/crypto/lzo-rle.ko
./5.4.58-211/kernel/crypto/poly1305_generic.ko
./5.4.58-211/kernel/crypto/cast5_generic.ko
./5.4.58-211/kernel/crypto/rmd320.ko
./5.4.58-211/kernel/crypto/af_alg.ko
./5.4.58-211/kernel/crypto/wp512.ko
./5.4.58-211/kernel/crypto/deflate.ko
./5.4.58-211/kernel/crypto/tea.ko
./5.4.58-211/kernel/crypto/crypto_user.ko
./5.4.58-211/kernel/crypto/ansi_cprng.ko
./5.4.58-211/kernel/crypto/twofish_generic.ko
./5.4.58-211/modules.devname
./5.4.58-211/modules.alias
root@XU4devuan2:/SD/modules# 

On to the “blow away the contents” of the / of Ubuntu. Since /boot is not mounted on that /SD/Ubuntu spot, I can just erase it all. BUT, remember that we have system file systems here that use Symbolic Links. “rm -rf” can follow symbolic links that might well point to parts of your running operating system via hard full path names (like, oh, /lib/whatever..) and break your system. For this reason, I prefer to use ‘gparted’ and just remake the file system. This will change the UUID (Universal Unit Identifier” and so the UUID in the boot partition will not be right, so you get to change that to something that will work.

So I’ll umount /SD/Ubuntu and use gparted to format that partition, then remount it and proceed to restore the Devuan tar tape file into it.

root@XU4devuan2:/SD/modules# umount /SD/Ubuntu/

Do the gparted format /dev/sdb2. I also labeled it “Ub_Devuan2”. Keep it ext4 as that’s what the boot loader / kernel expect to find.

root@XU4devuan2:/SD/modules# mount /dev/sdb2 /SD/Ubuntu
root@XU4devuan2:/SD/modules# df

Filesystem      1K-blocks      Used  Available Use% Mounted on
[...]
/dev/sdb2        25508076     45080   24144188   1% /SD/Ubuntu

So now you can see it is empty. I’d moved the tar image off to an Archive disk, /arc in the listing below. Wherever it is, you just need to un-tar it.

root@XU4devuan2:/SD/modules# ls /Arc/ext/UnpackWIP/XU4/
Armbian_20.08.1_Odroidxu4_buster_legacy_4.14.195.img	     devuan_ascii_2.0.0_armhf_odroidxu4.tar	     TEMP
Armbian_20.08.1_Odroidxu4_focal_legacy_4.14.195_desktop.img  NetBSD-9-earmv7hf-202009151800Z-odroid-xu3.img
devuan_ascii_2.0.0_armhf_odroidxu4.img			     stage3-armv7a_hardfp-20200509T210605Z.tar
root@XU4devuan2:/SD/modules# cd /SD/Ubuntu/
root@XU4devuan2:/SD/Ubuntu# ls
lost+found
root@XU4devuan2:/SD/Ubuntu# tar xvf /Arc/ext/UnpackWIP/XU4/devuan_ascii_2.0.0_armhf_odroidxu4.tar 
[...]
/usr/share/fontconfig/conf.avail/90-synthetic.conf
./usr/share/xml/
./usr/share/xml/fontconfig/
./usr/share/xml/fontconfig/fonts.dtd
./usr/src/
./usr/local/
./usr/local/share/
./usr/local/share/man/
./usr/local/share/ca-certificates/
./usr/local/share/zsh/
./usr/local/share/zsh/site-functions/
./usr/local/share/fonts/
./usr/local/bin/
./usr/local/games/
./usr/local/lib/
./usr/local/include/
./usr/local/sbin/
./usr/local/src/
./usr/local/etc/
./usr/local/man
./mnt/
./srv/
./opt/
./media/
./boot/
./boot/zImage
./boot/exynos5422-odroidxu4.dtb
./boot/boot.cmd
./boot/boot.scr
./dev/
./sys/
./proc/
root@XU4devuan2:/SD/Ubuntu# 

Now in theory I can just make an /etc/fstab entry to mount my Ub_firmware and Ub_Modules partitions over the existing Devuan versions and be done. BUT, I don’t know for sure the order of “mount file systems” vs “load modules and firmware”. So initially I’m going to move the present Devuan /lib/modules to /lib/OLD_modules and move /lib/firmware to /lib/OLD_firmware; make new directories, and copy the tar file copies into them. Later I’ll try mounting the uSD files systems over those. Then eventually moving them to New_Modules and New_firmware and just mounting the uSD copy over the regular ones. This is not necessary to make this work, it is just me playing, learning, and finding the limits. All that’s really necessary is that copy off to a tar file, and then a tar extract into a new couple of /lib directories.

root@XU4devuan2:/SD/Ubuntu# ls
bin  boot  dev	etc  home  lib	lost+found  media  mnt	opt  proc  root  run  sbin  srv  sys  tmp  usr	var
root@XU4devuan2:/SD/Ubuntu# df

Filesystem      1K-blocks       Used  Available Use% Mounted on
[...]
/dev/sdb2        25508076     536100   23653168   3% /SD/Ubuntu

Note that it is presently about 500 MB.

Now I’m just going to set aside the old modules and firmware directories, make two new ones, and put the new stuff in them:

root@XU4devuan2:/SD/Ubuntu# cd lib/
root@XU4devuan2:/SD/Ubuntu/lib# ls
arm-linux-gnueabihf  ifupdown  klibc-wj8bPF_vWmgfISY5PwQIdrRif5U.so  lsb	 modules   systemd   udev
firmware	     init      ld-linux-armhf.so.3		     modprobe.d  startpar  terminfo
root@XU4devuan2:/SD/Ubuntu/lib# mv modules OLD_modules
root@XU4devuan2:/SD/Ubuntu/lib# mkdir modules
root@XU4devuan2:/SD/Ubuntu/lib# ls -ld modules OLD_modules/
drwxr-xr-x 2 root root 4096 Oct 13 21:52 modules
drwxr-xr-x 3 root root 4096 Jun  5  2018 OLD_modules/
root@XU4devuan2:/SD/Ubuntu/lib# mv firmware OLD_firmware
root@XU4devuan2:/SD/Ubuntu/lib# mkdir firmware
root@XU4devuan2:/SD/Ubuntu/lib# ls -ld firmware/ OLD_firmware/
drwxr-xr-x 2 root root 4096 Oct 13 21:53 firmware/
drwxr-xr-x 7 root root 4096 Jun  5  2018 OLD_firmware/
root@XU4devuan2:/SD/Ubuntu/lib# cd modules
root@XU4devuan2:/SD/Ubuntu/lib/modules# ls
root@XU4devuan2:/SD/Ubuntu/lib/modules# tar xf /SG2/ext/Save_Ub/Modules.tar 
root@XU4devuan2:/SD/Ubuntu/lib/modules# cd ../firmware/
root@XU4devuan2:/SD/Ubuntu/lib/firmware# tar xf /SG2/ext/Save_Ub/firmware.tar 

Clearly a lotof the size of Ubuntu is in all that firmwre for allthose devices you will never have on this board:

root@XU4devuan2:/SD/Ubuntu/lib/firmware# df .

Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sdb2       25508076 1117004  23072264   5% /SD/Ubuntu

and

root@XU4devuan2:/SD/Ubuntu/lib/firmware# df /SD/firmware/

Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/sdb3         999320 531548    415344  57% /SD/firmware

Get the info needed for the boot files:

root@XU4devuan2:/SD/Ubuntu/lib/firmware# file -s /dev/sdb2
/dev/sdb2: Linux rev 1.0 ext4 filesystem data, UUID=32810fef-0978-42bd-83ec-c72f9782e091, volume name "Ub_Devuan2" (needs journal recovery) (extents) (64bit) (large files) (huge files)

Now you can either pass that UUID or that LABEL=”Ub_Devuan2″. Looking in /dev/sdb1 or /SD/boot/boot.ini:

# Boot Args
setenv bootargs "console=tty1 console=ttySAC2,115200n8 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro fsck.repair=yes net.ifnames=0 ${videoconfig} ${hdmi_phy_control} ${hid_quirks} smsc95xx.macaddr=${macaddr} ${external_watchdog}"

Either swap the new UUID for that one, or change it to “LABEL=” type.

Next, we check fstab:

root@XU4devuan2:/SD/Ubuntu/etc# cat fstab
##                   
## bootfs
/dev/mmcblk0p1    /boot         vfat   defaults                  0    1

Note that blk0 not blk1. It’s expecting a mmc card location. We’re on a uSD in blk1 position. so change that to a 1.

In theory, that’s it. Unless I missed something. So now I’m going to try booting it. BUT, just to add some fun, I’m going to publish this and THEN see if it works. Back “whenever” with the update!

Subscribe to feed

RSBN Trump Rally, On The Road Again In Florida!

Happening now, Trump Rally in Florida!

Trump to arrive about 7 P.M. eastern, 4 P.M. Pacific.

Yes, Chinese Wuhan Covid can’t stop the Trump Train!

Right Side Broadcasting Network is once again able to broadcast live on YouTube. They also now have a collection of past rallies: https://rsbnetwork.com/category/rallies/ And they have a collection of the non-rally Trump events / videos: https://rsbnetwork.com/category/donald-trump/

Scheduled for tomorrow in Johnstown, PA:

The 14th in Des Moines Iowa:

And the 15 in Greenville North Carolina:

This guy sure starts off with a Bang! 4 in 4 days? And Sleepy Joe can barely do 30 minutes with a dozen friends every other week…

In Other News:

SCOTUS abuse started today. I watched bits of it, but the Dimocrats were once again being offensive and busy crapping on Amy at every turn, so I’ve not watched most of this. 5 hours worth:

I’ve not validated all the following links in a while, so I hope they are still correct.

They have an “RSBN 2” channel on youtube:

https://www.youtube.com/channel/UCCMhQoxdVuBXVidcdvsBtOw

So something of a backup in case of some kind of “technical glitch” on their first channel…

There’s also supposed to be a Periscope feed:

https://www.periscope.tv/RSBNetwork

After exploring the Diamond & Silk site for a good line while (it has videos too) I finally had it sink in that the RSBN feed is on the D&S YouTube channel:

The RSBN Twitter Feed:

https://twitter.com/RSBNetwork

The RSBN Facebook Page:

https://www.facebook.com/rightsidebroadcasting

On Patreon:

https://www.patreon.com/RSBN

My interest?

The one thing about RSBN that made it special was the pre-show and post along with the local / minor political speakers. A lot more variation and interesting stuff. Way better than the snips and cuts and talking heads droning of the MSM coverage.

YouTube stuck their foot in it with censorship. I HATE this political censorship. So it is now my intent to put up a posting for each Trump rally linking to RSBN and anywhere they can broadcast. To the extent YouTube tries to reduce anyone “leveraging” their platform to get Trump positive coverage, I’m going to lever what I can to give some balance back (however small). I’ll keep this up as long as there is YouTube Bias Risk.

It may not be much that I can do, but I’m going to do it. Now if all the other Deep State Opponents did the same… Just sayin’… You can be an “Army of One” even with just sending a link to a friend… or an enemy ;-)

Misc.

Ran into this interesting site “keeping up with Trump” while searching for other RSBN spigots (though at present the link is flaky):

https://keepingupwithtrump.com/rsbn-tv/

A pretty good write up of the “ban of RSBN” here:

https://reclaimthenet.org/youtube-livestream-right-side-broadcasting-ban/

Subscribe to feed