Notice: To avoid posts by spam, a message body without the word '#FuguIta' is rejected.
Please include the word in your message text.
Mel (2021-04-27 (Tue) 15:35:18)
i try to follow how to setup development for #FuguIta from this JPN page "河豚板の開発ツールを使う - LiveDVDのカスタマイズと作成".
i download the construction tool tools-6.8-amd64.tar.gz. there is .ffsimg file (media/fuguita-6.8-amd64.ffsimg).
i understand this is for OpenBSD 6.8, if i want 6.9 this ffsimg should be updated. but, my question is, how do you create this .ffsimg file for each new release of OpenBSD?
m3th (2021-04-24 (Sat) 18:32:09)
Can I syspatch to #FuguIta?
kaw (2021-03-23 (Tue) 18:01:06)
Prototyped a trial version of #FuguIta based on OpenBSD-current (6.9-beta).
It is only available for the amd64 architecture.
Get it from "test" directory on download mirrors.
Your trial reports are welcome.
kaw (2021-02-16 (Tue) 19:00:58)
Two new mirror servers in Europe are now in operation.
They are de.dl.fuguita.org and fr.dl.fuguita.org, the successors to eu.dl.fuguita.org.
eu.dl.fuguita.org will be out of service in a few weeks.
I would like to express our sincere gratitude to the administrators of eu.dl.fuguita.org and everyone who are providing the mirror servers.
(2021-01-30 (Sat) 07:41:07)
I can use a second monitor with OpenBSD. I cannot use a second monitor with #FuguIta.
r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin" [drm] *ERROR* Failed to load firmware! drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init drm0 detached radeondrm0 detached
I saved settings after downloading the firmware, rebooted, and do have "/radeon/SUMO2_pfp.bin". I assume this error happens because the boot process executes the GPU init before I can choose boot mode 3. Is there an easy way to fix this error, myself?
Sorry. I am inexperienced with BSD (and computers).
# gzip -dc /sysmedia/bsd-fi.mp > bsd-fi.mp # vnconfig vnd0 bsd-fi.mp # mount /dev/vnd0a /mnt # mkdir -p /mnt/etc/firmware # (copy radeon's firmwares under /mnt/etc/firmware) # umount /mnt # vnconfig -u vnd0 # mount -uw /sysmedia # gzip -c9 bsd-fi.mp > /sysmedia/bsd-fi.mp # mount -ur /sysmedia
-- kaw 2021-02-01 (Mon) 09:21:51
kaw (2021-01-09 (Sat) 23:04:26)
Recently, I found reviews and tutorial videos about #FuguIta on the net, so I will introduce them.
I am deeply grateful to the authors of these articles.
kaw (2020-11-03 (Tue) 23:37:38)
Tools to create a live system based on OpenBSD 6.8 were uploaded at tools directory.
To use this tool, refer the article 河豚板の開発ツールを使う - LiveDVDのカスタマイズと作成 (LiveDVD - Using FuguIta development tools) in the page 河豚板ガイド (FuguIta Guide).
Fugu (2020-10-24 (Sat) 22:05:09)
Any chance of getting #FuguIta working with ventoy at www.ventoy.net/en/index.html.
No pressure - just asking since Fugu's broader goals align with such a tool.
kaw (2020-10-24 (Sat) 00:30:25)
#FuguIta-6.8-i386 and FuguIta-6.8-amd64 are now under test.
These are at test directory at download mirrors.
Your trial report is greatly appreciated.
kaw (2020-09-24 (Thu) 22:13:14)
I'm currently working on a Live Update for #FuguIta LiveUSB.
This is in beta testing.
To update with this utility, place the gzipped ISO image (not the *.img.gz file!) and the MD5 checksum file in the current directory.
Then run the fiupdate command.# cat /usr/fuguita/version 6.7-amd64-202008261 # ls -l total 606528 -rw-r--r-- 1 root wheel 310528773 Sep 24 18:47 FuguIta-6.7-amd64-202009041.iso.gz -rw-r--r-- 1 root wheel 11660 Sep 24 18:47 MD5 # fiupdate 202009041 fiupdate - Live Updater for FuguIta LiveUSB Version/Arch: 6.7/amd64 (FuguIta-6.7-amd64-202008261) Note: This sorftware is now under beta test. Please use this at YOUR OWN RISK. We recommend that you execute this command with fresh boot (boot mode 0 or 1). Or you should quit all application softwares and save all your data before you update this FuguIta device. Are you sure? [y/N] -> y Checking: environment: ok mounts: ok existing files: ok checksum: (MD5) FuguIta-6.7-amd64-202009041.iso.gz: OK all done, OK. extracting FuguIta-6.7-amd64-202009041.iso.gz... 296MiB 0:00:48 [6.12MiB/s] [================================>] 100% ETA 0:00:00 Now ready to update FuguIta-6.7-amd64-202008261 to FuguIta-6.7-amd64-202009041. This machine will reboot immediately after update completed. Do you proceed? [y/N] -> y stopping all daemons... cron(ok) ntpd(ok) pflogd(ok) slaacd(ok) smtpd(ok) sndiod(ok) sshd(ok) syslogd(ok) overwriting uniprocessor kernel... 8.68MiB 0:00:03 [2.31MiB/s] [================================>] 100% ETA 0:00:00 overwriting multiprocessor kernel... 8.71MiB 0:00:03 [2.23MiB/s] [================================>] 100% ETA 0:00:00 overwriting filesystem image... 894MiB 0:04:25 [3.36MiB/s] [================================>] 100% ETA 0:00:00 update completed. now rebooting... syncing disks... done rebooting...
We welcome your trial report.
kaw (2020-09-08 (Tue) 14:07:35)
isotop is a script to configure and customize vanilla OpenBSD into ready-to-use desktop environment.
I have modified isotop to be able to run on #FuguIta.
To run isotop.sh on FuguIta after download it, apply this patch isotop-665-fi.sh.diff .
Then run install script as a root.$ ftp https://framagit.org/3hg/isotop/raw/master/src/isotop.sh $ patch < isotop-665-fi.sh.diff # sh isotop.sh
Here's a screenshot of FuguIta configured by isotop.
kaw (2020-07-22 (Wed) 15:27:51)
Open Source Conference 2020 Online/Niigataが7月25日(土)に開催されます。
今回はオンラインでの開催になります。https://ospn.connpass.com/event/181888/ の開催概要ページよりZoom参加に登録頂くか、YouTube Liveにてご視聴下さい。
Open Source Conference 2020 Online/Niigata will be held on Saturday, July 25th.
This event will be held online and I will have a 15 minute talk about #FuguIta in the name of EBUG (Echigo BSD Users Group).
Please register for Zoom participation from the overview page of https://ospn.connpass.com/event/181888/ , or watch it on YouTube Live.
|06:00-06:15||Introduction of NetBSD||Japan NetBSD Users Group (JNUG)||Jun Ebihara|
|06:15-06:30||Introduction of FuguIta||Echigo BSD Users Group (EBUG)||Yoshihiro Kawamata|
vyos-cli: VyOS CLIs for Ubuntu
|Echigo Network Operators Group (ENOG)||Masakazu Asama|
(also member of EBUG)
-- kaw 2020-07-22 (Wed) 23:46:40
Fugu (2020-07-19 (Sun) 15:51:32)
Is there a difference in boot mode of OpenBSD and #FuguIta? I have a Dell PC where OpenBSD is very slow without disabling acpimadt whereas #FuguIta has no such problems.
Any guidance will be gratefully received.
nimbus9 amd64 # diff -u GENERIC RDROOT --- GENERIC Mon Jul 20 12:43:03 2020 +++ RDROOT Mon Jul 20 12:40:08 2020 @@ -49,7 +49,7 @@ option UDF # UDF (DVD) file system option MSDOSFS # MS-DOS file system option FIFO # FIFOs; RECOMMENDED -#option TMPFS # efficient memory file system +option TMPFS # efficient memory file system option FUSE # FUSE option SOCKET_SPLICE # Socket Splicing for TCP and UDP @@ -88,7 +88,7 @@ pseudo-device nmea 1 # NMEA 0183 line discipline pseudo-device msts 1 # MSTS line discipline pseudo-device endrun 1 # EndRun line discipline -pseudo-device vnd 4 # vnode disk devices +pseudo-device vnd 6 # vnode disk devices pseudo-device ksyms 1 # kernel symbols device #pseudo-device dt # Dynamic Tracer @@ -134,7 +134,12 @@ option NTFS # NTFS support option HIBERNATE # Hibernate support -config bsd swap generic +config bsd root on rd0a swap on wd0b and sd0b +option RAMDISK_HOOKS +option MINIROOTSIZE=3800 +option NKPTP=5 + +pseudo-device rd 1 # ramdisk mainbus0 at root nimbus9 amd64 #So I don't know why it behaves differently.
-- kaw 2020-07-20 (Mon) 12:50:48
scanning partitions: cd0a sd0i sd0j FuguIta's operating device(s): cd0a sd0i Which is FuguIta's operating device? [default: cd0a] -> sd0i # in case that sd0 is internal disk
If FuguIta runs slow as OpenBSD with this procedure, the problem could lay on internal disk device. -- kaw 2020-07-21 (Tue) 16:28:11
and one other escaping attention now.
To this end, I started reading through the show and list variables in the UKC config and found that #FuguIta has a lot more that get initialized than vanilla OpenBSD. When that did not work out, I once again disabled acpimadt, installed the operating system and waited for it to boot. The scenario now stood at reordering libraries (library_aslr). I let it complete the first time and then disabled the service via rcctl. This made a dramatic impact on reboot.
Presently, after having run sysupgrade (following -current), the performance is acceptable as good as on a ThinkPad.
My speculation is to do with the execute bit. I haven't read the source code to be certain of this but would appreciate your knowledgeable thoughts on it. I will try the above solution if video and browser performance in unacceptable with my continued testing. -- Fugu 2020-07-21 (Tue) 19:37:36
Former articles are at FuguIta/BBS/9.
Return to Top