Messages

Yes please, if you can run up 22.1 and then copy the dhclient over to that and reboot, see if it works... if not then we need to look elsewehere for the issue, but I suspect that it's the client.

I finally make the image of 22.1 written on an USB key, see other post ...

What if I write your Dhclient on the USBkey to test it from live boot ? will the test be the same ?
To be honest I don't really want to update, test, reinstall(or not) and so on ^^ but I agree to make some test !

Hi,

[/quote]
What exactely do you mean by writing fails? Is the created USB media not bootable?
[/quote]

That means that Rufus fails to write the image on the key near 4% of the writing process.

Do you mean that you have successfully written the image ?

Hi,

I will give it a try tomorrow, I need internet today ^^

@marjohn56 my ISP is not OR france (presume it's orange) but like orange I need a VLAN to bypass the box.

@nemric  - Seems the version from 21.7 is working OK, at least on my test device so I'm attaching it here. No guarentees, but try it. At least you have a local device and can revert. @nivek1612 is concerned he might lose everyhing if he tries, so would you try it and let us know? Remember to set the permissions to 0555 after copying the attached to /sbin .

Hi, I'm not sure to understand what you ask me for.
I'm running 21.7 now, and my vlan100 get an ip from ISP and everything works fine

The file you want me to try is for 22.1 ?

Have you verified checksums each time? If not, I start from there.

Yes I did it and I get files from different mirrors.

You uncompressed it? bz2 is not the raw image. Use 7zip.

No, I didn't uncompress the files, Rufus allow creating boot key directly from img.bz2 and it works great with v21.7.img.bz2 in the same way

Hi,
I ran update yesterday but I had a problem, well, went back to 21.7.
I've downloaded OPNsense-21.7.1-OpenSSL-vga-amd64.img.bz2 and write it to my usb key with Rufus, everything was right
Now I'd like to do the same for testing purpose with 22.1 but writing USB key fail with all images
Try it again with 21.7 and it worked so is there a problem with the new image ?

It's not the first time it fails like that with opnsense images, I can't remember the last time it happened but it happened

Did someone make it work ?

Yes I had to reinstall form an USB key. I didn't find any way to downgrade

you're right, I'm now back to 21.7

I can't believe it's true....
I went back to 21.7.8 (and VLAN is up) and I've made a packet capture for dhcp

The captures are the same execpt for 1 thing :
option (53) DHCP Message Type is discover for v22.1
option (53) DHCP Message Type is request for v21.7

in both cases I can't see option 60 vendor-class-identifier :/

I've removed this option (vendor-class-identifier "BYGTELIAD") from interface settings and it works :/

I won't have more time today to investigate deeper, see you later

Hi,

I've upgraded today for the new release, and my vlan vlan don't go online.

my config :
vlan100 on em1
assigned to an interface with options :
- spoof mac : xx:xx:xx:xx...
- send option : vendor-class-identifier "BYGTELIAD"

I've run a packet capture and only options :
53 DHCP message
50 requested ip
61 client identifier
12 host name
55 parameter request list
255 END

are sent

Option 60 vendor-class-identifier is missing

It was working like a charm before upgrade so it seems that it's a regression

Thanks a lot for your answer Alphabet Soup :)

This solution (having /tmp and /var on usb key) isn't a good idea at all !

I did it because the update from 19.1 to 19.7 failed because of memory size ...

Having these "drives" on USB key slow down opnsense a lot and I finally decide to keep /var on MFS and /tmp on full 4GB usb key size expecting that updates uses /tmp for download and/or unpacking update files.

USB key is now freebsd-ufs ...

Last question : Is tmpfs file system make it backuped on CF (ada0) or is this done every time ?

Hi,

I tri to setup /var and /tmp to an USB key formatted as

Code Select Expand

root@xxx:/etc # gpart show da0
=>     40  7866288  da0  GPT  (3.8G)
       40  4194304    1  freebsd-ufs  (2.0G)
  4194344  3671984    2  freebsd-ufs  (1.8G)

My fstab looks like :

Code Select Expand

root@xxx:/etc # cat /etc/fstab
# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/ufs/OPNsense       /               ufs     rw,noatime      1       1
/dev/da0p1              /var            tmpfs   rw              2       2
/dev/da0p2              /tmp            tmpfs   rw              2       2

Code Select Expand


root@xxx:/tmp # df -a -H
Filesystem           Size    Used   Avail Capacity  Mounted on
/dev/ufs/OPNsense    2.0G    1.0G    837M    55%    /
devfs                1.0k    1.0k      0B   100%    /dev
tmpfs                1.8G     24M    1.8G     1%    /var
tmpfs                1.8G    184k    1.8G     0%    /tmp
devfs                1.0k    1.0k      0B   100%    /var/dhcpd/dev
devfs                1.0k    1.0k      0B   100%    /var/unbound/dev


Capacities in "df" are not same a defined in "gpart"

Is there a way to make it work ?
How to be sure that /tmp and /var are well mounted on /dev/da0p1 ans /dev/de0p2 ?

thanks :)

Thanks, well understood ;)

Regards,
Nemric

Yes I've found these posts ...

What about "LTS" on I386 ? At least for security updates ? thanks

Hie,

Just made update of my opnsense to 19.1.7 release and guess what ?

"And speaking of 20.1: This is the first of many reminders that 20.1 will discontinue the i386 (Intel 32 Bit) franchise as discussed a number of times within the community over the years. Our hope is that ARM64 will make a viable replacement. But that is for another time."

I went to Opnsense from Pfsense thanks to I386 support, my hardware is a low power MSI 9A19 with Atom N270 32 bit that works great and support will be discontinued in 6 months, I'm so disappointed ...

I don't understand that choice of dropping old hardware support ... Is their some hope for having a kind of LTS on 19.x.x version ?