ms-sys Activity
Brought to you by:
henca
Activity for ms-sys
-
Henrik Carlqvist posted a comment on ticket #20
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...
-
T. Gessner created ticket #20
ms-sys vs syslinux
-
internet-uzver posted a comment on ticket #19
Yeap, it does nothing. It better to reformatting
-
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.
-
Thanks for the explanation lilo was not helpfull to find the heads, it's too old. I tried sfdisk: $ sfdisk -g /dev/sda1 /dev/sda1: 41283 cylinders, 255 heads, 63 sectors/track I had already backed up the files from the broken /dev/sda1, so I decided to delete it.
-
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...
-
Did you by any chance boot your Linux system with lilo? Noup. Can you tell please, is it good a idea at all to use ms-sys on GPT disk? Or is it designed for MBR only?
-
I found that the command with specifying the start of the partition as 0 mounts the partiotion fylesystem accurate: sudo mount -o ro,offset=0 /dev/sda1 /mnt
-
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...
-
I found that the command with specifying the start of the partition as 0 mounts the partiotion fylesystem accurate: sudo mount -t ntfs-3g -o ro,offset=0 /dev/sda1 /mnt
-
here is the output of that command: Start sector 2048 (nr of hidden sectors) successfully written to /dev/sda1 Physical disk drive id 0x80 (C:) successfully written to /dev/sda1 Number of heads (255) successfully written to /dev/sda1
-
restore gpt partition info
-
Minor fix, making sure that all lines in README are shorter than 80 columns.
-
ms-sys released /ms-sys stable/2.8.0/ms-sys-2.8.0.tar.gz
-
Release 2.8.0
-
Preparing to release version 2.8.0 as stable.
-
-
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,
-
jpz4085 posted a comment on ticket #9
I'm glad my contribution is helpful, that's awesome! Below is my suggested addition to the CONTRIBUTORS file: Joseph Zeller contributed macOS/OS X support and improved FreeBSD and OpenBSD support, added and tested NT6.0 FAT32 and EXFAT boot records, patched Makefile and tested install on Mac/BSD/Linux and updated man pages and po files with new information I understand you don't have access to (and I did not assume) you could test on all supported platforms and so I don't have a problem with that....
-
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...
-
ms-sys patches for macOS, FreeBSD and OpenBSD
-
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...
-
Amigo Ventero modified a comment on ticket #11
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible. It also looks like the core.img code is variable and it probably defines the partition FS and other from which it loads modules, because after adding it to the USB-flash fat32 ignored the configuration on the USB-flash and loaded it from the ext4 HDD. This is probably handled by a script from grub-install. Thank for your time and...
-
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible. It also looks like the core.img code is variable and it probably defines the FS partition from which it loads modules, because after adding it to the USB-flash fat32 ignored the configuration on the USB-flash and loaded it from the ext4 HDD. This is probably handled by a script from grub-install. Thank for your time and best w...
-
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible. It also looks like the core.img code is variable and it probably defines the FS partition from which it loads modules, because after adding it to the USB-flash fat32 ignored the configuration to the USB-flash and loaded it from the ext4 HDD. This is probably handled by a script from grub-install. Thank for your time and best w...
-
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible. Thank for your time and best wishes.
-
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...
-
Unless it takes it from that folder during installation - that would also explain core.img file in folder
-
I understand your arguments. Depending on what we've gathered together for the information, it's half and half, whether it's a missing next code or an error in the base code - why else would the core.img file be in the grub folder? So I'll try to ask PB how it is - he will probably be acquainted in more detail.
-
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...
-
As far as I know, other boot loaders do so - for example, the Winloader or G4D does not distinguish whether FS is ntfs or fat and loads the appropriate module for further management. It is true, that in rufus grub2 installing is fixed choice for fat32 - then if you really needed something more beyond MBR for recognize FS, so this could be solved by an additional parameter to ms-sys. But then is need to find out how it really is , whether it is loaded from the location immediately after the MBR or...
-
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...
-
It looks like it's going to load directly from the filesystem - grubfolder i386-pc include file core.img . In the end, I still think that the USB flash is evaluated the same as the HDD and that it may be an error. It is also possible that the code 0x80 may no longer be valid - I have experience that this parameter does not work with syslinux/isolinux chainloading to HDD, although it is set by default in the configurations of various Linux installers. Via Rufus is choice grub2-bootloader install fully...
-
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...
-
On wiki GNU is written, if i think this good, that core is possible put at defined filesystem - then is necessary modified main mbr code. But with modern formating, with starting at 1MiB for alignment, this is redundant. Yes - you have right - this is probably for support request. Minimalist systems are often without grub tools and ms-sys is smaller, more univerzal and more simple for remmember with good manpage.
-
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...
-
Thank you for vector and your time. By info from GNU GRUB you almost hit. The image files that make up grub2 have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more - now is image system - and grub2 mbr code search for "core.img", which is written in next at least 31KiB. From GNU wiki: This is the core image of GRUB. 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...
-
Thank you for vector. By info from GNU GRUB you almost hit. The image files that make up grub2 have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more - now is image system - and grub2 mbr code search for "core.img", which is written in next at least 31KiB. From GNU wiki: This is the core image of GRUB. 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...
-
Thank you for vector. By info from GNU GRUB you almost hit. The image files that make up grub2 have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more - now is image system - and grub2 mbr code search for "core.img", which is written in next at least 31KiB. From GNU wiki: This is the core image of GRUB. 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...
-
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...
-
In Win via Rufus is this procedure fully functional.
-
In Win via Rufus this is fully functional.
-
grub2 boot record unfunctional
-
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...
-
i30817 modified a comment on ticket #10
Actualy it's not the max long but the uninitialized value of sGeometry.start. Probably because it's a loop device not a real drive, so the ioctls are returning weird values. I tried to print it and ' iRes1 = ioctl(iFd, BLKGETSIZE, &lSectors);' makes iRes1 0 and ' iRes2 = ioctl(iFd, HDIO_GETGEO, &sGeometry);' makes iRes2 -1 then if(! (iRes1 && iRes2) ) return sGeometry.start; the inner is false because of iRes2, so it returns the uninit value. This seems wrong. Could we get a command line switch to...
-
Actualy it's not the max long but the uninitialized value of sGeometry.start. Probably because it's a loop device not a real drive, so the ioctls are returning weird values. I tried to print it and ' iRes1 = ioctl(iFd, BLKGETSIZE, &lSectors);' makes iRes1 0 and ' iRes2 = ioctl(iFd, HDIO_GETGEO, &sGeometry);' makes iRes2 -1 then if(! (iRes1 && iRes2) ) return sGeometry.start; the inner is false because of iRes2, so it returns the uninit value. This seems wrong. Could we get a command line switch to...
-
Actualy it's not the max long but the uninitialized value of sGeometry.start. Could we get a command line switch to provide this 'sGeometryStart'? Could it double as the 'offset' to operate on files without sudo if the given file is a real file?
-
Actualy it's not the max long but the uninitialized value of sGeometry.start. Could we get a command line switch to provide this 'sGeometryStart'? Could it double as the 'offset' to operate on files without sudo?
-
Using -p with a loopback device under dos causes the number of hidden sectors to be the max long
-
Bernhard M. Wiedemann posted a comment on ticket #7
Indeed, bzip2 and xz never did that. And gzip-1.9 even stopped embedding timestamps for pipes, because that made tar cz output unreproducible.
-
No problem, thanks again for reporting the issue!
-
Arnout Engelen posted a comment on ticket #8
Oops, sorry about the noise!
-
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.
-
Avoid the build timestamp from leaking into the manpage
-
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
-
John Boehr created ticket #7
Use gzip --no-name in manual compression for reproducible builds
-
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.
-
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..
-
ivanmara created ticket #18
Please stabilize 2.5.3 version!
-
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.
-
joergt created ticket #17
mkdosfs boot sector and -m option for message file
-
As far as I know Windows 10 supports only UEFI boot. UEFI booting is a completely different beast without any boot records writen to MBR or beginning of partitions. Instead booting is done with files in a special partition.
-
George Gannon created ticket #18
Support for Windows 10 / Server 2016
-
Please feel free to use ms-sys-free (from https://sourceforge.net/projects/ms-sys-free/ ) which does not contain any non-free part. Please also feel free to add functionality like an optional non-free addon to ms-sys-free. If you so wish, please also feel free to reuse any code from ms-sys when writing that addon as long as your addon complies with the GPL license. Or, if you are lazy like me, just let everyone choose between ms-sys-free or the complete ms-sys which can replace ms-sys-free. You can...
-
林博仁(Henry Lin) posted a comment on ticket #17
It would be great to separate the materials and made the non-free part as an optional addon(in a separated source tree so that the main source code is fully legally redistributable), this helps downstream packagers to package the free parts without dealing the copyright issue. Users who has been licensed to use the non-free code (id. est. Windows licensee) can choose to download the non-free parts and made it available to ms-sys using a separate installer. The non-free boot record can't be packaged...
-
Initial import to CVS on SourceForge, this is version 0.9 pre-release
-
Fixed compile problems with newer versions of msgfmt
-
Added file CONTRIBUTORS
-
--none-- committed [r3]
This commit was manufactured by cvs2svn to create tag 'start'.
-
Version 1.0 going for public release
-
--none-- committed [r1]
Standard project directories initialized by cvs2svn.
-
Starting new minor version which fixes sv_SE.po compile on RedHat 7.3
-
Removed some files which was not supposed to be in the CVS repository
-
Updated documentation about -p switch
-
This is still only an alfa
-
Now compiles even if libintl.h is missing
-
Replaced --keeplabel with inverted --wipelabel and implemented this also for
-
Completed installation instructions
-
Date of commit in CHANGELOG
-
Minor bug-fixes for identifying boot sectors
1 >
