Re: [gentoo-user] Strange UEFI boot behaviour

2022-07-11 Thread Michael
On Monday, 11 July 2022 01:25:00 BST Peter Humphrey wrote:
> On Sunday, 10 July 2022 17:37:00 BST Michael wrote:
> > This is happening if the EFI firmware for some reason has re-scanned the
> > attached block devices to find bootable UEFI images.  I've seen something
> > as simple as rebooting with, then without a bootable USB drive causing
> > this. Since the images boot order is editable, in your case via bootctl,
> > then it should be a fixable problem.
> 
> But, as I said, the order is unchanged, yet the BIOS displays them in
> reverse order. I think the BIOS is not long for this world, as you will
> see...
> 
> This machine shows bizarre behaviour in booting as well. Often, as soon as
> the POST is finished and the BIOS asks which kernel image to hand over to,
> I have no keyboard or mouse - except for CTRL-ALT-DEL, which does reboot.

Check your BIOS* firmware settings for USB and enable xHCI.  Perhaps this 
setting was toggled to auto, which may not work reliably.

* I use the word "BIOS" to describe the UEFI firmware menu on a modern MoBo, 
rather than the legacy CMOS stored BIOS.


> The thing that got me exercised today was Gentoo complaining that it
> couldn't mount /boot - wrong FS type or...etc. So I had to do something. 

You could have checked with fsck.fat to see what the /boot/EFI partition 
reported, but since you reformatted the ESP it's all new and in working order 
now.


> So
> today (well, yesterday now) I told the BIOS to load its standard optimised
> defaults, then rebooted, then told it to load my tuned set and rebooted
> again. Then I booted a SystemRescueCD (because the USB version showed that
> same no- keyboard problem), formatted /boot with FAT32, zapped / then
> recovered a week- old backup. Then, still in RescCD, a sync and
> world-update brought the system back.
> 
> Even then, running bootctl remove; bootctl install; replace /boot/loader/
> loader.conf; bootctl update - still left no UEFI boot option for the Gentoo
> system, though it usually does create one. I had to use efibootmgr to create
> a boot option, then do the bootctl dance again.
> 
> Finally, a bootable, running system.
> 
> Oh, one other thing. This machine has a small unformatted partition before /
> boot, and gparted on the rescue CD showed me that it had lost its bios_grub
> flag. Could that account for the wrong FS type error?

Yes, it is probable you mixed up legacy BIOS (CSM) Vs UEFI booting.  You need 
to make sure when you boot with Live media you boot in UEFI mode.

The EFI firmware can be set up to emulate a legacy BIOS configuration, by 
enabling its Compatibility Support Module (CSM).  This setting allows legacy 
OSs to boot with a conventional MBR boot loader from a GPT disk.  The problem 
which arises on a GPT formatted disk is where to store GRUB's 2nd Stage image.  
Normally, on a disk with a MBR partition table, the space immediately after 
the MBR on sector 0 contains GRUB's 2nd Stage image.  On a GPT disk the first 
sector is used to store the GPT partition table and therefore GRUB's 2nd Stage 
image  has to be stored somewhere else - in the marked bios_grub partition. 

An EFI MoBo which boots an OS installed in UEFI mode, on a GPT formatted disk, 
does not require a CSM or a bios_grub flagged partition.  I assume you've 
installed your OSs in UEFI mode and you do not intend to run WinXP on bare 
metal.  In this case, disable CSM.


> Should I consider re-flashing the BIOS? It's getting on for 10 years old. I
> did that to another machine once, thereby killing it stone dead.

As you attest some folk have had bad experiences with flashing new firmware on 
their MoBos.  I first check if the new firmware is meant to address any issues 
which affect my OS and peripherals and if it does, then I go ahead and flash 
it.  
If the release offers fixes irrelevant to my kit and OS, I leave it alone.  I 
have not yet had a single MoBo fail on me, even after multiple flash 
operations.  As long as the flash operation is not interrupted and the image is 
the correct image for the hardware, I would think the flash operation should 
complete successfully without having to J-TAG the chipset.  On a 10 year old 
MoBo I would consider replacing the NVRAM battery prior to (re)flashing.

signature.asc
Description: This is a digitally signed message part.


[gentoo-user] MAC whitelisting and UDP traffic.

2022-07-11 Thread Laurence Perkins
Ok, I asked a while ago about whitelisting MAC ranges for firewall rules, and 
just so you know, adding 16 million potential MAC addresses to the firewall...  
Doesn't work well...  No matter how you do it.  So I had to write a daemon to 
monitor which ones were local and add just those.  Whatever.

That brings me to the next problem.  The routing and NAT work just fine if I'm 
letting everything through.  But if I'm dropping connections that don't come 
from authorized devices then UDP only works in the outbound direction...  TCP 
is fine.

For reference, the rules consist of:

iptables -t nat -I POSTROUTING -o  -j MASQUERADE
iptables -A FORWARD -i   -o  -m state --state 
RELATED,ESTABLISHED -j ACCEPT

And then the daemon adds a:
iptables -A FORWARD -i  -o  -m mac --mac-source  
-j ACCEPT

for each authorized device.

TCP works perfectly.
UDP based protocols send out just fine, but any replies get blocked if the 
FORWARD chain's default policy is  DROP.

Now...  Everything I'm reading says that it's supposed to be able to associate 
UDP replies based on port number, which indeed it must be doing in order for 
them to get translated correctly and directed to the correct device inside the 
NAT when the default policy is ACCEPT.

So why is that rule to accept related packets not triggering for them?  And is 
there a standard way to do this?  Because everything I can dig up on Google is 
examples just of routing with no NAT involved and nobody reporting this problem 
anywhere.

I'll keep playing with it, but at this point I'm just throwing random stuff 
against the wall, so any hints would be appreciated.

LMP