[DragonFlyBSD - Bug #2674] GPT Support
Issue #2674 has been updated by ftigeot. Related to Bug #2264: DragonFly can't be installed on bigger than 2TB volumes added Bug #2674: GPT Support http://bugs.dragonflybsd.org/issues/2674#change-11974 * Author: ftigeot * Status: New * Priority: Normal * Assignee: * Category: * Target version: DragonFly currently doesn't have any GPT support in its installer, which makes it hard to install on 2TB storage volumes. Proposed roadmap: 1. Register some GUID partition types UFS and swap partitions could reuse the FreeBSD UFS and partition types New types are needed for HAMMER and HAMMER2 file systems 2. Add full-volume support to the installer The installer should be able to install DragonFly on a dedicated volume 3. Add partial volume support to the installer For people wanting to keep non-DragonFly managed data on part of a volume -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2264] DragonFly can't be installed on bigger than 2TB volumes
Issue #2264 has been updated by ftigeot. Related to Bug #2674: GPT Support added Bug #2264: DragonFly can't be installed on bigger than 2TB volumes http://bugs.dragonflybsd.org/issues/2264#change-11975 * Author: ftigeot * Status: Closed * Priority: Normal * Assignee: swildner * Category: * Target version: The DragonFly installer tries to run fdisk unconditionally on target devices and thus fails with 2TB volumes. This is what I've done to get DragonFly installed on a 8TB RAID volume: 1. Don't try to use the installer, log in as root on the live cd 2. gpt create /dev/da0 3. gpt boot /dev/da0 This stage adds a 256MB gpt boot slice with a disklabel32 filesystem type FIXME: Size should be updated to 768MB, like the /boot partitions created by the installer 4. gpt add -t swap -s 16777216 /dev/da0 This creates a 8GB swap slice 5. gpt add -t dfly /dev/da0 This creates a slice covering the rest of the da0 volume with a DragonFly filesystem type. FIXME: I'm not sure what is meant by DragonFly filesystem. maybe Hammer should be presented as a choice instead. 6. disklabel the /dev/da0s0 boot slice, install bootstrap code disklabel32 -B -r -w /dev/da0s0 auto disklabel32 -r -e /dev/da0s0 create a 'a' partition covering the entire slice 7. format /boot filesystem newfs /dev/da0s0a 8. format / filesystem newfs_hammer -L BIGVOLUME /dev/da0s2 9. mount and install /boot mount /dev/da0s0a /mnt cpdup -I -v /boot /mnt vi /mnt/loader.conf vfs.root.mountfrom=hammer:da0s2 umount /mnt 10. install the future / mount -t hammer /dev/da0s2 /mnt cpdup -I -v / /mnt cd /mnt rmdir etc mv etc.hdd etc vi etc/fstab 11. reboot The first stage bootloader will show an unknown F1 choice. Just use F2 (DragonFly) and it will boot The new system is able to run single-user, some /var directories which were not present on the livecd need to be created by hand to go multi-user The system is otherwise fully functional -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2674] GPT Support
Issue #2674 has been updated by herrgard. DragonFly has some partition types already. From /etc/defaults/uuids: # # DragonFly # 9d087404-1ca5-11dc-8817-01301bb8a9f5DragonFly Label32 9d58fdbd-1ca5-11dc-8817-01301bb8a9f5DragonFly Swap 9d94ce7c-1ca5-11dc-8817-01301bb8a9f5DragonFly UFS1 9dd4478f-1ca5-11dc-8817-01301bb8a9f5DragonFly Vinum dbd5211b-1ca5-11dc-8817-01301bb8a9f5DragonFly CCD 3d48ce54-1d16-11dc-8696-01301bb8a9f5DragonFly Label64 bd215ab2-1d16-11dc-8696-01301bb8a9f5DragonFly Legacy 61dc63ac-6e38-11dc-8513-01301bb8a9f5DragonFly HAMMER 5cbb9ad1-862d-11dc-a94d-01301bb8a9f5DragonFly HAMMER2 Bug #2674: GPT Support http://bugs.dragonflybsd.org/issues/2674#change-11976 * Author: ftigeot * Status: New * Priority: Normal * Assignee: * Category: * Target version: DragonFly currently doesn't have any GPT support in its installer, which makes it hard to install on 2TB storage volumes. Proposed roadmap: 1. Register some GUID partition types UFS and swap partitions could reuse the FreeBSD UFS and partition types New types are needed for HAMMER and HAMMER2 file systems 2. Add full-volume support to the installer The installer should be able to install DragonFly on a dedicated volume 3. Add partial volume support to the installer For people wanting to keep non-DragonFly managed data on part of a volume -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2670] `top -S` and `top -c` work, but not `top -Sc`
Issue #2670 has been updated by marino. yuck. I get a different bug with top -Sc. It just files the entire table with the same line: for top (run as root) confirmed -- something is screwy Bug #2670: `top -S` and `top -c` work, but not `top -Sc` http://bugs.dragonflybsd.org/issues/2670#change-11978 * Author: tautolog * Status: New * Priority: Normal * Assignee: * Category: Userland * Target version: 3.7.1 `top -Sc` will behave like `top -c`, but have a variable number of duplicate lines for each process. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2670] (Closed) `top -S` and `top -c` work, but not `top -Sc`
Issue #2670 has been updated by marino. Status changed from New to Closed fixed here: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/826597b58e4d70a51d4d17e21e7a797cda77666a tested by ivadasz Thanks! Bug #2670: `top -S` and `top -c` work, but not `top -Sc` http://bugs.dragonflybsd.org/issues/2670#change-11979 * Author: tautolog * Status: Closed * Priority: Normal * Assignee: * Category: Userland * Target version: 3.7.1 `top -Sc` will behave like `top -c`, but have a variable number of duplicate lines for each process. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2675] (New) Ultimate N WiFi Link 5300 can't load = iwn0: iwn_intr: fatal firmware error (error type = SYSASSERT)
Issue #2675 has been reported by revuwa.
Bug #2675: Ultimate N WiFi Link 5300 can't load = iwn0: iwn_intr: fatal
firmware error (error type = SYSASSERT)
http://bugs.dragonflybsd.org/issues/2675
* Author: revuwa
* Status: New
* Priority: Normal
* Assignee:
* Category: Driver
* Target version: 3.8.0
I'm using a Lenovo Thinkad X200s with Intel Ultimate N WiFi Link 5300.
On Dragonfly BSD 3.6.2 it worked perfectly without any errors (and exactly the
same configuration). Since 3.7.X and the actual testes 3.8.0RC my WiFi decive
throws the following error on every try to load it (also over manual
/etc/rc.d/netif restart):
### dmesg.boot (with rc_debug enabled) ###
iwn0: iwn_intr: fatal firmware error
firmware error log:
error type = SYSASSERT (0x0005)
program counter = 0x3130
source line = 0x0585
error data = 0x0001
branch link = 0x312A312A
interrupt link = 0x0916
time= 1270108785
driver status:
tx ring 0: qid=0 cur=0 queued=0
tx ring 1: qid=1 cur=0 queued=0
tx ring 2: qid=2 cur=0 queued=0
tx ring 3: qid=3 cur=3 queued=0
tx ring 4: qid=4 cur=0 queued=0
tx ring 5: qid=5 cur=0 queued=0
tx ring 6: qid=6 cur=0 queued=0
tx ring 7: qid=7 cur=0 queued=0
tx ring 8: qid=8 cur=0 queued=0
tx ring 9: qid=9 cur=58 queued=0
tx ring 10: qid=10 cur=0 queued=0
tx ring 11: qid=11 cur=0 queued=0
tx ring 12: qid=12 cur=0 queued=0
tx ring 13: qid=13 cur=0 queued=0
tx ring 14: qid=14 cur=0 queued=0
tx ring 15: qid=15 cur=0 queued=0
tx ring 16: qid=16 cur=0 queued=0
tx ring 17: qid=17 cur=0 queued=0
tx ring 18: qid=18 cur=0 queued=0
tx ring 19: qid=19 cur=0 queued=0
rx ring: cur=11
I just load 'iwn5000fw_load=YES' over loader.conf, because the other modules
(if_iwn.ko, wlan_ccmp.ko, wlan_tkip.ko) are loaded by the generic kernel. This
is what I've loaded, too:
### kldstat ###
Id Refs AddressSize Name
1 28 0x8020 15a8710 kernel
21 0x817a9000 13020snd_hda.ko
32 0x817bd000 31bf8sound.ko
43 0x817ef000 bf758acpi.ko
51 0x818af000 c7a0 ehci.ko
62 0x818bc000 f4c0 dm.ko
71 0x818cc000 1c4f8dm_target_crypt.ko
84 0x827e9000 58d0 libiconv.ko
91 0x827ef000 20c8 libmchain.ko
101 0x827f2000 f98 msdos_iconv.ko
111 0x827f3000 f88 ntfs_iconv.ko
122 0x827f4000 10a38ntfs.ko
131 0x82805000 fd0 cd9660_iconv.ko
141 0x82806000 5928 acpi_video.ko
151 0x8280c000 70c48drm.ko
162 0x8287d000 2ec8 iicbus.ko
171 0x8288 53fc8iwn5000fw.ko
181 0x828d4000 1da8 coretemp.ko
191 0x828d6000 68d0 acpi_thinkpad.ko
201 0x828dd000 3dd0 est.ko
211 0x83042000 35000pf.ko
### rc.conf (relevant entries) ###
wlans_iwn0=wlan0
ipv6_enable=YES
ipv6_network_interfaces=wlan0
ifconfig_wlan0=up DHCP WPA mode 11a
### wpa_supplicant.conf ###
ctrl_interface=/var/run/wpa_supplicant
eapol_version=2
network={
ssid=my SSID name
priority=145
#scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
psk=my secure passphrase
}
### sysctl.conf (relevant entries) ###
net.inet6.ip6.use_tempaddr=1
net.inet6.icmp6.nodeinfo=0
net.inet6.icmp6.rediraccept=0
In IRC at #dragonflybsd on EFNet @profmakx wrote: I have iwn4965 and iwn6000,
both work.
I've just tested (just for fun) to replace all that modules (if_iwn.ko,
wlan_ccmp.ko, wlan_tkip.ko, iwn5000fw.ko) one by one and all together with the
older one from v3.6.2. The result was exactly the same error.
I've found a FreeBSD issue with parallels:
http://www.marshut.com/sinuy/iwn-firmware-sysassert.html
Thanks in advance for any help!
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://bugs.dragonflybsd.org/my/account
