Sign in to follow this  
thinksitdo

Change MAC address AFTER DSM 6 install?

Recommended Posts

I successfully did a clean install of DSM 6 on a Microserver Gen8 with the original MAC address. I would like to use my old 212j MAC address now I have migrated over all my files so I can use QuickConnect. Can I alter this on the USB boot drive and would it have any affect or would I have to alter additional file on DSM? Or, would I have to do a clean install?

 

Many thanks

 

Scott

Share this post


Link to post
Share on other sites

The use of QuickConnect with an Xpenology box is a violation of Synology's services. QC is aimed exclusively to Synology's customers. Using QC with Xpenology simply destroys this project and give us a bad reputation. I highly recommend you do not use QC. Any discussion on how to abuse Synology will be closed.

 

Simply use your real NIC MAC address by modifying the grub.cgf file in your USB boot drive and then set up a custom DDNS instead of QuickConnect. Have a read at the tutorial >>> viewtopic.php?f=2&t=22100

Share this post


Link to post
Share on other sites

you can change mac address by pressing C in grub menu, enter "mac1 your_mac" in command line, then ESC and boot

Share this post


Link to post
Share on other sites

Hello  @Polanskiman, I understand what you say and totally agree, Personally, I won't be using quickconnect, however I don't see a reploy to the question of the original title... can we change the mac adress after? :-(

 

I did a fresh install of DSM 6 on a proliant gen8 in a microsd and everything went smoth. As I used microsd card I didn't have to change PID, VID and therefore also forgot to change mac-adress as it just loaded straight forward. Is that serious and can provoke potential issues?

I realized it was not clean when I tried to install xpenlogy on a nother VM in the same LAN...obviously same mac with different @IP cause conflicts...

 

I tested then to set up a new flash usb stick setting VID PID and mac (with OSF mount) but when starting the server the "syno assistant", it provides a DHCP @IP as it was a "new install"? and just propose a "repair". I guess it's logical because of the new mac adress...

 

What should I do? Should I proceed with the repair? I don't want to lose all my config!

 

Changing the mac adress from the grub menu itself pressing "c" would be better? won't it break anything?

 

 

Please help!!!! I would like to avoid a fresh install

Edited by siulman

Share this post


Link to post
Share on other sites

Responding to myself and maybe in order to help if someone is in the same situation as @mikhan stated below, chaning the mac adress from the grub menu worked perfectly. 

--> by pressing C in grub menu, enter "mac1 your_mac" in command line, then ESC and boot.

 

I still don't know why creating another usb stick didn't work, if someone can provide some clarity on this it would be great...

 

 

Thanks!

 

Share this post


Link to post
Share on other sites

easiest way of changing mac might be to use the microsd card or usb stick in windows and edit the grub.cfg (notepad++, its a unix file!)

changing with grub bootloader at boot does work too but its not so comfortable

 

why did a new created stick did not work? - most likely is you used jun's original from the start (that contains DSM 6.1.(0) kernel), installed dsm 6.1.3 or 6.1.4 and in this process the new kernel was written to the usb stick so installed dsm an disk and kernel on usb stick match

when replacing the usb stick with a new created from jun's image it contained the kernel from 6.1.0 and that does not mach the system on disk anymore, thats re repair is for

in synology original real life situation that would be like having  actual dsm, mainboard broken, getting a replacement "chassis" (with new mainboard containing usb laoder with older dsm kernel) and inserting the disks with newer dsm on it, that needs to be fixed without emptying the "good" (data containing) disks

 

to address this sbv3000 made a version containing the kernel of 6.1.3 (15152)

if a 6.1.4 is installed it would need a image with the matching kernel, so it would need a version for every major version of dsm 6.1, if its woth it is not decided yet as it would mean images for 6.1.1, 6.1.2, 6.1.3, 6.1.4 and for all 3 version - can get confusing for people and also easy to use the wrong image with so many

i theory it should be possible to refresh the stick with the content of the installed dsm *.pat file manually, so o written howto would be the thing to do?

 

Share this post


Link to post
Share on other sites

Hello @IG-88,

 

Thank you for your response. This is a pretty good explanation. In understand now why "version" "6.1.0" was displayed in my "syno in assistant soft" when I tried to boot with the new USB Flash using 1.02b indeed. I though upgrades did not write anything in the USB stick/microsd. I realize now that it does!

 

Concerning the first point... I was not able to open the partition where the "grub.cfg" is in a my microsd card. Windows10 just propose to format de partition but apparently can't open it.

 

Concerning the second point, allow me to ask:

 

What happens is my microsd fails tomorrow? How can I restore my system? Giving the fact I am running 6.1.4-15217 update 3 in a DS3615xs in a proliant gen8 and there is no bootloader for this kernel....

What is the procedure in this worst scenario? Is there a tutorial or somehing? would the "repair" work?

 

Edited by siulman

Share this post


Link to post
Share on other sites
4 hours ago, siulman said:

Giving the fact I am running 6.1.4-15217 update 3 in a DS3615xs in a proliant gen8 and there is no bootloader for this kernel....

What is the procedure in this worst scenario?

 

to prevent any untested manual work for now i would suggest

 

1. make a backup with Win32Diskmager after a major update (dd if its linux)

or

2. use virtualbox vm, create usb as usual with a 6.1.0, create a vm for dsm (should be documented here in the forum), hand over the usb to the vm and boot from that stick, install the dsm you use in baremetal and after that your usb has the version you need, just change mac/sn as needed and you are ready to go

alternatively to usb stick you can use a vmdk text file referencing to jun's img file (he had this in 1.02a together with the img file), that way you modify the img by installing dsm and can work as in the normal intall howto so after updating the img by installing newer dsm use osfmount to edit grub.cfg for mac/sn, and win32diskimager to write it to usb

 

4 hours ago, siulman said:

Is there a tutorial or somehing? would the "repair" work?

 

no, i have only checked the usb stick for newer files and the files come from the dsm *.pat file

i wrote that here:

 

in win10 (creators update or later, win7 or earlier win10 only show 1st partition) you see both partitions of the usb stick when you connect it so it should be easy to copy the files

other method would be so read the usb stick with win32diskimage modify the image with osfmount and write the iage back to usb

Share this post


Link to post
Share on other sites

Among all what you said, I decided to do a “win32imager” of my current microsd. I flashed it in a pendrive changing vid/pid and worked perfectly. I think it’s the easyest way.

I am just entering into the xpenology world. This is great, however, I still have a doubt. What happens if someday for some reason I do an upgrade and it fails. How to roll back?

Share this post


Link to post
Share on other sites

Well I guess you will need to come here and provide details of what the problem would be. It is difficult to tell you what would need to be done for something that has not yet happened.

 

In general updates don't fails per say. What actually fail are external modules not been up to date following a major update or simply the loader not having been updated for the new DSM update; e.i. a major update usually has a different kernel version than its predecessor and so modules need to be recompiled in order for the hardware to be detected by DSM; The loader also needs to be re-worked to make sure it will boot up DSM properly. Regarding modules, this usually applies to network adapters or disk controllers which modules have been added by a third party like developers here. This does not apply for modules which are part of DSM simply because the update will provide such newly compiled modules.

 

Simply come to forum regularly and check out the Critical Update forum as well as other sections of the forum. Never update a production machine prior updating a test machine first or checking the forum for compatibility issues.

Share this post


Link to post
Share on other sites
On 19/12/2017 at 6:25 AM, Polanskiman said:

Well I guess you will need to come here and provide details of what the problem would be. It is difficult to tell you what would need to be done for something that has not yet happened.

 

In general updates don't fails per say. What actually fail are external modules not been up to date following a major update or simply the loader not having been updated for the new DSM update; e.i. a major update usually has a different kernel version than its predecessor and so modules need to be recompiled in order for the hardware to be detected by DSM; The loader also needs to be re-worked to make sure it will boot up DSM properly. Regarding modules, this usually applies to network adapters or disk controllers which modules have been added by a third party like developers here. This does not apply for modules which are part of DSM simply because the update will provide such newly compiled modules.

 

Simply come to forum regularly and check out the Critical Update forum as well as other sections of the forum. Never update a production machine prior updating a test machine first or checking the forum for compatibility issues.

 

 

Hello @Polanskiman,

 

Thank you for your response. Message received and understood. Before any update I always check the forum and make sure people succeded with the same hardware as me + I test the update on my VM.

However, how to proceed if the update fails? Is there a roll-back method? I understand when you proceed with an upgrade you are flashing the bootloader usb key but also performing some modifications in the primary disk where the system is installed. So, even if you reflash the usb key with the previews bootloader, is the primary disk blocking for the roll-back? or can you do a "repair" thing ?

 

Thanks

Share this post


Link to post
Share on other sites

Hello everyone,

 

just wanted to inform I have tested to plug into my server a pendrive with an old bootloader version. Using the "syno assistant" just clicked on "repair" and everything just booted with the old version. So I guess if and update fails, I just have to flash a pendrive with and old working bootloader and "repair" to boot.

Share this post


Link to post
Share on other sites
4 hours ago, siulman said:

Hello everyone,

 

just wanted to inform I have tested to plug into my server a pendrive with an old bootloader version. Using the "syno assistant" just clicked on "repair" and everything just booted with the old version. So I guess if and update fails, I just have to flash a pendrive with and old working bootloader and "repair" to boot.

Yes that should work, but only 'within' the DSM version eg 6.1, if you tried the 6.0 loader it would probably fail

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this