I've been running into a bug, but can't yet rule out my own code, even
though I really really don't think I could have caused it.
The behaviour would be obvious, i.e. boot fails real early and drops you
into the emergency initramfs shell, with the subject line error message
either visible obviously, or at the end of dmesg output.
One bizarre behavior I've noticed while trying to pin this down, is that
the sparse overlay file used in the dm-snapshot, created with dd
of=/overlay bs=1024 count=1 seek=$((512*1024)), seems to often be
512*1024*1024 bytes long, instead of 512*1025*1024 bytes long like it
should. I.e. if you remove the '2> /dev/null' from the dd call in
mayflower's init, you may see 0 records written in&out, when you should
see 1 record written in&out.
Now, why count=1 is used instead of count=0 is an entirely separate
question, to which I'm not sure enough of the answer to suggest using
count=0. (reason would I guess seem to be that dd might be reasonably
be entitled to just do _absolutely_ nothing if you say count=0).
Anyway... If you hit this, you'll know it. And probably would have
posted it anyway, but now you'll know immediately that you aren't the
only one hitting this bug.
The nasty part of it is that it is not deterministic. I rerun the exact
same qemu command on the same iso, and sometimes it hits it, sometimes
it just works fine.
Though if anybody is curious enough to remove the dd '2> /dev/null' and
see if they get the 0 records in/out result, and hopefully can explain
why in the world that is happening... I'd be greatful...
-dmc
--
Fedora-livecd-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
