DragonFlyBSD

Is this booted from an ISO?

232MB seems too much. Note that cd9660 fs has some kind of bug that causes
hard links to be counted separately as if it were separate files so du(1)
output for example might give a false impression.

On master here I see:

advancer# du -sh /usr/share/initrd/
14M /usr/share/initrd/

So it should fit. Not sure what the problem is. I'll try installing from a
4.0.3 ISO tonight.

Sascha

swildner wrote:

Is this booted from an ISO?

232MB seems too much. Note that cd9660 fs has some kind of bug that causes
hard links to be counted separately as if it were separate files so du(1)
output for example might give a false impression.

On master here I see:

advancer# du -sh /usr/share/initrd/
14M /usr/share/initrd/

So it should fit. Not sure what the problem is. I'll try installing from a
4.0.3 ISO tonight.

Sascha

#du -sh /usr/share/initrd/
227M /usr/share/initrd

The output above is the same whether booted from hard disk or from the install cd, but is larger because I bypassed the 15 Meg limit inherited from /etc/default/mkinitrd.conf.

Before you start a new install, first see if the current install shows the copy errors in the /var/log/install.log starting with tcplay, it should be evident with:
#grep -A4 initrd /var/log/install.log | head -n 12

I believe your 14M is what fits with the current default size "15m" in /etc/default/mkinitfs.conf while 200-some megabytes of files (such as shutdown,swapctl,tcplay,) fail to copy as evidenced in /var/log/install.log

Witness the initrd contains /etc/rcmount_tcplay while missing /sbin/tcplay with the "15m" limit.

#gzip -c -d /boot/kernel/initrd.img.gz > ~/initrd.img
#vnconfig -c -v /dev/vn0 ~/initrd.img
#mount /dev/vn0 /mnt
#find /mnt | wc
72 72 1235 #for "15m" limited mkinitrd
158 158 2691 #for expanded mkinitrd
#find /mnt | grep tcplay
... witness the /etc, but maybe not the /sbin/tcplay...

............

Thank you for the attention.
Should I file another seperate bug to request static versions of vi(1) and undo(1) be built for the initrd?
-rich

Thank you. It will take me some time to learn the building process, the only 'make rescue' I've run was as part of the install, tho I did run mkinitrd(8). I intend to try and learn the build process on the 4.0.3 release instance of the install, but first I downloaded the daily snapshot to verify your fixes.

#grep -A4 -B1 initrd /var/log/install.log
Filesystem Size Used Avail Capacity Mounted on
/dev/vn4s0 15M 15M 388K 97% /mnt/tmp/initrd #before fix:write failed: no space left on device
/dev/vn4s0 15M 9.9M 5.0M 66% /mnt/tmp/initrd #after fix: no fail, plenty room to spare

#du -sh /usr/share/initrd/
14M /usr/share/initrd :before fix, hitting mkinitrd limit
227M /usr/share/initrd :before fix, with mkinitrd limit expanded
9.9M /usr/share/initrd :after fix, much efficiency from shared inodes

#ls -liR /usr/share/initrd
Fascinating that all of /usr/share/initrd/bin are identical files sharing an inode (except for the dowpa script). Does it link to a busybox type binary? How can i learn more about this setup?
#ls -liR / | grep -B3 91191 #the shared initrd/bin/* inode on my box, but nothing outside of /usr/share/initrd/bin is found.

Even more fascinating, is that while a majority of identical files in /usr/share/initrd/sbin also shares an inode, the minority of identical files that are symlinks to /usr/share/initrd/lvm each have unique inodes. Is this intentional, or an oversight? I am curious about the possible disk space consumption versus inode consumption tradeoffs.

Regarding my earlier requst to inculde both vi(1) and undo(1) in the initrd... I believe they are not included because they are both under the /usr directory, instead of directly under /(s)bin. Also
#find / | grep bin | grep -eshutdown -eundo
/sbin/shutdown :file(1) shows dynamically linked
/usr/bin/undo :... dynamically linked
/usr/share/initrd/sbin/shutdown :...statically linked

Even if I'm mistaken and both binaries are in the installation initrd, I still believe static versions of undo(1) and vi(1) would be very helpful for /usr/share/initrd for when mkinitrd(8) rebuilds an initrd. However, I don't know how to explicitly verify whether these files are on the installation initrd (short of remembering and recreating my error from some weeks ago which caused a degraded system boot, which prompted this request in the first place).
I know that mkinitrd(8) uses /usr/share/initrd by default, but I noticed your commits seem to add a new -c flag somewhere, perhaps to mkinitrd... it seems not documented in the manpage... and the whole initrd creation process seems a bit over my head at this point, buried in makefiles. I'm sorry, I'm more end-user oriented than installer and developer oriented for the time being, although I want to become more fluent in DragonFly and have a deeper understanding of the BSD way ASAP.

Thank you for your consideration.
-rich