Project

General

Profile

Actions

Submit #2798

closed

mkinitrd insufficient default size, triggerred by installer

Added by opvalues about 9 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/03/2015
Due date:
% Done:

80%

Estimated time:

Description

Using DragonFly 4.0.3-RELEASE #27,
mkinitrd has a default size of 15MB,
but it needs about 232MB to contain /usr/share/initrd wholly.
This should be evident on most systems with

grep -A4 initrd /var/log/install.log | head -n 12

/etc/mkinitrd.conf or /etc/defaults/mkinitrd.conf should probably be increased.
Is there any reason to keep the smaller INITRD_SIZE="15m" setting?

Also, can a static /bin/vi and /sbin/undo please be included in /usr/share/initrd?
It would be a great help with repairing configuration mistakes.
Thank you.

Actions #1

Updated by swildner about 9 years ago

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

Actions #2

Updated by opvalues about 9 years ago

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

Actions #3

Updated by swildner about 9 years ago

  • Status changed from New to In Progress
  • Priority changed from Low to Normal

I investigated a bit and it turned out to be as follows:

Hard links on cd9660 all have different inode numbers, even though the hard link count is correct (this can be checked by ls -li in /usr/share/initrd of a live CD). Due to the inodes, copying them off the CD will create individual files. This is what caused our initrd to overflow when the installer tried to create it (shown in the /tmp/install.log, as you pointed out). This is also the reason why you saw the /usr/share/initrd directory taking the same 227MB in the installed system.

I pushed some fixes for this, which I'll MFC to the 4.0 branch too, and we'll roll 4.0.4 probably very soon.

Regarding the system you installed, if you rebuild/install your world in it and do another 'make rescue' then, the initrd should be back to being complete.

Regarding vi(1) and undo(1): I see them both in a non-broken initrd. I guess they are just missing in yours because the initrd is broken. Or I misunderstood you.

Actions #4

Updated by opvalues about 9 years ago

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

Actions #5

Updated by opvalues about 9 years ago

  • % Done changed from 0 to 80
Actions #6

Updated by swildner almost 8 years ago

  • Assignee set to swildner

grab

Actions #7

Updated by swildner almost 8 years ago

  • Status changed from In Progress to Closed

Ok, I don't know what made me write "Regarding vi(1) and undo(1): I see them both in a non-broken initrd." in comment #3, because they are not. Regarding vi(1), I don't think it's necessary since our emergency editor mined(1) is already on it. But undo(1) is a good suggestion, so I'm adding it.

Most things on the rescue image are generated with crunchgen(1), so see 'man crunchgen' for further information.

Closing this issue now.

Actions

Also available in: Atom PDF