Re: CVS commit: src/distrib/amd64/liveimage/emuimage
maya@ wrote: > Module Name: src > Committed By: maya > Date: Tue Apr 16 16:13:45 UTC 2024 > > Modified Files: > src/distrib/amd64/liveimage/emuimage: Makefile rc.conf.emuimage > spec.emuimage > > Log Message: > restore amd64 live image support for resize root after combined mbr/gpt commit > > we need to resize_gpt now, as it takes precedence over mbr/disklabel > this change brings us to behave like the evbarm images. > > XXX: we don't seem to touch disklabel and MBR, but they exist. Not sure > whether > that has any negative repercussions, maybe another system might regard MBR as > the > sole source of truth when GPT also exists. Actually disklabel or MBR does NOT exist in USE_GPT=YES case. In src/distrib/common/bootimage/Makefile.bootimage, both ${TOOL_FDISK} and ${TOOL_DISKLABEL} are only invoked inside .if ${USE_GPT} == "no". "${TOOL_GPT} biosboot -c /usr/mdec/gptmbr.bin" by USE_GPTMBR=yes does all the tricks, i.e. gptmbr.bin in the MBR sector just reads the first sector of the specified GPT partition: https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/mbr/gptmbr.S and the loaded pbr.S in the primary bootxx checks a GPT partition table and loads the whole (~8KB) the primary bootxx: https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/bootxx/pbr.S#L134-L135 https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/bootxx/pbr.S#L372-L380 Maybe this is the reason why some odd machines cannot boot UEFI images (such ugly implemantations might assume MBR partition really exists). --- Izumi Tsutsui
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
Martin Husemann writes: > On Thu, Aug 08, 2019 at 08:09:19PM -0400, Greg Troxel wrote: >> In addition, I don't like it that images have stuff in /boot in the DOS >> partition that can't be found in some obvious place, like /usr/mdec. >> But I haven't gotten around to trying to fix it either so I get it that >> ENOPATCH. > > Yes, but in this case the bug is that sysinst does not know how to properly > fill the /boot things - which is on my TODO list. > > (and also, as you mention, that there is no obvious easy source for the > content) I was talking about the first bug, that these things aren't in the destdir of a build. The following belong on /usr/mdec/RPI, or similar, either for all arm build (or when MKRPI=yes if we want to split that out). -rwxr-xr-x 1 root wheel 1494 Oct 26 2017 LICENCE.broadcom -rwxr-xr-x 1 root wheel17932 Oct 26 2017 bootcode.bin -rwxr-xr-x 1 root wheel 105 Nov 9 2018 cmdline.txt -rwxr-xr-x 1 root wheel 6624 Oct 26 2017 fixup.dat -rwxr-xr-x 1 root wheel 2533 Oct 26 2017 fixup_cd.dat -rwxr-xr-x 1 root wheel 2823716 Oct 26 2017 start.elf -rwxr-xr-x 1 root wheel 634948 Oct 26 2017 start_cd.elf Arguably installboot should be taught to deal with this; it's a FAT partition instead of blocks 0-15, but it strikes me as the same thing logically.
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
Martin Husemann wrote: > However - the whole idea boils down to: > > - what purpose do others use the USB install images for? What others use the USB *install* image for is hardly relevant to the present discussion. The install image and the live image (aka "emuimage") are two separate things, and the commit being discussed affects only the latter: NetBSD-9.99.4-amd64-install.img1.4G NetBSD-9.99.4-amd64-live.img 3.6G I'm guessing almost no one uses the amd64 live image presently, simply because it is not included in the official binary releases - you have to build it yourself. But I think there is a clear trend away from the 1980's concept of "installing" an operating system towards simply running images - that's what ARM SBC users do, that's what you do on Amazon EC2, etc. Many other open source OSes distribute fully functional live images for amd64, and I think NetBSD should, too. -- Andreas Gustafsson, g...@netbsd.org
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
On Fri, Aug 09, 2019 at 05:44:12AM +, m...@netbsd.org wrote: > I guess not a lot of people use the amd64 .img files as an alternate > sysinst for remote setups. where you reboot to rescue, dd it to disk, > then reboot to a complete netbsd install. Sorry, I am not sure I get your point here. I have only ever used a virtual ISO for that (as that is trivial to add in most virtual machine setups, whereas the USB images often need some conversion and I always forget the details). On machines with enough RAM the ramdisk module (or on other architctures the monlithic ramdisk INSTALL kernel) is even better for simple recovery. However - the whole idea boils down to: - what purpose do others use the USB install images for? My proposition relied on the (obviously wrong) impression that it would be mostly for: 1) testing a new NetBSD version on some random (foreign) hardware (e.g. a Notebook at a shop before buying it) 2) quickly trying NetBSD (while usually running something else) 3) installing NetBSD None of this would require the ability to statically link code or realy debug binaries in this (limited) setup. If others use the images more broadly, the whole idea is moot, especially as USB stick sizes are not exactly limited anywhere close to the size we need right now. Martin
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
On Thu, Aug 08, 2019 at 08:09:19PM -0400, Greg Troxel wrote: > In addition, I don't like it that images have stuff in /boot in the DOS > partition that can't be found in some obvious place, like /usr/mdec. > But I haven't gotten around to trying to fix it either so I get it that > ENOPATCH. Yes, but in this case the bug is that sysinst does not know how to properly fill the /boot things - which is on my TODO list. (and also, as you mention, that there is no obvious easy source for the content) Martin
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
On Thu, Aug 08, 2019 at 08:22:21PM +0200, Martin Husemann wrote: > On Thu, Aug 08, 2019 at 09:13:37PM +0300, Andreas Gustafsson wrote: > > The image already has an empty /usr/libdata/debug. The increase in > > size when MKDEBUG is enabled is spread out over various other > > directories, notably /usr/lib. For example, > > > > /usr/lib 405182 kB -> 866276 kB > > /usr/bin 53426 kB -> 63140 kB > > > > The largest file in /usr/lib is libstdc++_pic.a, which grows from > > 4.3 MB to 27 MB. > > Heh - nice, didn't think about that. > > How about: remove all *.a files from those images? > Is there a tool to strip CTF from binaries? > > Martin I guess not a lot of people use the amd64 .img files as an alternate sysinst for remote setups. where you reboot to rescue, dd it to disk, then reboot to a complete netbsd install.
re: CVS commit: src/distrib/amd64/liveimage/emuimage
> Other libraries also have _pic.a files that are much larger than the > others versions. Is there a bug that causes them not to be CTF-converted, > or is this deliberate? the _pic.a libraries are special case we could choose to stop shipping. they're useful if someone wants to build a special case application for some reason (tm), but almost never used by the vast majority of people. they're created as part of create the .so, and the .so has its debug info moved out, but apparently we've never created any makefile or sets infrastructure to do this for _pic.a. perhaps we should choose not to install them by default. you can turn it off already with MKPICINSTALL=no. .mrg.
re: CVS commit: src/distrib/amd64/liveimage/emuimage
Martin Husemann writes: > On Thu, Aug 08, 2019 at 09:13:37PM +0300, Andreas Gustafsson wrote: > > The image already has an empty /usr/libdata/debug. The increase in > > size when MKDEBUG is enabled is spread out over various other > > directories, notably /usr/lib. For example, > > > > /usr/lib 405182 kB -> 866276 kB > > /usr/bin 53426 kB -> 63140 kB > > > > The largest file in /usr/lib is libstdc++_pic.a, which grows from > > 4.3 MB to 27 MB. > > Heh - nice, didn't think about that. > > How about: remove all *.a files from those images? start with *_pic.a? :) those are really rarely used, even on normal installs. .mrg.
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
Andreas Gustafsson writes: > I really don't like the general idea of introducing differences > between images and systems installed through sysinst. It's confusing > for users, and also means that testing of one is less likely to apply > to the other. Agreed strongly. In addition, I don't like it that images have stuff in /boot in the DOS partition that can't be found in some obvious place, like /usr/mdec. But I haven't gotten around to trying to fix it either so I get it that ENOPATCH.
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
Martin Husemann wrote: > How about: remove all *.a files from those images? > Is there a tool to strip CTF from binaries? I really don't like the general idea of introducing differences between images and systems installed through sysinst. It's confusing for users, and also means that testing of one is less likely to apply to the other. I see that libstdc++_pic.a is much larger than the other versions of the same library: # cd /usr/lib # ls -al libstdc* -r--r--r-- 1 root wheel 4539634 Aug 8 14:00 libstdc++.a lrwxr-xr-x 1 root wheel16 Aug 8 14:00 libstdc++.so -> libstdc++.so.9.0 lrwxr-xr-x 1 root wheel16 Aug 8 14:00 libstdc++.so.9 -> libstdc++.so.9.0 -r--r--r-- 1 root wheel 2030136 Aug 8 14:00 libstdc++.so.9.0 -r--r--r-- 1 root wheel 4787754 Aug 8 14:00 libstdc++_p.a -r--r--r-- 1 root wheel 28835160 Aug 8 14:00 libstdc++_pic.a and that it contains .debug_info sections, which the others don't: # size -A -d libstdc++_pic.a | fgrep .debug_info | wc -l 173 # size -A -d libstdc++.a | fgrep .debug_info | wc -l 0 Other libraries also have _pic.a files that are much larger than the others versions. Is there a bug that causes them not to be CTF-converted, or is this deliberate? -- Andreas Gustafsson, g...@netbsd.org
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
On Thu, Aug 08, 2019 at 09:13:37PM +0300, Andreas Gustafsson wrote: > The image already has an empty /usr/libdata/debug. The increase in > size when MKDEBUG is enabled is spread out over various other > directories, notably /usr/lib. For example, > > /usr/lib 405182 kB -> 866276 kB > /usr/bin 53426 kB -> 63140 kB > > The largest file in /usr/lib is libstdc++_pic.a, which grows from > 4.3 MB to 27 MB. Heh - nice, didn't think about that. How about: remove all *.a files from those images? Is there a tool to strip CTF from binaries? Martin
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
Martin Husemann wrote: > I would like to see this images created w/o /usr/libdata/debug/ (as we > do for ISO images, some of which we even strip more), but I have not > yet found an easy way to hack that into the image creation process. The image already has an empty /usr/libdata/debug. The increase in size when MKDEBUG is enabled is spread out over various other directories, notably /usr/lib. For example, /usr/lib 405182 kB -> 866276 kB /usr/bin 53426 kB -> 63140 kB The largest file in /usr/lib is libstdc++_pic.a, which grows from 4.3 MB to 27 MB. The largest file in /usr/bin is gdb, which grows from 7.8M to 12M. "size -A -d" shows most of the growth is CTF. Is there a corresponding tool to look at the sizes of sections in a ".a" library? In any case, the kernel has only grown from 23M to 26M, so this growth looks like it's mostly a userland issue and unrelated to the removal of "-U DEBUG" from etc/Makefile. -- Andreas Gustafsson, g...@netbsd.org
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
On Wed, Aug 07, 2019 at 07:59:36AM +, Andreas Gustafsson wrote: > Module Name: src > Committed By: gson > Date: Wed Aug 7 07:59:36 UTC 2019 > > Modified Files: > src/distrib/amd64/liveimage/emuimage: Makefile > > Log Message: > The amd64 live image no longer fits in 2 GB when built with with > MKDEBUG, as releases are. Bump the size to just under 4 GB (as in > 4*10^9, not 4*2^30), the next larger common USB thumb drive size. I would like to see this images created w/o /usr/libdata/debug/ (as we do for ISO images, some of which we even strip more), but I have not yet found an easy way to hack that into the image creation process. Any pointers welcome ;-) Or does someone see a good use for the debug info on them (by default)? During testing I often gathererd cores on these images but could easily analyze them on another machine. Martin