Hello!
Does anybody know if there is a way to remove “Build with susestudio” logo. I tried with changing the pictures in iso file and rebuilding it but it didn’t work.
Thanks for help
On Wed, 25 Apr 2012 13:36:02 +0000, mihamobili wrote:
> Hello!
>
> Does anybody know if there is a way to remove “Build with susestudio”
> logo. I tried with changing the pictures in iso file and rebuilding it
> but it didn’t work.
>
> Thanks for help
Probably pretty easy to do with the on-site version.
But it does seem reasonable that for the free version, they’d want to use
the appliances developed with it to advertise the service. Doesn’t that
seem fair to you?
Jim
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell Knowledge Partner
@Jim do you really think he cares if you think it’s reasonable or not?
An it’s not really reasonable at all, just yesterday I read a blog post done by Jos Poortvliet called On the value of collaboration, even though the blog post was about collaboration between anyone making changes to various cores/sources it was just as much about opensuource and access to changing source as you wish.
Here is a quote for you:
“So, I believe that if you try to isolate yourself from the rest of the Free Software world, you’re not only doing yourself a disservice, but all of Free Software”
My conqlusion: susestudio is a tool to build custom respins of the openSUSE source, BUT you can not debrand it!
It seems like a small issue right? and it seems I’m ungrateful right? Well maybe I am, but I have the right to be as long as the freedom openSUSE and Poortvliet talks about does’nt apply as far as susestudio goes.
openSUSE always talks about open source, however debranding there source are supposed to be impossible, this is redicilous and makes the blog post Poortvliet redundant. He should remove it in my opinion.
Now to the issue about debranding, I’ve tried it for months now and have partially succeeded for installed users but not for the live session.
I have build custom packages with various configuration, I’ve built custom gfxboot themes, bootsplash themes and even tried overriding the suseconfig scripts running at the live session, but all my efforts have so far failed.
I’ve browsed every susespesific folders in the image, but so far no success.
I’m now building a package that overwrites about every branding related files I’ve found so far, but I doubt that it will help. .
I’m about to write a short guide on how to debrand for installed users, I’ll update this post as soon as it’s ready and if I succeed debranding the live session I’ll update here as well. .
@Jim, i’m sorry, but I dislike forum posts like the one you did above where you contribute nothing, I am sure that the original poster has been working hard with he’s appliance and that he wants anyone that uses it enjoys it, with the posters very own branding.
On Tue, 08 May 2012 16:36:03 +0000, tertitten wrote:
> @Jim, i’m sorry, but I dislike forum posts like the one you did above
> where you contribute nothing, I am sure that the original poster has
> been working hard with he’s appliance and that he wants anyone that uses
> it enjoys it, with the posters very own branding.
If he wants to use his own branding, there is a full version of SUSE
Studio that is fully customizable.
It doesn’t bother me if you don’t like posts like the one I wrote. Your
reply similarly doesn’t particularly add anything to the discussion, but
I specifically wanted to understand the OP’s rationale for wanting to
remove the SUSE Studio branding from his appliance - he’s using the
service for free, and to me it seems perfectly reasonable that as a
‘thank you’ to SUSE that those who use his appliance learn about what
SUSE Studio can do and be given the opportunity to learn about the
service.
It’s reasonable that he wants anyone who uses his appliance to enjoy it.
How does leaving the SUSE Studio branding on it take away from his users’
enjoyment of the appliance?
Indeed, one of the purposes of the free SUSE Studio service is to let
people see what can be done with it. It allows customization of SLE and
openSUSE installations, and there is a paid-for version that has more
functionality.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Let’s just disagree 
I wrote a long answer, but something unknown to me happened to it. . Anyway here is a short version
Having proprietary branding in a derivative makes it seem like a uninspired attempt of creating a derivative, it makes it seem like there’s no effort going into the derivative… I’ve read enough of reviews of derivatives to know that it’s a huge turnoff when there are brandings like these in the “distro”
The kernel line should read whatever the derivative is called and the bootsplash and desktop should be something you can brand. This should be available for free in my opinion.
Let me ask you something, when was the last time you heard about a successful Desktop derivative of openSUSE ?
When was the last time you read a review of a Desktop derivative based on openSUSE ?
When was the last time you actually read an excited blog about susestudio, where the blogger has only positive stuff to say?
I’ve read a few blogs about susestudio, but there is always a but in it… usually something like “but I could not created/remove the branding” You may think that this does not matter for anyone else than me, but I promise I’m not the only one that are “thinking about” changing the base, many have allready to i.e fedora or ubuntu which gives those distros positive results as more people actually discovers those distros simply trough they’re derivatives.
How many people do you think has discovered ubuntu thanks to Linux Mint?
In my opinion openSUSE, susestudio (free and commercial) and suse would benefit massively thanks to successful derivatives, it would show that both openSUSE and susestudio is extremely flexible… It will never happen as long as you can’t do everything you want with the original opensuse images for free… It just want, and it hasn’
t. Simply because people wants something that seems professional from the very first boot to an installed desktop, having “built in susestudio” logos everywhere does not inspire people to try your derivative.
How do I know this?
Well, again I know because of all the reviews I’ve read where the branding seems uninspired
And the number one complaint on my own appliance is the basedonopensuse branding.
I want it removed, and I don’t want my derivative officially released before it is removed, I don’t want my hundreds of hours of work seem like it’s just something trown together in a few hours.
I’m not sure if I explain the problem well enough, and it may seem like bagatelle’s but it’s really not for allot of us using susestudio, just check the forums and the mailinglists.
Having successful derivatives based on openSUSE would only be beneficial for openSUSE
On Tue, 08 May 2012 18:26:02 +0000, tertitten wrote:
> Let’s just disagree
No doubt we will.
> Let me ask you something, when was the last time you heard about a
> successful Desktop derivative of openSUSE ?
openSUSE Medical and the education derivitive immediately come to mind.
> When was the last time you read a review of a Desktop derivative based
> on openSUSE ?
I don’t often go looking for reviews of derivitives.
> When was the last time you actually read an excited blog about
> susestudio, where the blogger has only positive stuff to say?
Again, not something I go looking for, but it is something that I’ve
talked to people about and in general, people are very impressed with it.
> I’ve read a few blogs about susestudio, but there is always a but in
> it… usually something like “but I could not created/remove the
> branding” You may think that this does not matter for anyone else than
> me, but I promise I’m not the only one that are “thinking about”
> changing the base, many have allready to i.e fedora or ubuntu which
> gives those distros positive results as more people actually discovers
> those distros simply trough they’re derivatives.
So let me see if I understand - people discover Ubuntu or Fedora through
a derivative not because it’s branded, but because they ‘discover’ it?
Seems like making it clear that it’s a derivative would help with that
‘discovery’.
> In my opinion openSUSE, susestudio (free and commercial) and suse would
> benefit massively thanks to successful derivatives, it would show that
> both openSUSE and susestudio is extremely flexible… It will never
> happen as long as you can’t do everything you want with the original
> opensuse images for free… It just want, and it hasn’
> t. Simply because people wants something that seems professional from
> the very first boot to an installed desktop, having “built in
> susestudio” logos everywhere does not inspire people to try your
> derivative.
Here’s something that we perhaps do agree on - that having the freedom to
do it is in the spirit of OSS in general.
But I have a hard time understanding why people who love openSUSE and
SUSE enough to use it as a base have a problem with advertising that they
used something they love /as/ a base.
> How do I know this?
> Well, again I know because of all the reviews I’ve read where the
> branding seems uninspired And the number one complaint on my own
> appliance is the basedonopensuse branding.
> I want it removed, and I don’t want my derivative officially released
> before it is removed, I don’t want my hundreds of hours of work seem
> like it’s just something trown together in a few hours.
I don’t think it says “I spent no time building this”. It says that you
used a professional-grade tool for building it. It says that you’re
smart enough to know that you don’t have to re-invent the wheel to build
a base OS.
There’s nothing wrong with doing things the easy way. I’m guessing that
your appliance isn’t about the Linux OS or kernel, but about some
application or suite of applications that you want to put together and
make them easy for someone to use.
So using a tool like Studio says that you put care into what was
important for your appliance - and you left the configuration of the base
to something that is reliable and solid for doing that.
> I’m not sure if I explain the problem well enough, and it may seem like
> bagatelle’s but it’s really not for allot of us using susestudio, just
> check the forums and the mailinglists.
If you mean the Studio forums/mailing lists, they’re one and the same
thing. If you mean this forum, I’m here pretty much daily.
> Having successful derivatives based on openSUSE would only be beneficial
> for openSUSE
This is something else we agree on.
Jim
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell Knowledge Partner
I think we agree about allot, but see some things differently, and thats fine
About this:
So let me see if I understand - people discover Ubuntu or Fedora through
a derivative not because it’s branded, but because they ‘discover’ it?
Seems like making it clear that it’s a derivative would help with that
‘discovery’.
What I mean is that when derivatives of various products gets mentioned in any media, it is always clear what product the derivative is based on. .
This is evident on websites, reviews, and on such pages as distrowatch.com.
It’s not that we want to exclude what product the image is based on, this information will always be available anyway, so will the information on what is used to build the images.
I don’t even think you can submit a “distro” to distrowatch.com without this information, along with lots of other information …
It’s no secret that Chakra is based on Arch, Fuduntu is based on Fedora, Pear is based on Ubuntu, etc etc etc…
I found the Arch Desktop thanks to Chakra, I had always believed that Arch was a server distro only, a friend of mine uses Debian thanks to Dreamlinux, I’m sure there are tons of examples where people have found the mothership thanks to derivatives
The derivatives you speak both are semi-official and semi-supported distros and is off-topic
On Tue, 08 May 2012 20:56:02 +0000, tertitten wrote:
> I think we agree about allot, but see some things differently, and thats
> fine
I’ve always said that if everyone always agreed about everything, life
would be incredibly dull.
> About this:
> -So let me see if I understand - people discover Ubuntu or Fedora
> through a derivative not because it’s branded, but because they
> ‘discover’ it? Seems like making it clear that it’s a derivative would
> help with that ‘discovery’.-
>
> What I mean is that when derivatives of various products gets mentioned
> in any media, it is always clear what product the derivative is based
> on. .
> This is evident on websites, reviews, and on such pages as
> distrowatch.com.
OK, so then I don’t understand why having the image actually say what
it’s a derivative of is a bad thing.
> The derivatives you speak both are semi-official and semi-supported
> distros and is off-topic
Only in the sense that they’re discussed on the project list on occasion.
Digging a bit more into the technical details related to this topic, it
looks like the images are tweaked after the build scripts are all done -
even a ‘post build’ script shows that the images haven’t been modified.
So it seems the way to handle this for those who are really determined
(and thus are not likely to be distributing through the Studio gallery
anyways) is to build with studio, export the kiwi config, tweak and build
locally.
You might also be able to do something with the first boot script, but
obviously that doesn’t help if the media is R/O.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
I’ve tried with some custom packages and config files, for me it hasn’t helped so far, but I’m not the one to give up so easy, I have never tried the Kiwi export, but that is of-course a option. I’ll look into that.
Here are some of the files I’ve somehow tweaked or changed in the latest package I built. . I haven’t gotten to try the package yet as I havn’t built the latest image yet, but anyway these are the files I tweak to try to debrand
/etc/gconf/gconf.xml.vendor/%%gconf-tree.xml # for wallpaper, I doubt it does anything as long as I use the /usr/share/glib2.0/schemas/openSUSE-branding.gschema.override file
/etc/gdm/custom.conf #login user live, can also be done trough susestudio setup
/etc/skel/.gtkrc #theme specific
/etc/skel/.config/gtk-2.0/gtkrc #theme specific
/etc/skel/.config/gtk-3.0/settings.ini #theme specific
/etc/skel/.gconf/apps/metacity/general/%%gconf.xml #theme specific
/studio/build-custom.out #the studio themes applied both for bootsplash and gfxboot
/studio/config.xml #the studio themes applied both for bootsplash and gfxboot
/studio/configure_gdm_theme.sh #the studio themes applied both for bootsplash and gfxboot - tweaked to match my own wallpaper
# I doubt it does anything as this file probably is generated by some other script
/studio/configure_gnome_background.sh #the studio themes applied both for bootsplash and gfxboot - tweaked to match my own wallpaper
# I doubt it does anything as this file probably is generated by some other script
/studio/manifesto.xml #the studio themes applied both for bootsplash and gfxboot
/studio/profile #the studio themes applied both for bootsplash and gfxboot
/usr/share/gdm/themes/studio/background.jpg #applied my own picture as background
/usr/share/gdm/themes/studio/background.png #applied my own picture as background
/usr/share/gdm/themes/studio/dots.png
/usr/share/gdm/themes/studio/GdmGreeterTheme.desktop
/usr/share/gdm/themes/studio/logo.png #applied my own picture as logo
/usr/share/gdm/themes/studio/preview.png #left as is for now
/usr/share/gdm/themes/studio/studio.xml
/usr/share/gfxboot/themes/studio/data-boot/back.jpg #applied my own picture as background
/usr/share/gfxboot/themes/studio/data-install/back.jpg #applied my own picture as background
/usr/share/gfxboot/themes/studio/data-install/welcome.jpg #applied my own picture as background
/usr/share/gfxboot/themes/studio/config
/usr/share/glib2.0/schemas/openSUSE-branding.gschema.override #There is allot of setting you can change here
# you need to have the opensuse gio branding package installed to use this tweak
/usr/share/glib2.0/schemas/org.gnome.desktop.background.gschema.xml # set wallpaper etc
/usr/share/glib2.0/schemas/org.gnome.shell.gschema.xml #gnome-shell specific tweaks
/usr/share/gnome-background-properties/gnome-default.xml #default gnome wallpaper
/usr/share/wallpapers/openSUSE-default-static.xml #changed to point to my own wallpaper
I’m also tweaking a few other files to my preference, but again, the files above are for my latest package and I doubt it will do anything for debranding, but I’ll try it anyways.
On Tue, 08 May 2012 21:46:03 +0000, tertitten wrote:
> I’ve tried with some custom packages and config files, for me it hasn’t
> helped so far, but I’m not the one to give up so easy, I have never
> tried the Kiwi export, but that is of-course a option. I’ll look into
> that.
What I did was have studio execute the command:
rpm -Vv bootsplash-branding-openSUSE > /var/log/rpmverify.txt
as the final command in the post-build script. This is the last place
where you can make changes during the build.
The rpmverify.txt file showed no changes to that RPM.
In the built system, the same command shows which files have been changed.
Conclusion: They are modified after the builder has their last chance to
customize the image.
Therefore, the only way to change it (using Studio) without buying the
onsite version of Studio is during the first boot script. You’d have to
replace any branding RPMs with the originals in order to replace the
modified files.
The other option is to export the kiwi config and build locally using
kiwi. There doesn’t appear to be any other way to accomplish this. The
modification is deliberate and (I think) perfectly reasonable for the
reasons I explained before.
That said, I did (as a result of this thread) modify a VM that I had
built in Studio just to see what it would take to remove the branding,
and in and of itself, it was pretty easy to do. So tweaking the kiwi
build script to suit your needs would seem the best option without buying
SUSE Studio Onsite.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
“Therefore, the only way to change it (using Studio) without buying the
onsite version of Studio is during the first boot script. You’d have to
replace any branding RPMs with the originals in order to replace the
modified files.”
I have actually tried that, but as far as the bootsplash theme goes I could not figure out how to do a mkinitrd to actually write the bootsplash theme change.
I of-course tried /usr/bin/mkinitrd in the build script - nogo
Also tried it in the first boot script - nogo
Edit: Had a look to the log, my bootsplash theme does the exact same thing as the opensuse one except the files are different
Installing: bootsplash-branding-aperturelinux-0.0.1-49.1 [complete]
More rpm-results:
Updating /etc/sysconfig/bootsplash…
Log:
......... /etc/bootsplash
......... /etc/bootsplash/themes
......... /etc/bootsplash/themes/aperturelinux
......... /etc/bootsplash/themes/aperturelinux/config
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1024x600.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1024x768.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1152x768.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1152x864.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1280x1024.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1280x768.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1280x800.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1280x854.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1280x960.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1366x768.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1400x1050.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1440x900.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1600x1024.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1600x1200.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1600x900.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1680x1050.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1920x1080.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-1920x1200.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-3200x1200.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-640x480.cfg
......... /etc/bootsplash/themes/aperturelinux/config/bootsplash-800x600.cfg
......... /etc/bootsplash/themes/aperturelinux/images
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1024x600.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1024x768.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1152x768.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1152x864.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1280x1024.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1280x768.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1280x800.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1280x854.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1280x960.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1366x768.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1400x1050.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1440x900.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1600x1024.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1600x1200.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1600x900.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1680x1050.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1920x1080.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-1920x1200.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-3200x1200.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-640x480.jpg
......... /etc/bootsplash/themes/aperturelinux/images/bootsplash-800x600.jpg
......... /etc/bootsplash/themes/aperturelinux/images/logo.mng
......... /etc/bootsplash/themes/aperturelinux/images/logov.mng
......... /etc/bootsplash/themes/aperturelinux/images/silent-1024x600.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1024x768.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1152x768.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1152x864.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1280x1024.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1280x768.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1280x800.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1280x854.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1280x960.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1366x768.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1400x1050.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1440x900.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1600x1024.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1600x1200.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1600x900.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1680x1050.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1920x1080.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-1920x1200.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-3200x1200.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-640x480.jpg
......... /etc/bootsplash/themes/aperturelinux/images/silent-800x600.jpg
......... c /var/adm/fillup-templates/sysconfig.bootsplash-branding-aperturelinux
Hmm, there is one important difference between the two packages though…
The package bootsplash-branding-openSUSE actually did properly update the bootsplash and did run mkinitrd to actually set it as the bootsplash, while my package did set the correct values in /etc/sysconfig/bootsplash, but did not run mkinitrd at the end…
Wierd, and I don’t know why that is.
On Tue, 08 May 2012 22:16:03 +0000, tertitten wrote:
> I have actually tried that, but as far as the bootsplash theme goes I
> could not figure out how to do a mkinitrd to actually write the
> bootsplash theme change.
I found that it was necessary to use gfxboot to get the change to be made
in my Studio-built VM. I also had to install another branding package so
the theme was properly listed. Replace the image files with the
original, and then run gfxboot -theme openSUSE to get the original
openSUSE theme back in place.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On Tue, 08 May 2012 22:26:02 +0000, tertitten wrote:
> The package bootsplash-branding-openSUSE actually did properly update
> the bootsplash and did run mkinitrd to actually set it as the
> bootsplash, while my package did set the correct values in
> /etc/sysconfig/bootsplash,
> but did not run mkinitrd at the end…
I think if you do an RPM verify on the package (if you installed the
package in Studio), you’ll see that several of the files changed. When I
installed that package in a 12.1 VM (which is what I was testing with), I
noted it did run mkinitrd, but because the file was modified to have the
“built with” graphic included, the image didn’t change.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
I found that it was necessary to use gfxboot to get the change to be made
in my Studio-built VM. I also had to install another branding package so
the theme was properly listed. Replace the image files with the
original, and then run gfxboot -theme openSUSE to get the original
openSUSE theme back in place.
I don’t understand what you mean by “I found that it was necessary to use gfxboot to get the change to be made
in my Studio-built VM” do you mean you had to install some gfxboot branding or what?
I don’t understand exactly what you mean by this ether: “Replace the image files with the original, and then run gfxboot -theme openSUSE to get the original openSUSE theme back in place.”
I’m now trying to install both my config overrides and the bootsplash theme with the build script.
The gfxboot theme/branding I made works for installed users but not for live, so I might have to try to install the theme using the build script instead of as a regular package under the software tab
It’s now at the point where I no longer have any ideas on how to manage to debrand everything, I’ve looked trough those scripts I have found and haven’t really found anything obvious. . I’m not to good at bash scripting so adding to much to the “Run script at the end of the build” is not an easy task for me.
I’ve learned allot from experimenting though, I’ve learned what configs does what, packaging and much more
On Wed, 09 May 2012 01:26:02 +0000, tertitten wrote:
> I don’t understand what you mean by “I found that it was necessary to
> use gfxboot to get the change to be made in my Studio-built VM” do you
> mean you had to install some gfxboot branding or what?
gfxboot is the tool used to configure the grub menu. The file /boot/
message is a cpio archive that contains, among other things, the graphic
used as the background on the grub menu.
> I don’t understand exactly what you mean by this ether: “Replace the
> image files with the original, and then run gfxboot -theme openSUSE to
> get the original openSUSE theme back in place.”
The studio branding is overlaid on the images in the branding package, so
whatever image you use ends up with the branding.
If you boot the appliance and run:
rpm -V -v bootsplasn-branding-openSUSE
you’ll note that a few of the files have changed from the original RPM.
You’ll need to replace those images with the files in the original RPM to
lose that branding. Simplest solution in the post-build appliance is to
just reinstall the RPM.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
That is exactly what I have tried, but it fails
I’ve tried it on first boot using a script like this:
if -f /etc/init.d/suse_studio_firstboot ]
then
# All our commands goes here
echo "Running Aperture Linux first boot script..."
# First install our config overrides manually using rpm -Uvh
rpm -Uvh /opt/aperture-configs-last-resort-0.0.1-30.1.noarch.rpm
rpm -Uvh /opt/bootsplash-branding-aperturelinux-0.0.1-71.1.noarch.rpm
/sbin/update-bootloader --refresh
fi
It doesn’t do anything as far as bootsplash goes though.
My gfxboot theme that is installed from my repo does the trick for installed users though, the bootsplash fails until mkinitrd is runned.
Nether my bootsplash theme or my gfxboot theme works for the live session
I thought about changing the files inside message, and then re-iso the image but I read somewhere that it gets overwritten anyway …
Basically the best would do as you say, simply reinstall my custom rpm’s post-build, but I can’t seem to do it correctly.
On Wed, 09 May 2012 03:56:02 +0000, tertitten wrote:
> /sbin/update-bootloader --refresh fi
update-bootloader won’t do it AFAIK. You need to use gfxboot. You also
should update /etc/sysconfig/bootloader (don’t forget to run SuSEconfig
after that) to point to the correct theme.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
tertitten;4427 Wrote:
> When was the last time you actually read an excited blog about
> susestudio, where the blogger has only positive stuff to say?
Say what? Been reading your posts and fell from my chair with what
you are expecting of a service people have put allot of effort into.
Sure, I think cars should be built, and just because I have a can a fuel
I brought along, I’ll clam one of those cars mine.
As far as the branding, I think it’s done rather nicely as the only
place you really see it is during boot and login. With a little (own)
effort it is possible to remove that branding, but I have the same view
as Jim that it’s a small thing we do in return (name exposure) for
letting us build/test/share using this service.
Even though SUSE Studio makes standard and custom package selection and
building of media effortless… it still takes proper knowledge and
skills to deliver a solid appliance, especially if one has customized in
such a way it is a ready to go “out of the box” experience. What Studio
takes away is the real effort of having to organize and build the media,
not the work and creativity you put into the appliance you deliver.
We are all entitled to our opinions, one of mine is that I think you
are looking at this in a non realistic fashion… At least your demands
are non realistic in my opinion. And yep, I’ve read different articles
and blogs this last year on SUSE Studio that where all very positive
about this service. One of the two Linux magazines I’m subscribed to
also very recently published an article on different build services…
and guess who the winner was?
Anyway, if you want to really fully customize all aspects of a build
you can. SUSE Studio offers you the option to export your project so
you can tune and tweak it anyway you’d like using Kiwi.
-Willem
–
Knowledge Partner (voluntary sysop)
It ain’t anything like Harry Potter… but you gotta love the magic IT
can bring to this world
Magic31’s Profile: http://forums.suse.com/member.php?userid=73
View this thread: http://forums.suse.com/showthread.php?t=980
-
Say what? Been reading your posts and fell from my chair with what
you are expecting of a service people have put allot of effort into.
Ehh, exactly what am I expecting except the possibility to debrand/use own branding that makes you fall of your chair ?
If that’s what makes you fall of, ether get a new chair or some nerves
I’m not expecting anything else than the possibility to debrand, if you think I do you need to re-read my posts.
You should re-read my posts anyway as it seems you have intensionally ignored some of my points regarding the no-debrand feature in susestudio.
You are also off-topic when mentioning kiwi. This thread is about susestudio and branding, not kiwi.
It’s fine that the possibility to export to kiwi is there, but if we could export to bash, would this thread automaticly be about bash as well?
Finally, it’s fine that you disagree with me, I don’t mind that at all, to sum it up, I want the possibility to make my own branding in susestudio, you don’t mind that you “cant”, fine
Finally, I am not unappreciative (at least I don’t feel unappreciative) to suse, susestudio or openSUSE in any way, I just disagree with the branding policy, is that so bad ? Giving critizism and feedback is what is needed to make a product grow right ?
There’s only a few months ago where every appliance breached openSUSE’s trademark licenses