OPNsense Forum
Archive => 15.1 Legacy Series => Topic started by: franco on April 23, 2015, 07:15:36 pm
-
Hello my favourite kind of people :)
so there's finally some glue that allows to build direct disk images:
https://github.com/opnsense/tools/commit/5aadb136894f10c17092a8614fff2cc159b3a59d
Things that need your help and input now:
o Test the current 1G amd64 snapshot: https://pkg.opnsense.org/snapshots/OPNsense-201504231209-nano-amd64.img.bz2
o I only want to provide 1 additional image per architecture, so the question is 1G, 2G or 4G? 1G might be just big enough to run, 2G is reasonable, and 4G might be too big for some folks. What do you think?
o What should be different about this setup? I was thinking of making it dual serial/vga and enabling var and tmp MFS by default. Any other ideas?
o Upon further reflection a second slice doesn't hurt in case we decide to go down that road in the future. The bootstrapping is always kind of simple. It kills a bit of space, but even so it may make a few people happy in the progress (nanobsd can be operated on the command line as well).
Cheers,
Franco
-
From the price point I see no significant difference between 2G and 4G. It´s allready hard to find 1GB cards. So my suggestion is 4GB images. Jakob
-
What are the implications having a combined serial/vga image?
With monowall we had a serial and a separate vga, as far i remember.
Regards Jakob
-
Thanks Jakob, I think so too although only have 2GB card at the moment for testing purposes. ;)
I am putting back slice number two for a bit of testing and future use (we don't have the code to operate the second slice though), it makes 2G or 4G a lot more reasonable. Probably going to say 4G, yeah.
The implication dual serial/vga vs. serial or vga being:
(a) it should work but I can't confirm with my current test hardware (there may be a chance that's not possible)
(b) dual images prefer the serial for outputting kernel messages and main boot messages. That might be a hindrance for some people.
(c) SD card hardware with VGA but no serial isn't the most useful of combinations. I'm trying to find the sweet spot between usefulness and workload for the project (more image varieties mean more build time, more testing, a.k.a longer release cycles that could be spent developing things instead)
Cheers,
Franco
-
Franco,
Works on the APU Board. Did a dd to the SD card.
I was assigning the Interface via the Serial Port.
Jakob
-
My Soekris Net6501-70 has a 4GB SLC mSATAT SSD
At the time of purchase (2011), it was the best price/value option.
*B
-
After my first success with the PCengines APU where I configured the initial Settings via Serial Interface, I tried to do a Headless installation. (no serial Interface connection). I discovered this is not possible yet.
But I made during this second installation (writing the image again to the SD card) a strange discovery.
I was assigning the WAN Interface to the physical port (in my case "re1") and did a ping to the IP address and saw the following:
Request timeout for icmp_seq 246
Request timeout for icmp_seq 247
64 bytes from 192.168.10.237: icmp_seq=248 ttl=64 time=864.758 ms
64 bytes from 192.168.10.237: icmp_seq=249 ttl=64 time=0.399 ms
Request timeout for icmp_seq 250
Request timeout for icmp_seq 251
Request timeout for icmp_seq 252
Even after restarting the box twice I can't access the Box via the network. The Interface settings settings seems to be ok
root@OPNsense:~ # ifconfig
re0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:0d:b9:33:16:00
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (10baseT/UTP <half-duplex>)
status: no carrier
re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:0d:b9:33:16:01
inet 192.168.10.237 netmask 0xffffff00 broadcast 192.168.10.255
inet6 fe80::20d:b9ff:fe33:1601%re1 prefixlen 64 scopeid 0x2
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
re2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:0d:b9:33:16:02
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (10baseT/UTP <half-duplex>)
status: no carrier
pflog0: flags=100<PROMISC> metric 0 mtu 33144
pfsync0: flags=0<> metric 0 mtu 1500
syncpeer: 0.0.0.0 maxupd: 128 defer: off
enc0: flags=0<> metric 0 mtu 1536
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
inet 127.0.0.1 netmask 0x0
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Any Ideas?
BTW: Why we do not give this type of image a fixed IP address so it could be accessed for the initial configuration via Ethernet.
Jakob
-
o I only want to provide 1 additional image per architecture, so the question is 1G, 2G or 4G? 1G might be just big enough to run, 2G is reasonable, and 4G might be too big for some folks. What do you think?
Why not providing the smallest image size, and let users growfs their partition once installed ?
o What should be different about this setup? I was thinking of making it dual serial/vga and enabling var and tmp MFS by default. Any other ideas?
On a dual serial/vga image, what kind of multi-boot loader (boot0) will you use ?
boot0 is used to display this message during boot:
1 FreeBSD
2 FreeBSD
F6 PXE
Boot: 1
And this menu is very usefull on nanobsd using 2 system slices: If after an upgrade you didn't like the new version, you still can ask to boot the previous "version" (old slice).
But there are 2 versions of boot0:
- boot0, that use vga as default output: This message will not be display on a serial-only board
- boot0sio, that use serial as default output, this message will not be display on vga screen
o Upon further reflection a second slice doesn't hurt in case we decide to go down that road in the future. The bootstrapping is always kind of simple. It kills a bit of space, but even so it may make a few people happy in the progress (nanobsd can be operated on the command line as well).
Then if you aren't using 2 "system" slices today, I understand why you don't care of displaying boot0 message.
-
Just a update from my side. I can access the WAN interface via Browser. I was mislead by the fact that the Interface does not respond to Ping.
The remaining thing in my mind is the ability to start the box without the serial interface
Jakob
-
Hi,
just did a try on PC engines ALIX, here are the Results:
My guess is this HW needs a 32bit version.
+----------- Welcome to OPNsense ---------+
| |
| 1. Boot Multi User [Enter] |
| 2. Boot ingle User |
| 3. [Esc]ape to loader prompt |
| 4. Reboot |
| |
| Options: |
| 5. [K]ernel: kernel (1 of 2)
| 6. Configure Boot
| |
| |
| |
+-------------------------------+
/boot/kernel/kernel text=0x11d1e68 data=0x7d9bc8+0x215540 syms=[0x8+0x174b28+0x8+0x18da94]
Booting...
CPU doesn't support long mode
Error while including /boot/menu.rc, in the line:
menu-display
-
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
CPU doesn't support long mode
Type '?' for a list of commands, 'help' for more detailed help.
OK
-
Why not providing the smallest image size, and let users growfs their partition once installed ?
I don't think NanoBSD images are suitable for growfs as they pin down the partitions and also add a config partition that can't be disabled so you'll end up with a weird partition layout that's split in the middle.
On a dual serial/vga image, what kind of multi-boot loader (boot0) will you use ?
boot0 is used to display this message during boot:
1 FreeBSD
2 FreeBSD
F6 PXE
Boot: 1
And this menu is very usefull on nanobsd using 2 system slices: If after an upgrade you didn't like the new version, you still can ask to boot the previous "version" (old slice).
But there are 2 versions of boot0:
- boot0, that use vga as default output: This message will not be display on a serial-only board
- boot0sio, that use serial as default output, this message will not be display on vga screen
Since the dual boot prefers the serial anyway, boot0sio is preferred as well. Ideally, the VGA is a fallback only. In normal operation, we don't even need to manually boot as the partition is switched on upgrade.
In any way I'd like to start with the option with the most benefits for users, not with both options out of lack of asking the necessary questions. After all it is work and pressure for the project to provide more (and more) images.
Then if you aren't using 2 "system" slices today, I understand why you don't care of displaying boot0 message.
The NanoBSD code in core.git was overly convoluted and needed to be purged and can now be rebuilt. It's not that I don't care about the second slice, it's that I care about making it sane and simple and easy to maintain in the future. Like right now I'm thinking the second slice won't do any harm on a 4GB image so that we one day can magically use the dormant partition instead of telling users to reinstall their systems again. Because that's how we try to approach problems with OPNsense... :)
Cheers,
Franco
-
@Jakob: thanks for testing. 32 bit coming soon; at least the current script works already so that is good news :)
-
So here's the 32bit Image snapshot with two slices (2GB total):
https://pkg.opnsense.org/snapshots/OPNsense-201504271233-nano-i386.img.bz2
-
Franco,
I confirm the I386 version on SD Card image works on PCengines ALIX.
jakob
-
Thank you for testing, Jakob. Looks good. The 4GB image will be part of 15.1.10. :)