Re: uefi boot install and disk partitions
On 1/5/20, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote:
>> Le 04/01/2020 à 20:47, Sven Joachim a écrit :
>
> [FAT, hard links]
>
>> >a feature that is crucial for dpkg.
>>
>> I vaguely remember this, but not when and why dpkg needs to create
>> additional hard links. Can you refresh my memories ?
>
> My search engine is lucky today (no, Goog, no cookies for you today ;-)
>
>
> https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem
>
> I'd be more worried about whatever packagers do in their post-install
> scripts. After all, hard links are pretty handy when trying to do
> atomic operations on file systems. If there's no policy explicitly
> banning hard links, I'd expect them to be used...
DISCLAIMER: HOPEFULLY I'm understanding the use of "hard links" here
such as has been my understanding of that topic for *many* years.. :)
For the most part, I thought about the only problem with hard links
was that whatever was using them had to exit an entire hierarchy to
then dig back in from the top to find its target. That comes from my
earliest days of creating anchor links in web design where you're
trying to help your webpages load as fast as possible for the end
user.
As I was sitting pondering this, two thoughts keep floating in my head...
1) Maybe this, primarily the "fat" part of it, somehow explains why
rsync flat out refused to copy a limited number of files over to a USB
for me a few ago. Happened a couple times in different situations. I
can't remember how to recreate it to say yay or nay on it having been
about this topic.
2) A couple years ago, my linux-image installations on debootstraps
were creating "hard" /vmlinuz and /initrd.img links. At some point in
my decades' old perennial newbie-ness, I accidentally stumbled on a
usage case where that very detrimentally.... linked out of my chroot
somehow... and was targeting my host's /boot directory, i.e. NOT the
intended /mnt/deboostrap/boot directory which it SHOULD have been
seeking, instead...............
To this day to fix it, one of my early-on debootstrap checklist points
is to consciously verify that /vmlinuz and /initrd.img symlinks are
being used instead of hard links immediately after apt/apt-get is
finished installing linux-image. Apparently a Developer at some point
noticed the same on some level because I haven't had to create new
links there in a LONG time now.
In wondering how I would have caught that major whoa, maybe it was
that the hard link was reflecting the different kernel version. That
sounds like the most likely way a User would catch that kind of
[anomaly].
Maybe.... "fat" is trying to (intelligently, proactively) protect us
from the rare occasion something like my experience might occur??
Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with... a... seriously... more backup modems... NOW. Because
weather-util says another thunderstorm is in the queue this week.....
*
Reply to: