3.2labelexperimental

CHANGES

@@ -3,8 +3,21 @@
     ___________________________________________________   CHANGELOG
 
 
+                -add hid and composite gadget drivers @tba some auto-setup
+                -dnsmasq custom init.d nowan NOT> ok newbuilds only HARDENING_<service>_NOWAN=1
+                 @fboot>53-hardening > uci>service>nowan=1 dnsmasq&&dropbear&&uhttpd(noportsupport)
+
+                -merge/mangle mainline stage2 refactoring
+
+
+
+
                 -remove parted in favour of mainline package - add possible old version appzip/ipk install
+                -add basic 'is-olderversion(4-model-b)-without-parted' fboot_install_appzip@970-bdappzip
+                -re-add accidentally removed mailsend
+
 
+                -remove modemmanager be more mellow tweaks (update~refresh~or~drop)> keep still messed up
 
       3.2.1x
                 -fix luci@bootstrap-intrusion log duplicate denied page

README

@@ -3,6 +3,7 @@
 
 
 
+
     see: https://forum.openwrt.org/t/rpi4-community-build/69998
          to request packages, provide feedback etc.
 

builds/README

@@ -1,6 +1,33 @@
 
 
 
+    NOTE:
+           3.1 = stable [3.1.57-50 recommended]
+           3.2 = current (works ok-ish for basic setups)
+
+    3.2 introduces config-network-device changes as seen in
+    21.02... if starting(ed) on(pre) 3.1... it is possible
+    to upgrade<->downgrade
+
+    on downgrade an 'old' copy of your network settings is restored 
+    so any changes made on the new version/s are reverted
+
+    if starting(factory) on 21.02||3.2 it is not possible to downgrade
+
+    changing UPGRADEsFLAVOUR="current" #or stable will allow you
+    to toggle between stable||current as will;
+
+      rpi-sysuponline check stable
+      rpi-sysuponline -R stable
+
+      rpi-sysuponline check current
+      rpi-sysuponline -R current
+
+
+
+     NOTE: www(uhttpd) features under test mean that running
+           of www on untrusted(guest etc.) is not advised
+
 
     ################################################## builds
 
@@ -85,3 +112,321 @@
 
 
 
