How easy/hard are updates/upgrades?

Christoph Harder shadowomf at arcor.de
Sun Jan 22 12:05:23 PST 2023 

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
>>>
>>>
>>>
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA362479F3F0ADC06.asc
Type: application/pgp-keys
Size: 1440 bytes
Desc: OpenPGP public key
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20230122/c6597d0e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 321 bytes
Desc: OpenPGP digital signature
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20230122/c6597d0e/attachment-0001.bin>

More information about the Users mailing list