Activity for Henrik Carlqvist
-
Henrik Carlqvist posted a comment on ticket #20
The main purpose of DOS FDISK is to create partitions, ms-sys cannot do that. There are other free tools for that like Linux fdisk, cfdisk parted or gparted. However, ms-sys is capable of doing the equivalent of DOS "FDISK /mbr", that is writing master boot records. The master boot record consists of the first 512 bytes of a device and only part of those 512 bytes are the code to boot, in the MBR you also have the DOS partition table. Ms-sys does not alter or create the partition table. The fact...
-
No, I do not have any contact with the people who has contributed code. Most contributors have only added some single feature that they needed for themselves. It is not like we would be some group that continues to work together.
-
Sorry, ms-sys is not enough to create a bootable USB stick. To become bootable, you will need to install some kind of operating system on that USB stick. Whatever operating system that you choose will most likely provide you with all tools needed to make it bootable. Ms-sys is only a tool to identify and fix boot records. Once booted, boot records will need something to chain to. The master boot record might need to pass on to a partition boot record (so far ms-sys will be able to provide both for...
-
What options you need to use completely depends upon what you are going to boot and what you are going to use to boot it. First of all, ms-sys in itself is not capable of creating a "bootable disk", you will need some kind of operating system to boot. Next, ms-sys is only capable of writing the kind of boot records usable by legacy BIOS computers, if your system has UEFI boot only, ms-sys will not be to any use for you. The initial and still main intention of ms-sys is to be a Linux tool to make...
-
What options you need to use completely depends upon what you are going to boot and what you are going to use to boot it. First of all, ms-sys in itself is not capable of creating a "bootable disk", you will need some kind of operating system to boot. Next, ms-sys is only capable of writing the kind of boot records usable by legacy BIOS computers, if your system has UEFI boot only, ms-sys will not be to any use for you. The initial and still main intention of ms-sys is to be a Linux tool to make...
-
Sorry, I have no experience from FreeBSD myself. Others have contributed all the code for OpenBSD and FreeBSD.
-
Thanks for not giving up and finally being able to verify that it works as expected! Even though it has not yet been tested with an older version of nvidia-smi the changes to the code are so trivial that I expect to release version 1.3 later today. Thanks again!
-
Interesting! And the snmp daemon has been restarted since nvgpu-snmp.so was installed as you rebooted. However, you wrote something about uininstalling and reinstalling net-snmp, could it be that the running snmpd is using modules from some other directory than /usr/x86_64-linux-gnu/snmp/dlmod ? In what way did the compilation of nvgpu-snmp interfer with your snmp installation? During compilation, netsnmp-config is used to figure out where to install nvgpu-snmp.so, maybe that directory changes if...
-
I now realize that during "make install", the "install" command is called with the switch "-s" when installing nvgpu-snmp.so which strips the binary from some symbols, making it smaller. However, there is still one way to check that the new version is installed: strings /usr/x86_64-linux-gnu/snmp/dlmod/nvgpu-snmp.so | grep power The above command should show the new fields average_power_draw and instant_power_draw, if not, the installed nvgpu-snmp.so is some older version. If those fields does not...
-
Thanks! With that line in snmpd.conf you should not have nggpu_agentxd running as a separate process. Instead, please check that your /usr/x86_64-linux-gnu/snmp/dlmod/nvgpu-snmp.so has a size that matches your newly compiled nvgpu-snmp.so Also, just to make sure, check that the timestamp of /usr/x86_64-linux-gnu/snmp/dlmod/nvgpu-snmp.so is the same or newer than your newly compiled file.
-
In lack of any nvidia-smi I made a quick hack to my code to read the XML data provided by you instead of calling nvidia-smi. I then got the following output: tuxedo:~> snmpwalk -c public -v2c localhost 1.3.6.1.4.1.2021.13.42.2 UCD-SNMP-MIB::ucdExperimental.42.2.1.1.0 = INTEGER: 0 UCD-SNMP-MIB::ucdExperimental.42.2.1.1.1 = INTEGER: 1 UCD-SNMP-MIB::ucdExperimental.42.2.1.2.0 = STRING: "NVIDIA GeForce RTX 2060" UCD-SNMP-MIB::ucdExperimental.42.2.1.2.1 = STRING: "NVIDIA GeForce RTX 4060 Ti" UCD-SNMP-MIB::ucdExperimental.42.2.1.3.0...
-
Thanks for your attempt! I was hoping that my changes would help and use average_power_draw and instant_power_draw for your version of nvidia-smi. Just to double-check that the right version is running: ps -ef | grep nvgpu_agentxd | grep -v grep (just to make sure that only one such process is running), and then: ls -alH /proc/`ps -ef | grep nvgpu_agentxd | grep -v grep | awk '{print $2}'`/exe And make sure that the size and timestamp matches with your newly compiled binary. If size and timestamp...
-
Fine! I have pushed my changes now, but not been able to test anymore than to see that the code still compiles. I have also fixed another bug report about code no longer compiling with newer versions of net-snmp.. Please let me know if this version works better for you.
-
Thanks a lot for the xml data! Unfortunately I am not sure where to find any matching xml data in the file. Was your card used rather heavily when you did produce the file? If so, maybe the field "instant_power_draw" is the one supposed to be used now instead. That field says 144.88 W for one of your cards and 156.89 W for the other card. However those values are far higher than the 12 W in your first example output from nvidia-smi and 10 W in the example snmpwalk output. It seems as if average_power_draw...
-
Could you please compare the xml output from nvidia-smi? nvidia-smi -q -x My guess is that they have renamed "power_draw" to something else in the new version.
-
They will probably both be able to boot a system, but they contain slightly different data as they come from different sources. Those different data will probably only be notable by an end user as slightly different error messages if something goes wrong. The switch -7 writes an MBR which looks as the one from Microsoft Windows 7. It is also possible to write an MBR looking as it came from syslinux with the switch -s, however even that one might differ slightly depending on version of syslinux. The...
-
My guess is that the Linux kernel reports the same number of heads (255) to sfdisk as it did to ms-sys. Trying to write 255 again is probably not going to help. Reformatting the file system from scratch and restoring a backup might be the simplest solution. Unless you have more questions within the next week I will close this support request.
-
It is fully possible to do a legacy boot also with a GPT partition table. However, most new machines have UEFI boot and ms-sys is not useful for UEFI boot systems. For UEFI boot a GPT partition table is required, but a GPT partition table does not require UEFI boot. I am not aware of any other way than lilo to find out the number of heads to give to ms-sys. However, there is another tool called testdisk: https://www.cgsecurity.org/wiki/TestDisk . I have used it a few times to restore erased partitions...
-
The --partition switch does not in any way alter the partition table, only the file system of the given partition (in this case sda1). This can be done on FAT or NTFS file systems. Usually ms-sys is able to get everything right automagically except for the number of heads. So ms-sys has the switch -H where you manually can set the expected number of heads of the disk. Did you by any chance boot your Linux system with lilo? If so, you can use "lilo -T geom" to see the number of heads of your drive...
-
Removed some warnings from admin/pois.php
-
Working better with mysql/mariadb databases configured for UTF-8.
-
Releasing version 1.1.1
-
Converting KML encoding to UTF-8 to work with
-
Creating tag for phpoi version 1.1.0
-
Releasing version 1.1.0
-
It is no longer possible to give a kml URL to google for a updated map.
-
Making pngblob work with php8 and some more mysql logging.
-
Removed obsolete and now broken support for hitta.se and multimap.
-
Changed license from GPL to AGPL
-
Creating a tag for version 1.0.1
-
Releasing version 1.0.1
-
Preparing release 1.0.1
-
Minor fix, making sure that all lines in README are shorter than 80 columns.
-
Updated ms-sys to version 2.8.0
-
Release 2.8.0
-
Preparing to release version 2.8.0 as stable.
-
Upgraded cdlabelgen to version 4.3.0
-
Updated some rules to work with Slackware 15.0
-
This updated patch also supports Linux kernel 5.x
-
Upgraded splitjob to version 3.2
-
Preparing to release version 3.2
-
Version 3.2 is soon to be released...
-
Updated splitjob to version 3.1
-
Setting tag for version 3.1
-
Preparing to release version 3.1 with improved handling of magic bytes
-
Upgraded cvsgraph to version 1.7.2
-
Updated ms-sys to version 2.7.0
-
Fixed typo in date of today.
-
Preparing to release stable version 1.0.0
-
Preparing to release version 1.0.0
-
Fixed bug in detecting broken mac address from snmp.
-
Make FreeDOS bootable
-
Bug report closed due to inactivity.
-
Tag to mark version 2.7.0
-
Preparing to release version 2.7.0
-
ms-sys patches for macOS, FreeBSD and OpenBSD
-
Now closing this ticket as the patch has been merged into the svn repository. I can't say for sure when I will get the time to make a new official development release.
-
Applied patch from jpz4085 (Joseph Zeller), added macOS/OS X support,
-
Thanks alot for you contribution! One more file which I really think should be updated is the file CONTRIBUTORS, what would you like to write there? I really appreciate contributions to support more targets like FreeBSD and macOS and that you were able to test on so many targets, but I hope that you realize that I will not now or in the future be able to test my future versions on those targets. Future versions of ms-sys will probably be marked as "unstable development" and after some year without...
-
grub2 boot record unfunctional
-
Yes, https://www.gnu.org/software/grub/manual/grub/html_node/Images.html says about core.img: "It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads everything else (including menu handling, the ability to load target operating systems, and so on) from the file system at run-time. The modular design allows the core image to be kept small, since the areas of disk where it must...
-
Some more googling explains how core.img can be in the grub folder, from https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation "there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the "boot track", "MBR gap", or "embedding area", and which is usually at least 31 KiB), or the core image can be installed in a file system and a list of the blocks that make it up can be...
-
The Windows MBR bootloader simply checks which partition is marked as "active" in the partition table and then chains to the bootloader of that partition. A FAT32 boot record is about 1.5 kB in size, 3 times as big as the MBR. Newer Windows versions which relies on UEFI to boot needs a computer with an UEFI BIOS where the functionality to read a FAT file system is built into the BIOS. Yes, it would be possible to add yet another functionality to ms-sys, making it capable of writing a grub second...
-
The Windows MBR bootloader simply checks which partition is marked as "active" in the partition table and then chains to the bootloader of that partition. A FAT32 boot record is about 1.5 kB in size, 3 times as big as the MBR. Newer Windows versions which relies on UEFI to boot needs a computer with an UEFI BIOS where the functionality to read a FAT file system is built into the BIOS. Yes, it would be possible to add yet another functionality to ms-sys, making it capable of writing a grub second...
-
512 bytes is half a kilobyte, I really find it hard to believe that the MBR would be able to fit code to understand and read from a file system. The linux kernel module for FAT is about 92 kB in size, but FAT is a rather simple file system, the ext4 module is about 908 kB in size, that is almost an entire Megabyte! If you want to compare your successful installation with your failed installation and we assume that the GRUB2 MBR expects the next stage to be placed within the 32 kB directly after the...
-
Unfortunately I do not think that it would be possible to modify the GRUB MBR code to open files in a file system to find the next step in a core file there. The code to understand a file system and open files on a file system is too complex to fit into the 512 bytes that the MBR is limited to. To make things even worse those 512 bytes does not only contain the executable binary of the MBR but also the partition table. That is why all boot loaders in the MBR are really simple and rely on some kind...
-
If it really is so simple that the GRUB MBR only searches for the contents of core.img which is supposed to be written to the disk directly after the MBR this bug report should be converted to a support request. If so, it is not enough to only "copy necessary files" to a file system but the content of core.img will need to be written to a specific location on the raw disk. Writing data to that loccation of course also assumes that there is no partition containing a file system at that location. If...
-
Ms-sys only has functionality to write the grub stage 1 part to the MBR. I am not very familiar with GRUB myself, all the GRUB functionality in ms-sys was added by Pete Batard. However, some googling tells me that the stage 1 part of GRUB relies on the stage 2 part of GRUB and it seems as if the GRUB MBR written by ms-sys assumes that stage 2 (or stage 1.5) of grub resides on disc 80 (usually called C: or /dev/sda) and immediately after the MBR. So my guess is that you will not be able to boot from...
-
Using -p with a loopback device under dos causes the number of hidden sectors to be the max long
-
Sorry, the things you are asking for are attributes of real physical disks like their number of heads. To find out those attributes you really need to use ioctl, there is no other way to find out and an image file does not have any such real physical attributes. If you really know what you are doing you can manually set the number of heads using the -H switch, but again, the rest of -p assumes that you are working on a physical disk. My advice to you is to work on your image file from within some...
-
Using -p with a loopback device under dos causes the number of hidden sectors to be the max long
-
Sorry, the things you are asking for are attributes of real physical disks like their number of heads. To find out those attributes you really need to use ioctl, there is no other way to find out and an image file does not have any such real physical attributes. If you really know what you are doing you can manually set the number of heads using the -H switch, but again, the rest of -p assumes that you are working on a physical disk. My advice to you is to work on your image file from within some...
-
Data is sometimes corrupted by version 2.0
-
Fixed in version 2.1
-
Upgraded splitjob to version 3.0
-
Releasing version 3.0
-
Removed predefined support for parallel gzip decompression, preparing to
-
Avoiding bug from LLDP messages without SysDescr
-
Fixed "Unknown OS" instead of misleading "missing 99_default.php" for
-
No problem, thanks again for reporting the issue!
-
Avoid the build timestamp from leaking into the manpage
-
Marked as closed-accepted but would more correctly be called duplicate.
-
Thanks for the patch! This patch adds the same functionality as patch #7 contributed at https://sourceforge.net/p/ms-sys/patches/7/ which has already been accepted into svn. The functionality will be in the next releas of ms-sys, but unfortunately I do not yet know which year next release is to come. First I plan to give a new release of my project splitjob and I was hoping to do so some months ago but unfortunately I have been short on time.
-
Use gzip --no-name in manual compression for reproducible builds
-
Thanks for your patch! I wasn't even aware that gzip by default put a timestamp in compressed data, it seems as if bzip2 and xz does not. Your patch has been applied to the svn repo, however I do not know which year next official release will be.
-
Compressing man-page with gzip --no-name for reproducibility
-
Please stabilize 2.5.3 version!
-
Version 2.6.0 released as stable with no changes compared to 2.5.3
-
Releasing version 2.6.0
-
Preparing to release version 2.6.0 as stable.
-
Updated README as splitjob is being distributed as tar.xz files.
-
Releasing version 2.2
-
Documented parallel decompression in man page.
-
Preparing to release version 2.2
-
Thanks for your encouraging words! I will probably release a stable labeled 2.6 version identical to 2.5.3. But being short on time I first want to make a new release of my splitjob project. I was hoping to do that release in october but haven't had the time since even development is finisched..
-
-
mkdosfs boot sector and -m option for message file
-
ms-sys is not intended to replace tools which create file systems like mkfs.fat. Ms-sys is only intended to make disks and file systems bootable. Before running ms-sys on a file system you will need to use some other tool to create the file system. That tool migt add a text explaining that the file system is not bootable, but once the file system has been made bootable by ms-sys or some other tool that text will be overwritten by program code and other messages.
-
A first attempt to support parallell decompression, needs rather much CPU...
-
As uiPrevWantedJobs is no longer used in signal handler it does no longer need
1 >