+
+
+
+
+
+    #NOTE THESE INSTRUCTIONS NEED UPDATING / HARMONIZING
+    #DETAILS ABOUT NOTEWORTHY SPECIFIC BUILD FEATURES PARTUUID / PERFTWEAKS(old/off)/OTHER old NOTES
+
+
+
+
+
+	######################################### partuuid-notes
+
+
+		NOTE(old): usb_testing > partuuid_testing ready for beta testing
+        #############################################################
+        (well, moderate to advanced users with manual and dd backups
+        should be ok?)
+        https://forum.openwrt.org/t/rpi4-community-build/69998/502?u=wulfy23
+
+
+        SIMPLIFIED PARTUUID NOTES
+
+			-if you restore a traditional backup you should always check cmdline.txt
+             and your current PARTUUID (blkid) to verify it is correct
+             /dev/mmcblk0p2 is ok for mmconly usage
+
+            -best to use another disk or dd backup your mmc ( plus normal backups as usual )
+             factory installs disregard
+
+            -novice-users / anyone using the build in a production capacity are advised
+             wait for a week or two or use factory only on newdisk
+             factory installs disregard
+
+            -non-factory installation (sysupgrade) and wish to switch disk around later
+             update cmdline.txt with root=PARTUUID=abcdefgh-0N AFTER install
+             $> blkid $(findmnt /) #to get partuuid
+
+             (note: if you started on mmc flash this and stay on mmc then root=/dev/mmcblk0p2 if fine )
+
+
+            -use a low power requirement usb disk (non-mmc users)
+
+            -see forum-post/rpi-documentation re: boot-order... by default... the mmc needs to
+             be removed in order to attempt to load from usb drive
+
+            -if you get no boot and have no serial plug into a pc -> fsck ->
+             mount fatpart1/boot -> check your PARTUUID / cmdline.txt
+             root=/dev/mmcblk0p2 is fine for mmc-only use...
+             for dual use or usb only dont rely on /dev/sdX
+
+
+
+        KNOWN-ISSUES:
+            -argon theme splash page intermittent on reboot
+             i've limited it to twice but old scripts are orphaned... need to poke
+             around upstream a little of fix in next few weeks
+
+        FIXED-ISH:
+			-sqm may not start on firstboot/boot (workaround implemented seems ok 20210311)
+			-luci_statistics->collectd->sqm.sh respawn issue (present for 2+months)
+             (workaround implemented 20210311)
+
+
+
+
+
+
+    ################################################  recent builds tofix
+
+            -fwcustom/dscp disabled(20210121->dscpnowRPI4_QOS@.qos)
+            -package selections add / trim / tweak
+            - -R packagerestore not perfect
+
+
+
+
+
+    ############## old-notices
+
+
+
+        PERFTWEAKS-IN-TEST - ENDED NO LONGER INCLUDED DUE TO MINMAL FEEDBACK
+
+        OFF Builds after rpi-4_snapshot_2.9.17-7_r16357
+        OFF contain experimental PERFTWEAKS https://forum.openwrt.org/t/rpi4-community-build/69998/715
+
+        OFF If you are on the build above(or older) you can just pull down the related files
+        OFF to test read the link above for more info
+
+        OFF Testing / tweaking will likely be an ongoing process... > ok things are starting to pan
+        out now...
+
+
+
+        THEMEODDITY:        noticed that argon may switch back to bootstrap for no apparent reason
+                            could be something on my system but im keeping an eye on it...
+                            use bootstrap or set LUCIDEFAULTTHEME="bootstrap" to mitigate for now
+
+
+
+
+
+
+		!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+        IMPORTANT: build users running pre r15599 releases are advised to update
+        ( or check dnsmasq version is above 2.82 -> above 2.83 for logspamfix )
+        https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq-multiple-vulnerabilities/85903
+        !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+        +odhcp6c +netifd +libwolfssl24
+
+
+
+        20201123 opkg outage... (downloads.openwrt.org)
+
+        20201125 downloads stale for 2 days...
+
+        20201110
+        -master has been fairly volatile of late... unstable
+         sample build for testing usage...
+
+
+
+
+
+        NOTICE: USERS OF BUILDS prior to r15199 are advised
+                to update / upgrade due to openssl vulnerability
+        CVE-2020-1971
+        https://forum.openwrt.org/t/rpi4-community-build/69998/328
+
+
+
+
+
+
+
+
+
+        NOTE: usb_testing > partuuid_testing ready for beta testing
+        #############################################################
+        (well, moderate to advanced users with manual and dd backups
+        should be ok?)
+
+
+        https://forum.openwrt.org/t/rpi4-community-build/69998/502?u=wulfy23
+
+        SIMPLIFIED NOTES
+
+            -best to use another disk or dd backup your mmc ( plus normal backups as usual )
+
+            -non-factory installation (sysupgrade) and wish to switch disk around later
+             update cmdline.txt with root=PARTUUID=abcdefgh-0N
+
+            -backup restore from alternate disk or old above applies ( before reboot )
+             (note: of you started on mmc flash this and stay on mmc then root=/dev/mmcblk0p2 if fine )
+
+            -use a low power requirement usb disk if using on usb
+
+            -see forum-post/rpi-documentation re: boot-order... by default... the mmc needs to
+             be removed in order to attempt to load from usb drive
+
+
+
+
+
+
+
+
+
+
+
+
+
+       USB-PARTUUID-VERBOSE-NOTES
+
+
+                -as above re:uas/ssd likely existed on older builds also
+                -probable luci_statistics minor oddities or manual migration / refresh / required
+
+                best tried on a new usb/mmc disk ( it is not specific to usb
+                and makes the disk pluggable either way  )... or dd backup
+                your mmc if you are game to sysupgrade over that... ( due 
+                to cmdline.txt being part of the backup... you'd have to 
+                update your root=PARTUUID=ABCDEFGH-02 this is not mandatory
+                and only really help is the disk is inserted / copied to a
+                non-mmc slot  )
+
+            -best flashed to a new disk... (but sysupgrade capable with hand edit of cmdline.txt)
+
+            -note: on usb2 flashing takes approx 12mins + 3mins for firstboot init
+             ( approx 3xslower dont have usb3-disk to test with )
+             correction... that was a usb3-sdreader... usb3-ssd@5years old is comparable to mmc
+             read seems faster
+
+            -if you restore config files... do not restore cmdline.txt ( clone/setup root=PARTUUID= )
+
+            -if you use sysupgrade on your existing mmc... optional but recommended to update your
+                 cmdline.txt also to root=PARTUUID= AND make a 'dd' dump+backup of your mmc card
+                 in it's original state
+
+            -also recommended to have serial access just in case ( will be needed for debugging/support )
+
+            -fwiw my boot order is inverted to try usb first then mmc (0xf14)
+
+            -any requests for support should state;
+               -you used a factory/sysupgrade to install?
+               -what cmdline.txt/partuuid was before and is now
+               -where the disk was plugged into before and is now
+               -console boot output and your (pi)firmware version
+
+
+
+
+
+    more detailed comments
+    ################################################ cmdline.txt restore caveat 2.7.23+
+
+    if you restore a backup from a different 'disk' (factory) you will need to
+    check / manually repair /boot/cmdline.txt root= prior to reboot if it is
+    set to PARTUUID or you will be using the new disk as alternate usb/mmc
+
+    short term I recommend not intermixing backups per disk
+    ( use a new and preferably different build for usb )
+
+    or if you never intend to use usb you can change the cmdline.txt back to
+    root=/dev/mmcblk0p2
+
+    vice versa if you are switching to usb you should update your root=PARTUUID
+    to that of the disk prior to unplugging / dd in this case you should only
+    have one instance of that disk plugged in at a time... 
+
+
+
+    ################################################ uuid(real) caveat
+
+    not yet writing new real UUID so you may need to do that if you
+    have config/fstab mounts and mmc + usb installs plugged
+    in at the same time
+
+
+
+
+
+    ######################## minimal-migration list
+
+
+
+#/boot/config.txt
+#edited /boot/cmdline.txt if you wish to support disk switching and are flashing a sysupgrade
+
+
+/etc/passwd
+/etc/shadow
+/etc/group
+/etc/uhttpd.crt
+/etc/uhttpd.key
+/etc/config/network
+/etc/config/dhcp
+/etc/config/sqm #adblock banip statistics etc
+/etc/config/system #optional
+/etc/config/fstab #optional
+/etc/dropbear/
+/root/.ssh
+/root/wrt.ini
+
+#/etc/packagesinstall.txt
+#/etc/packagesremove.txt
+#/etc/luciqrcodes.txt
+#/boot/plog/
+#/tmp/rrd
+#var nlwmon/
+#/etc/crontabs/root
+
+#/etc/inittab
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+   #OLD
+
+
+   NOTE: usb_testing is experimental (see README)
+
+   ################################################ package specific notes
+
+        openvpn-2.5 ( older builds had sec bugs no longer available pre~r15185ish )
+
+        odhcp6c@watching re: improvements?
+
+        mwan/wifi being fixed in master are two key fixes to keep an eye out for...
+            *) 20201209 current state not really known... many ongoing changes
+            *) 20201029@r14779+ mwan pr 2 10 was pushed
+
+
+
+