How easy/hard are updates/upgrades?

Sun Jan 22 16:06:21 PST 2023

The installer will NOT copy modifications done to loader.conf on the 
install media to a new install. When installing FreeBSD on APU machines, 
I would typically opt to modify the installation before rebooting, then 
add the serial console options, then exit and reboot into the new install.

If you did not add the console options when installing, you are on the 
right track. Boot the install media, mount the SSD, modify the 
loader.conf to include the console settings, then reboot.

You might want to refer to this document to get a feel for disk layout: 
https://www.dragonflybsd.org/docs/handbook/Installation/

Essentially, after booting the install media you probably need to do 
something like the following:
# mount_hammer2 /dev/da0s1d /mnt
# mount /dev/da0s1a /mnt/boot

Then edit loader.conf. You could just mount da0s1a on /mnt, but wanting 
to illustrate the way the volumes are actually mounted.

On 1/22/23 13:05, Christoph Harder wrote:
> Hi Seann,
>
> good to know, that you're also using boxes made by them, maybe you can 
> help me a bit more?
>
> To run the installer I added
>     sio0.flags=0x10
>     sio0.baud=115200
>     set boot_serial="YES"
>     console=comconsole
>     set comconsole_speed=115200
> to the loader.conf of the usb stick I used to install.
>
> To prevent constant output of messages like
>     Jan 22 18:14:26 getty[2228]: open /dev/ttyv4: No such file or 
> directory
>     Jan 22 18:14:26 getty[2229]: open /dev/ttyv5: No such file or 
> directory
>     Jan 22 18:14:26 getty[2231]: open /dev/ttyv4: No such file or 
> directory
>     Jan 22 18:14:26 getty[2232]: open /dev/ttyv5: No such file or 
> directory
>     Jan 22 18:14:26 init: getty repeating too quickly on port 
> /dev/ttyv5, sleeping 30 secs
>     Jan 22 18:14:26 getty[2233]: open /dev/ttyv4: No such file or 
> directory
>     Jan 22 18:14:26 init: getty repeating too quickly on port 
> /dev/ttyv4, sleeping 30 secs
> I've edited /etc/ttys and disabled the virtual consoles.
>
> However even after completing the setup, I'm not able to boot from the 
> SSD.
> I suspect I might need to change the settigs regarding loader.conf and 
> /etc/ttys on the SSD, since I'm not sure that the installer will copy 
> the settings to the SSD.
>
> When I try to start the live image and mount the file system from the 
> SSD I do get various failures.
> Maybe I'm just doing it wrong?
>     root@:/dev # mount_hammer2 /dev/da0s1 /mnt
>     hammer2_mount: devstr="/dev/da0s1 at DATA"
>     hammer2_mount: device="/dev/da0s1" label="DATA" rdonly=0
>     hammer2_ondisk: /dev/da0s1 #0: bad magic
>     hammer2_ondisk: /dev/da0s1 #1: bad magic
>     hammer2_ondisk: /dev/da0s1 #2: bad magic
>     hammer2_ondisk: /dev/da0s1 #3: bad magic
>     hammer2_ondisk: /dev/da0s1 has no valid volume headers
>     hammer2_ondisk: failed to read /dev/da0s1's volume header
>     mount: Invalid argument
>
> I also managed to crash the system by accidentially entering /da0s1 
> instead of /dev/da0s1:
>     root@:/dev # mount_hammer2 /da0s1 /mnt
>     hammer2_mount: devstr="/da0s1 at DATA"
>     hammer2_mount: device="/da0s1" label="DATA" rdonly=0
>     panic: assertion "strncmp(path, "/dev/", 5) == 0" failed in 
> hammer2_init_devvp 7
>     cpuid = 3
>     Trace beginning at frame 0xfffff801179f2c18
>     hammer2_init_devvp() at hammer2_init_devvp+0x48b 0xffffffff8098589b
>     hammer2_init_devvp() at hammer2_init_devvp+0x48b 0xffffffff8098589b
>     hammer2_vfs_mount() at hammer2_vfs_mount+0x379 0xffffffff8096a4d9
>     sys_mount() at sys_mount+0x33b 0xffffffff80702d7b
>     syscall2() at syscall2+0x11e 0xffffffff80bdc0ae
>     Debugger("panic")
>     CPU3 stopping CPUs: 0x00000007
>      stopped
>     Stopped at      Debugger+0x7c:  movb    $0,0xbcbd09(%rip)
>     db>
>
> Do you know if it is even necessary to change the console settings on 
> the SSD in an additional step?
>
> Best regards,
> Christoph Harder
>
>
> Am 22.01.2023 um 19:42 schrieb Seann Aswell:
>>> E.g. could I use a server to build the binaries and then sync them 
>>> with some embedded system (with a processor that probaby doesn't 
>>> support the latest SSE, AVX, ...)? 
>>
>> Well, ping me in a week and I will know for sure. Currently migrating 
>> a few APU and Atom boxes from FreeBSD to DragonFly, and will be 
>> compiling on more powerful hardware.
>>
>> However, my guess is that it won't matter. DragonFly currently only 
>> supports x86-64, and everything should be compiled regardless of 
>> whether the hardware uses it. If certain capabilities are not 
>> supported by the hardware, they won't be loaded or used by the kernel.
>>
>> That is my guess, but will find out soon, and someone will chime in 
>> if I am leading you astray...
>>
>>
>> On 1/22/23 00:34, Christoph Harder wrote:
>>> Hello Seann, Hello Balázs,
>>>
>>> thank you for your fast feedback and the links.
>>>
>>> Having a separate non-critical machine for building and testing 
>>> would indeed make sense and avoid many potential problems.
>>> Is it important to build on the same hardware or will the build 
>>> process always produce the same results independent of the hardware 
>>> it is running?
>>> E.g. could I use a server to build the binaries and then sync them 
>>> with some embedded system (with a processor that probaby doesn't 
>>> support the latest SSE, AVX, ...)?
>>>
>>> Best regards,
>>> Christoph
>>>
>>>
>>> Am 22.01.2023 um 07:46 schrieb Seann Aswell:
>>>> I too have had 'freebsd-update fetch upgrade' result in issues, so 
>>>> while FreeBSD's binary update process is easy, it isn't bulletproof.
>>>>
>>>> I personally don't recall ever having an issue with DragonFly's 
>>>> source updating process, but keep in mind that compiling source is 
>>>> required, so on resource constrained systems it can take quite a 
>>>> while.
>>>>
>>>> Having been responsible for supporting various systems remotely in 
>>>> the past, your concern is completely understandable. Once you go 
>>>> thru the process a few times, you will gain confidence in updating 
>>>> remotely, as long as you have a backup snapshot of the OS and 
>>>> someone is onsite in case there are issues.
>>>>
>>>> FYI- A few resources about updating constrained systems:
>>>> https://marc.info/?l=dragonfly-users&m=149234716521744&w=2
>>>> https://umbriel.fr/blog/Upgrading_DragonFly_BSD_hosts_with_a_central_build_server.html 
>>>>
>>>>
>>>> The other advantage of updating from a central source is that you 
>>>> can test with a non-critical machine, and be pretty confident it 
>>>> will work on others.
>>>>
>>>>
>>>> On 1/21/23 12:30, Christoph Harder wrote:
>>>>> Hello everybody,
>>>>>
>>>>> maybe this question should be extended with "How bulletproof are 
>>>>> updates/upgrades?".
>>>>>
>>>>> I've used FreeBSD as OS for three VPN gateways, but keeping the 
>>>>> systems up to date was always a problem.
>>>>> Multiple times manual conflict resolution was required. Sometimes 
>>>>> remote access to the systems failed while/after an update, causing 
>>>>> downtimes and requiring me to go to the systems.
>>>>> Now this might not be a FreeBSD problem, I'm certainly no expert.
>>>>> Anyway, the result was, that I generally only did updates when I 
>>>>> was near the systems and did updates not as often as I would have 
>>>>> liked.
>>>>> I did the updates by myself, since anytime a manual conflict 
>>>>> resolution would be required none of the other users could do it. 
>>>>> Ideally updates/upgrades would be so easy that anybody can do it 
>>>>> or that they can be automated.
>>>>>
>>>>> Now to the actual question. How easy/hard/bulletproof are 
>>>>> DragonflyBSD updates/upgrades?
>>>>>
>>>>> https://www.dragonflybsd.org/docs/handbook/Upgrading/ looks super 
>>>>> easy, but so did the update/upgrade manual of FreeBSD.
>>>>>
>>>>> Is the upgrade process on Dragonfly BSD easy enough that you could 
>>>>> describe the process to a (non-technical) user over the phone?
>>>>>
>>>>> Best regards,
>>>>> Christoph Harder
>>>>
>>>>
>>>>
>>
>>