Re: Bug#330445: do_initrd message fails in noninteractive install
On Sat, 1 Oct 2005 00:03:05 +0200, Sven Luther <sven.luther@wanadoo.fr> said:
> On Fri, Sep 30, 2005 at 01:47:47PM -0500, Manoj Srivastava wrote:
>> Hi,
>>
>> This is a long message, but I have tried conscientiously to answer
>> every bit addressed in the rpeceding message. I honestly think that
>> the previous message was very confused, since it seems to address
>> an on-existent problem (that the ekrnel-image either does not know
>> it was created to be an initrd image, or that somehow the location
>> of the initrd image is unknown -- which is not the case).
> Just because you fail to see the problem, it doesn't mean there is
> no problem.
So pray explain what the rpoblem is here. The kernel postinst
knows that we have an initrd image. There is no confusion about the
path where the initrd image lives. What probblem are you inventing
here?
>> Given that the previous mesage went at great lengths devising a
>> solution to a different, non-existent problem, I am at a loss as to
>> how much of the actuall problem has been discussed below (which is,
>> does the current lilo.conf or grub's menu.lst or whatever boot
>> loader is being used -- which could have changed since the time any
>> of the boot laoders on the machine were installed) are aware that
>> the kernel iamge to boot has an initrd. Details below.
> Well, you cannot deny that any kernel built with make-kpkg could be
> made aware if it is a initrd kernel or not.
It has been for years. The fact you think "could be made
aware", ie, future tense, implies you have no idea what the postinst
is doing. There is no need for "could be made aware". It is, for
gawds sake. Stop trying to solve problems that do not exist.
>> On Fri, 30 Sep 2005 17:09:12 +0200, Sven Luther
>> <sven.luther@wanadoo.fr> said:
>>
>> >> So, this is a kernel-package feature, not a bug :P
>>
>> > It is indeed a bug, but hey, if you really think it is a feature,
>> > probably the best solution will be for the official kernels to
>> > drop kernel-package and do their own stuff, so retitling the bug
>> > accordyingly.
>>
>> Feel free. However, unless you come up with a mechanism for not
>> hosing the user system on install, that would still be an RC bug
> It would not be, since we will do the right thing :)
Given your grasp of the technical issues of the problem we
apparently are discussing, I very much doubt that.
>> for the official kernel image, so I am not sure what you are
>> buying. If you install an initrd image system willy nilly with out
>> asking to make sure that the user has added initrd handling in the
>> boot loader, it still won't get into etch due to the "breaks whole
>> system" rc bug.
> Well, why do you want to ask the user to configure stuff manually,
> if you know what configuration is needed you just have to set it by
> hand, at least in high priority of debconf.
*Sigh*. You have no clue, do you? The user is the one who has
full control over /etc/lilo.conf or /boot/grub/menu.lst. I am not
asking them to configure anythinbg that I can determnine manually. I
am saying that kernel-package does not have any idea about which boot
loader is active, now ehre the configuration files lie, and neither
does debconf.
>> > Also, Manoj, why in hell did you chose to reassign this bug to
>> > linux-kernel-di-powerpc-2.6, which is a group of .udebs without
>> > any such logic and doesn't even remotely have any link to
>> > kernel-package, was it just to anoy me or something ? If this is
>> > so, i think i am expecting some apologizes from you, but i
>> > believe it was only a mistake on your part ?
>>
>> The bug was assigned from that package to kernel-package, I
> The bug was filled in a funny format, it was filled against three
> coma separated packages, not sure how this is handled by the BTS.
>> merely sent it back. I assume that the original reporter found the
>> bug in the packages it was originally reported against. Really,
>> you should stop getting annoyed by bugs reported against packages
>> you are responsible for.
> Well, i replied to the bug under the linux-2.6 umbrella, and really
> was surprised (and a bit pissed i must say) when you reassigned it
> such, to a place none of the debian kernel team will ever read ?
> And it *IS* a kernel-package bug, even if you deny it.
Repeatred assertion, backed by a total cluelessness about the
actual problem being discussed, leve me totally underwhelmed.
>> >> The installer does not know better then the user whether or not
>> >> initrd's are supported in the boot loader -- and definitely not
>> >> in the general, real world case. And the idea is to cater to as
>> >> many user as we can, not just the case of ourselves (I, for
>> >> example, never ever use initrd's on my production boxes).
>>
>> > Whatever, but this is not the choice of the debian kernel team,
>> > nor of the debian-installer team, so if you run your own kernels
>> > and
>>
>> If the debian kernel team is choosing not to cater to the wide user
>> base that the kernel-package caters to, I see this as a flaw in the
>> kernel team working.
> yeah, sure, i am sure weall appreciate your comments, in the
> meantime you are not really caring for all the debian users, but
> just the little subset who has the same needs as you.
>> > want a kernel-package which suits your own need, without caring
>> > about what the need of the debian project is, then i think there
>> > is
>>
>> Well, really, I am catering to the installed base, and the
>> users. Am I mistaken in assuming that the desires of the project
>> are supposed to be exactly that?
> Well, you *think* you are catering to them, but you plainly ignore a
> request from such an installed base, and defaults to putting the
> blame to others.
Get a clue. You have no idea how to deal with the discovery
of the fact whether a boot loader has been configured to accept
initrd images, blathering on about debconf, and you think you have
any idea how to configure kernel image installation?
>> > no more reason for the debian kernel team to use kernel-package
>> > to build the official kernels. I know some people who will dance
>> > with joy if we go this way :)
>>
>> Well, if reducing functionality and choices for the users makes
>> people dance with joy, I'll probably have to start de-recommending
>> the official kernels.
> Getting rid of the continuous pain and breakage that is using
> kernel-package and having to adapt to his misbehaviors is certainly
> something some would be delighted for. I believe that using
> kernel-package is the best idea though, but if you are going to go
> all rigid over the stuff, and not cooperate with the debian kernel
> team and refuse to even consider perfectly valid requests, i doubt
> it is a good idea to continue using kernel-package at all.
Given your total inability to grasp simple facts of debconf
usage, or what the question is trying to resolve, leads me to be
unsurprised you have a problem dealing with kernel-package.
I am quite flexible about new functionality -- provided it
does work. So far, I have seen nothing of the sort from you --
indeed, every email you continue to demonstrate your lack of grasp of
the issue under discussion.
>> >> If you think the initrd question is useless, I don't think you
>> >> have thought through real world scenarios and use cases.
>>
>> > Well, i guess that if you produce a initrd kernel with the
>> > --initrd option to make-kpkg, then make-kpkg has all the logic to
>> > know that it needs an initrd, and can produce suitable postinst
>> > scripts which do the right thing.
>>
>> Good god, man, the post isnt _does_ indeed know it has an initrd
>> kernel image. How dense can you get? If you do not have an initrd
>> kernel image, it does not ask that question. What the postinst does
>> not know is if the target system is ready for an initrd kernel
>> image.
> Ah, yes ? And when is the postinst generated ? When you build the
> package ?
Yes.
> How can you be so dense as to not see this most trivial of things,
> and you supposedly wrote that software. I guess we better get ride
> of it as quickly as possible in these conditions.
What trivial fact can't I see? Please, please, do demonstrate
your ignorance again. Or try and teach me -- what am I missing here?
The postinst does know if a kernel has an initrd or not. Are you
saying it does not?
>> Remarks like this make me question if you really know the details
>> of the issues we seem to be talking about.
> Yeah, i know you well, i believe you perfectly know what we are
> speaking about, and that you are playing the ignorant in order to
> denigrate me, you already did this in the paste, and i don't
> appreciate at all.
It is not I who is playing ignorant. Indeed, since you do not
seem to be playing at it, one can even say no one is _playing_ ignorant.
>> > The fact that the /etc/kernel-img.conf is shared between all
>> > kernels is probably another kernel-package bug in this context.
>>
>> Why? It isshared between _all_ kernels on the same machine, yes,
>> but which part of the kernel-img.conf actually fails for this?
> What if you have a initrd kernel and a non initrd kernel, and you
> want to boot both alternatively ?
Then you need to configure your boot loader to do so. Also,
you probably want to use the postinst hook and use a variant of the
sample hook script to keep the symbolic links different, and you
probably need a different update grub script.
The problem is notr /etc/kernel-img.conf -- the problem is
/etc/lilo.conf, or /boot/grub/menu.lst.
>> Any hook script can be made version dependent, and all the
>> configuration file is there for is to providehooks and and for some
>> cross version stuff like symbolic links and reverse symlinks and so
>> on.
> Indeed, but what are we going to put in those hooks ?
Err, configuration of the boot loader config, of course. What
else?
>> You continually make broad sweeping statements with very little
>> technical substantiation. Had you ever elaborated on the technical
>> problem you were trying to solve that the configurations offered do
>> not meet, rather than these broad drive-by-vague-insinuations, they
>> would have been addressed.
> bah, you just try to play stupid and ignore any arguments because
> they don't suite you.
Again, I am not the one playing ignorant. I have provided
sound technical arguments; you are the one making vague accusation
and hand waving.
> And for your info, i am actually working writing firmware code, so
> you can hardly accuse me of having no clue of what is needed to boot
> a system :)
I offer my condolences to your employer.
>> > Most problems are from having bootloaders installed that are not
>> > used, others are for having subarch targets in kernel-package
>> > that nobody used for ages, so i think removing the old cruft and
>> > keeping only the newer powerpc and powerpc64 targets should work
>> > just fine.
>>
>> Removing subarches that are not used is the domain of the people
>> responsible for them. If you really think that there are obsolete
>> subarches, and that they interfere with other subarches (abd why is
>> that?), send me an email.
> No, they don't interfer with what we need, so they can stay, for
> now.
> They are mostly just useless cruft though.
So no user exists for those subarches? All known deployments
have been eradicated? Which subarches are these?
>> > Also, notice that most of the /etc/kernel-img.conf options are
>> > highly dependent on the bootloaders, and if one uses more than
>> > one bootloader on the same machine, there should be problems.
>>
>> Which oprion in the kernel-img.conf are dependnet on boot loaders?
> link_in_boot and other symlink stuff is dependent of if the
> bootloader can follow symlink, and also on which kind of filesystem
> the firmware/bootloader is able to boot from. The bootfloppy stuff
> is also influenced with the way you boot the machine to a degree.
>> Are not related to boot loaders. The following are also not related
>> to boot loaders directly, they are about initial ram disks, which
>> can be used by boot laoders: ramdisk, do_initrd, warn_initrd,
>> mkimage,
> indeed. We have to see how this things will survive the initrd-tools
> to initramfs migration, and if we can do more funny tricks that
> initramfs allows.
Sure. All if this can be extended, of course, without
impacting older installations and the isntalled base.
>> The following three options are related to boot loaders, however,
>> you do not have to use them; you can set them to no and just do
>> your own thing in a postinst hook do_boot_enable, do_bootloader,
>> silent_loader,
>>
>> What kind of maths do you use in which three options out of 29
>> become "most"? This again makes me question if you even know what
>> kernel-img.conf is all about, and your rants become just that --
>> uninformed rants.
> Ha, what happens if you count those that are actually installed by
> default on debian systems ? debootstrap itself doesn't even set
> those values, and a clean sarge install has maybe 5 values in that
> file.
But kernel-package creates kernels that are installed on messy
end user systems, and the kernel-img.conf is not merely used on
pristine new install machines.
>> > The case is that the kernel-package code used to break frequently
>> > during the sarge d-i development phase, since it was not using
>> > debconf for its questions, and random questions came up until the
>> > setting of the kernel-img.conf entries was nicely set. I only get
>> > breakage when i build chroots with debootstrap now, and need to
>> > install a kernel to build kernel .udebs from it or for another
>> > reason, and get asked about this anoying initrd thingy.
>>
>> Well, using debconf would not make the annoying question disappear,
>> you know. Installing in a chroot is not the common case for
>> kernel-images; end user systems are.
> Ah, but it allows to handle priorities, and most of all, it allows
> to show those questions to user during d-i installs, instead of just
> dying like it happens now.
That is a point. The not using debconf is likely to be RC for
Etch, so this shall be addressed before etch release.
>> > Both grub and lilo are installed, both have debconf logic, and
>> > add themselves to the list of boot-loaders listed in the debconf
>> > database, and ask you which one you prefer to use. Then the
>> > kernel package postinst can easily enough query that debconf
>> > setting and do the right thing.
>>
>> debconf setting have nothing to do with the configuration currently
>> on disk. "Debconf is not a registry". The users can change their
>> mind about which boot loader to use -- when installed, I used lilo,
>> since it was set up already. Then I migrated to grub, after
>> creating grub on a floppy and then testing grub.
> Sure, which is why we need the cooperation from the bootloaders, and
> a real policy for this.
The code and cooperation comes first, then comes policy.
>> Why is it so hard for you to understand that debconf is not to be
>> used as a registry, and that the situation on the machine may have
>> changed after the initial install?
> Sure, then we use debconf to ask questions to user, and we use
> another file to handle the information with all packages.
So either there is /etc/kernel-img.conf, or we use debconf?
Well, that would work unless the debconf front end is
non-interative.
>> > Unless the people you are trying to explain it to just decide not
>> > to care about hearing any kind of explanation, and dismiss it
>> > from the start because it doesn't suit them.
>>
>> Err, I listen to sound technical solution, not just hand waving and
>> pretend solutions.
> You don't listen at all.
Do too. Nyah-Nyah.
>> >> overwrote the boot loader in /dev/hda3 (which is /booot, and
>> >> toggled bootable using fdisk). Then, they started using their
>> >> own kernel, and turned off initrd's in /boot/grub/menu.lst.
>>
>> > This is where you are oh so wrong, and i am very surprised
>> > because it is not like you to be so small-minded.
>>
>> Why am I wrong?
>>
>> > Anyway.
>>
>> > 1) The information of if there is a initrd or not is something
>> > related to the kernel used, since you build the kernel image
>> > with either the --initrd option or not.
>>
>> Right. That is why the question is being asked: the postinst knows
>> that the kernel has an initrd, but does not know if lilo/grub is
>> aware of that.
> So, instead of making sure the kernel .deb tells lilo/grub about
> this, you ask the user to tell lilo/grub. You know, we are no more
> in the stone age, and computers are there for making the task easier
> for the users.
So, pray tell, how does one tell grub to change menu.lst? How
do I even tell grub is the one to tell? Until the grand framework is
in place, this is not a bug in kernel-package -- this is just missing
infrastructure. Obviously, you can't alter another programs conffile
in a kernel-image maintainer script -- so the user still has to be
asked, if a configuration file has to be altered.
>> > 2) The information on where to put the initrd in a way it can be
>> > loaded is something related to the bootloader.
>>
>> Correct.
>>
>> > 3) The information on what bootloader is installed is of the
>> > resort of the user.
>>
>> And there can be multiple boot loaders installed. The user may
>> change which one is currently active by running grub/lilo/whatever
> This is why it is important to know both the list of installed
> bootloaders, and the one which is used. The user has to provide this
> information, and after all it is HE who makes this choice. The
> system can default to something sane even, and the user who doesn't
> care will not even know about it.
Or the user can just also tell kernel-package, by adding one
line to /etc/kernel-img.conf.
>> > Do we agree with that, or do you have any kind of problem with
>> > that ?
>>
>> Look above.
> Well.
>> > So, i believe that any neat solution to the problem will be to
>> > let each part be responsible of what he knows about, the kernel
>> > package to know it has to generate an initrd or not, the
>> > bootloader to know where he has to put it, and the user to chose
>> > the bootloader he is installing.
>>
>> The kernel package already knows this, this is why it is asking.
> Then why does it not tell the bootloaders instead of asking the user
> ?
Cause there is no current way to tell the bvotloader, or even
determine which boot loader to tell. duh.
>> The fact you insist that the ekrnel-package needs to know whether
>> or not there is an initrd also makes me question if you know what
>> we are talking about, or what the current behaviour actually is.
> You are the one claiming that there is no way to know if there is an
> initrd or not. So, now you are saying the opposite and blaming me ?
Can't you read? I know there is an initrd. What I don't know
is the boot loader also knows the same. You are the one making
outlandish claims that the postinst does not know.
>> How does one tell which boot loader is currently in use? How does
>> one tell if the configuration of that boot loader is ready for an
>> initrd?
> Well, i think i replied to that already numerous times, it is not my
> fault if you don't want to know, or only try to make me ridicoulous
> by playing the one who doesn't understand.
Yeah, you have hand waved a lot about debconf andgrand
plans -- but none of this exists now, and probably would require
large amountsof new code to allow users to retain current
functionality (just tun lilo to change over from grub, and run grub
to change over from lilo -- like every other linux isntall also
allows them to do). To do this seamlessly requires a lot of work to
be done that is not done yet -- and saying that ekrnel-package is
buggy for not using infrastructure that does not exist is what
started it all off.
>> >> How can you discover this reliably, using just debconf?
>> >>
>> >> >> not feasible to know what boot loader is being used (I have
>> >> >> both grub and lilo on my machines), nor is it feasible to
>> >> >> tell whether the boot
>> >>
>> >> > In today's setup, you are right :), but i believe we should be
>> >> > able to come up with somewhat better for etch if we start soon
>> >> > enough.
>> >>
>> >> So, in todays set up, this is not a bug in kernel-package, so I
>> >> am reassigning this back to where it came from.
>>
>> > you are reassigning it to some random package without thought.
>>
>> I am reassigning it to where it came from.
> Yeah, yeah, i guess you also didn't see where it came from :
> Package:
> linux-image-2.6.12-1-powerpc,linux-kernel-di-powerpc-2.6,kernel-package
> I also have no clue why it was filled like that.
>> > So, because you believe we cannot have a bootloader policy, we
>> > should not try to make any effort to fix things for sarge ?
>>
>> We can have a policy till we are blue in the face. Until we have
>> actual implementation it is all hot air. And until we have a
>> technical means for telling what boot loader is active, and
>> querying the configuration of the active boot loader, this is not
>> anything but a lot of hand waving.
> Bah, whatever, first you make the specification of the thingy, or
> the policy in this case, and then you implement the solution, with
> the force of the commonly decided thingy. That is how proper
> software design works.
Fine. Don't start by filing RC bugs on other packages that are
not using this grand old scheme until it is actually in place.
I'd be happy to help out with the requirements for such a spec.
> You can hardly propose an implementation in this case where more
> than a single developer or group of developers is concerned.
You determine requirements first, and then you move to
implementation.
>> >> >> As I have said elsewhere in this report, working correctly,
>> >> >> and not rendering the system unbootable, trumps
>> >> >> non-interactive installs.
>> >>
>> >> > Indeed, but let's try to do the right thing and allow both for
>> >> > etch, i believe it is possible, altough there may be issues
>> >> > you have more experience with and which i may have missed
>> >> > which may make the above plan not work, but i believe it is
>> >> > the right way to solve those issues.
>> >>
>> >> Indeed. Come up with a solution that works for the scenario I
>> >> have given above, and we may be getting somewhere.
>>
>> > I believe i have, and you probably would have seen it if you had
>> > looked at it positively, since i believe that you are a rather
>> > brillant person, but let's go at it.
>>
>> > 1) A user did an initial installation, using lilo and an initrd
>> > kernel.
>>
>> > => Lilo provides information to the system, either through
>> > debconf or another system of where the initrd should go. The
>> > kernel informs the system that it needs to generate an
>> > initrd. The kernel postinst script gets the information from
>> > lilo of the kernel location, and from the kernel that it needs
>> > an initrd, and does the right thing.
>>
>> This is not a problem that the question is trying to ascertain
>> anyway, so this is a distraction. Can you stick tothe point we are
>> trying to solve? The location of the initrd image is already fixed,
>> and there is no confusion about that.
> Ah, yeah ? so why are you complaining loudly about it ?
I never complaind about this bit. I complaind I don't know
which is the active boot loader, or how to tell if a boot loader can
deal with initrds.
>> > 2) Later the user decides to switch to grub.
>>
>> > => grub is now the default bootloader, and the information on
>> > where the initrd goes change. The user didn't upgrade the
>> > kernel, so during the grub the changing of the default
>> > bootloader, a script makes sure the initrd is moved to the
>> > right place or something.
>>
>> The location is not the problem.
> it will always be in boot ? The location is always known, and the
> bootloader only know if they need an initrd or not ? So why are you
> making such a fuss ?
Cause you are misreading where the problems lie. The path is
not the problem. The fact that the kernel-image doe snot ask for a
path should have been a clue.
>> > 3) The user changed the disk around. I am not sure about this
>> > one, could you
>> > please explain more in detail the exact situation ? I mean i am
>> > used to firmwares which are not discriminate in where they boot
>> > of, and have little experience with limited functionality ones
>> > like the x86 stuff.
>>
>> Err, this is not something that needs to be fixed.
> Well, you brang this up, it is your example, so why do you confuse
> the issue by mentioning stuff you believe are no problem ?
I brought up the example, yes, and presented a probloem,
which, apparently, you could not understand.
>> > 4) They decide to build their own kernel without initrd, and
>> > build a debianb package of it, the .deb package knows it has
>> > no initrd (because it was generated without --initrd :), and
>> > does the right thing.
>>
>> Grub configuration was changed not to expect or use an initrd, but
>> otherwise correct.
>>
>> > 5) The user decides to use a self generated kernel. Frankly,
>> > this is not something that debian officially supports, and
>> > it should be ok to leave the user alone in this case, he can
>> > write the lilo/grub configuration just fine in this way, and
>> > also do the lilo/grub invocation by hand, and if it fails,
>> > it is his own problem.
>>
>> This is not the case. The user has booted their kernel iamge, and
>> changed the grub configuration. So, now the machine is running a
>> non-initrd kernel iamge, and the grub configuration does not expect
>> a initrd image.
> So ? If the user muck around by hand there is no way any automated
> thingy can work, the user has to play by the rules also.
Hell no. The rules are that the user can edit any conffile
they please, and we make it so that such mucking around is
supported.
>> > => Neverthless, we can support this situation also by providing
>> > some kind of user-config in the database, where the user points
>> > his kernel too, and his initrd status, and the rest of the
>> > scripts would still do the right thing.
>>
>> What happens if now he is trying to install an image with an
>> initrd?
> Well, he is installing a hand built kernel with an initrd. Since it
> is a handbuild kernel, he tells the database that version so and so
> of his hand built (not with make-kpkg) kernel needs an initrd. and
> the system does the right thing.
no, it is built with kernel-package, and uses initrd's. Or it
can even be an official image being installed -- on a system that has
traditionally used hand rolled non-initrd images, also built using
kernel-package.
>> >> > Indeed, but debconf and a proper large-scale plan should be
>> >> > able to solve this where kernel-package alone could not.
>> >>
>> >> Good. When such a plan, and a workable one, is in place, feel
>> >> free to open a wishlist bug against kernel-package. At this
>> >> point, however, it is the debian installer that is buggy.
>>
>> > you are speakign pure nonsense here.
>>
>> Since this is how you are polite, why do you expect others to be
>> more polite than you?
> i think there is a qualitative difference between your "faugh" and
> saying that the above is pure nonsense, since you put the blame on
> debian-installer, which has scarcely anything to do in the scenarios
> we are contemplating here.
The scenario has everything to do with kernel-package, which
is what you are trying to blame.
> But then, maybe we don't speak the same english ...
>> >> > This is also the logical continuation of the work done by the
>> >> > kernel team, and i hope you can add your experience and
>> >> > knowledge to help us evolute this in the best possible
>> >> > solution for etch.
>> >>
>> >> I have always answered emails sent to me. I would also prefer to
>> >> start working with the problem statement, not with a proposed
>> >> fait accompli, since there are times, like now, where I consider
>> >> the proposed solution as being suboptimal when it comes to
>> >> kernel packaging --- but I have been doing this for ten years.
>>
>> > Hehe, well, and you don't think a bug report is a good place to
>> > discuss this, right ?
>>
>> Actually, since I had to go hunting for your reposnse (it was not
>> sent tome by email), no, this is a piss-poor place to do a
>> design. Sending me email would ensure I was kept int he loop.
> Ah, i had hoped that as a maintainer you would be responsible enough
> to read the bug reports against your packages, but then i beleive
> the problem was because you decided to reassign it to some random
> package just to get ride of it,
That happens not to be the truth. You went and made a boo-boo,
making the d-i break (and obviously never tested it in a clean
chroot), and tried to balem kernel-package. I determined it was not a
bug, provided explanation, and assigned it back. Future discussion
opf potential infrastructure changes do not belong in this bug report.
> and furthermore i did a group reply, so you would have been CCed if
> you had not mucked with your email setting, or maybe you are using
> one of those blacklister, which block half the ISPs of the planet.
This is mostly incoherent.
> In any case, if you didn't read my reply, it is your own pure fault.
Bug reports are still silly ways to do design discussions.
manoj
--
Stop searching. Happiness is right next to you. Now, if they'd only
take a bath ...
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: